We have released an MCP, sometimes it works

TL;DR: We're releasing the DatoCMS MCP after six months of development. The MCP ecosystem is flooded with low-quality implementations that barely work. Ours is better — using a layered approach with some carefully designed tools instead of dumping 150+ API endpoints on the LLM. It's kinda slow, it burns tokens, and works sometimes. Given where LLM technology actually is today, "sometimes" might be the best anyone can achieve. Try it here!

Every few years, tech discovers a new universal standard that will finally make everything talk to everything. This time it's MCP — USB-C for AI — and the industry has responded with the restraint and careful consideration you'd expect. Which is to say: +6,000 implementations in under a year, most held together with duct tape and wishful thinking.

Anthropic, OpenAI, Google, Microsoft... they're all in. And now every product manager on earth has the same slide in their deck: "MCP Integration Q2."

We spent six months building ours, genuinely excited about the possibilities it could offer. Three rewrites. Humbling amounts of testing. Today we're releasing it — not because we've cracked the code, but because after seeing what passes for "working" in this ecosystem, we figured we'd throw our hat in. It works. Sometimes. Apparently that's above average.

The uncomfortable truth about MCP quality

Let me be blunt: the average quality of MCPs that interact with SaaS products is abysmal. The hype has led to a flood of implementations that are low-quality, poorly documented, and rushed to market.

The most pervasive problem isn't even security — a serious topic I won't address here — it's that they are, very often, an agonizing experience for the end user.

A widely-shared critique documented that Claude Sonnet 3.7 achieved only a 16% success rate on airline booking tasks — the very kind of multi-step workflows MCPs promise to enable. David Cramer, Sentry's co-founder and early adopter, stated flatly: "MCP is not good, yet." The consensus among those actually building with MCP? It's premature at best.

We tested a recently released MCP from a competitor's CMS. The result? An endless cascade of failed API calls, each one marked with a warning icon. The LLM had no clue how to make the API calls using the provided tools — it just kept trying random endpoints, guessing at parameter structures, repeating the same mistakes. It was like watching someone fumble in the dark. The end result? When asked to translate an article to Italian, it overwrote the English content instead.

This isn't an edge case — this is the norm. Why?

First, because most MCPs are rushed to market due to internal and external pressures — whether from the C-suite, prospects, or competitors. Companies are launching MCPs with vague tool descriptions, incomplete documentation, and zero consideration for whether the LLM can actually understand them.

Second, because LLMs are still too dumb. Companies thought they could just "wrap" their APIs in a thin layer of MCP and delegate the hard work to the LLMs... but unless we're talking about extremely simple products, that's just a fantasy. APIs are too hard for LLMs, especially if the MCP does not help by offering some kind of documentation or examples — which most don't.

Third, because the protocol itself is flawed. Performance degrades after 40 tools and collapses after 60 — not exactly "USB-C for AI" when plugging in more things breaks everything.

The best part? Anthropic themselves effectively admitted the whole approach is broken: tool definitions and intermediate results eat your context window alive, slowing agents, raising costs, and increasing errors. And just a couple of days ago, they doubled down formalizing three "official" workarounds for problems people were desperately trying to solve on their own. When the creator has to keep releasing patches to make their own protocol usable, maybe it's time to stop pretending this is the future of anything.

The bottom line: making MCPs that actually work is hard. You either have to do the heavy lifting yourself — simplifying, pre-processing, hand-holding the LLM — or limit your tools to a handful of very precise actions. Not exactly the "just plug it in and let AI do the rest" future we were promised.

So what did we do?

The DatoCMS MCP: better than some (which isn't saying much)

Here's our entry: the DatoCMS MCP. Six months of development, three rewrites, and countless failed approaches. We hit every wall Anthropic just documented. The result? It's not perfect, but it's reliable enough to be useful. What makes ours different?

• 10 tools, not 150: DatoCMS offers 40+ resources and 150+ API endpoints. We've reduced this to just 10 tools by following a layered approach. Instead of dumping everything on the LLM and hoping for the best, we guide it through stages: first discover what's available, then plan the operation, then execute. The result? Fewer malformed calls, less confused reasoning, and workflows that are actually debuggable.

• Script-based approach: Instead of making one API call at a time, the LLM can write complete TypeScript scripts that batch multiple operations together. These scripts are validated before execution to catch errors early. Batching reduces round-trips and token overhead, and gives the LLM full context to reason about the entire operation — not just isolated steps.

• Incremental editing: When errors occur (and they will), instead of rewriting lengthy scripts repeatedly, our MCP allows precise modifications, significantly speeding up the trial-and-error process.

• Documentation-aware: Unlike MCPs that just throw raw API endpoints at the LLM and expect the AI to sort it out, our MCP retrieves detailed information about each method and concrete examples from documentation. This consumes quite a few tokens, but it's the only way to give the LLM a fighting chance.

It's been quite funny to see Anthropic release, just days ago, very similar solutions to the exact problems we'd been wrestling with. (Or maybe not so funny, depending on your perspective.)

• Their Search Tool → our "Layered discovery"

• Their Programmatic Tool Calling → our "Script-based execution"

• Their Tool Use Examples → just... including documentation. We did that.

But here's the difference: theirs are generic features. Ours are tailored to DatoCMS specifics — our documentation is already packed with TypeScript examples, so feeding those to the LLM gives it far more context than generic "tool use examples" ever could. Plus — and this is a big plus — because our approach is baked into the MCP itself, it works today across any client: Claude Desktop, VS Code with Copilot, whatever. Not just Claude's API.

So what does this actually look like? The MCP can handle complex operations like generating landing pages, translating content, and modifying schemas — tasks that leave most competitors' implementations in shambles:

The harsh reality

But let's not pretend this is a victory lap. Our MCP still has significant limitations:

• Token consumption: Reading documentation is expensive.

• Speed: Don't be surprised if operations take a while. A "simple" operation could finish in seconds or stretch to several minutes, depending on how the LLM approaches it.

• Unpredictability: LLMs are not that smart. They forget things. They take absurd paths even when given all necessary information.

• Scale limitations: It struggles with particularly large records and complex modifications.

The fundamental problem isn't our implementation — it's that LLMs aren't ready for this level of autonomy. They're statistical models that sometimes produce useful outputs.

So why release it at all? Because "sometimes" is the best anyone can achieve right now — and our "sometimes" is good enough to solve real problems. The encouraging part: once patterns for a task are established, subsequent operations become more reliable. Users who provide clear, precise prompts will get better results.

The path forward

The MCP ecosystem is messy right now, but that doesn't mean the concept is doomed. It means we're in the early, awkward phase where standards are forming and best practices are emerging.

Our contribution is an MCP that actually works for complex multi-step operations. Yes, it's kinda slow. Yes, it burns tokens. But it can bulk-update SEO fields, scaffold new content types, migrate content between models... the tedious, multi-step operations you'd never want to do by hand.

We've shipped it as a beta because it's useful enough today and will only improve with real-world feedback. Are there simpler approaches on the horizon? Maybe — Claude Skills and others are worth watching. But this is what we've got now, and we think it's solid.

Give it a try! → datocms.com/docs/mcp-server