Why MCP is useful: An introduction to MCP for skeptics

You’re right to be skeptical about the Model Context Protocol (MCP) . From the outside, it looks like word salad, and it arrived on the heels of the hyped-up AI darlings known as “vibe coding” and “agentic”. If you’ve dared to poke around, you’re probably left with the feeling that it’s a Rube Goldberg machine, and everyone’s either in on the joke or dazzled by the complexity.

Developers love shiny complexity, but anyone who lived through the early internet’s immature, brittle protocols and torturous RPC standards knows to hit the brakes when YouTube talking heads sing a new protocol’s praises in unison.

This skepticism and care shouldn’t end at MCP, though. The entire generative AI ecosystem is rife with complexity and potential pitfalls. To quote the sagely Samuel Colvin (of Pydantic ):

From a software engineer’s point of view, you can think of LLMs as the worst database you’ve ever heard of, but worse. If LLMs weren’t so bloody useful, we’d never touch them.

Well, if MCP servers weren’t so bloody useful, we’d never touch them either!

We believe MCP will eventually enable powerful AI agent ecosystems, but we’re not here to evangelize. The protocol adds genuine complexity and operational overhead that isn’t justified for many use cases. Function calls or REST APIs are often the simpler, better choice.

But there are specific scenarios where MCP’s architecture genuinely shines - where its standardized discovery, stateful sessions, and cross-platform compatibility solve problems that are painful with alternatives. MCP servers like Desktop Commander  and Playwright MCP  demonstrate this: they turn any LLM into a powerful automation tool for desktop and web interactions that would require significant custom development otherwise.

The question isn’t whether MCP is inherently good or bad - it’s whether its benefits justify the complexity for your specific needs.

What people think about MCP

This has made a lot of people very angry and been widely regarded as a bad move.

• Douglas Adams

Polarized doesn’t begin to describe the reaction to MCP on the internet. The extremes appear to fall into four clear camps:

1. The “everything about this sucks” naysayers. Here are a few highlights from our favorite orange site:

   MCP is a kitchen sink of anti-patterns. There’s no way it’s not forgotten in a year, just like Langchain will be.

   It’s a half-baked, rushed out, speculative attempt to capture developer mindshare and establish an ecosystem/moat early in a (perceived) market.

2. The deliberately obtuse. I won’t quote these commenters for being ignorant, but you know the people who say, “I can’t get my head around this, so it must be useless.” I believe some of this group’s resistance is driven by the viscerally negative reaction of the naysayers. This one includes the “Isn’t this just an OpenAPI spec?”, “Why not just use REST?”, and “I have yet to see one compelling use case” crowds.

3. The builders who use MCP to get things done now or help fix what’s broken in the spec. Think of David Cramer learning MCP while building the Sentry MCP server  in public - or Samuel Colvin, Armin Ronacher, the developers from Cloudflare, LangChain, Vercel, and others enthusiastically (and in record time) helping to review updates to the MCP Specification . This includes the hackers (the best kind) and tinkerers who built more than 15,000 MCP servers  over the past six to eight months.

4. Vendors and tooling companies. We’re in this group - we build a platform that generates MCP servers from existing APIs. This gives us a front-row seat to both MCP’s potential and its implementation challenges, which we’ll share honestly. We have a biased perspective, of course, but that perspective comes from solving real problems developers face with MCP implementation.

Explore the skeptic’s guide

We’ve organized this guide into focused articles that address specific concerns and topics. Start with the criticisms if you’re still unconvinced, or jump to the technical introduction if you’re ready to understand how it works.

Our take

We’re not here to evangelize, but we do believe MCP solves real problems in specific scenarios. The protocol adds genuine complexity that isn’t justified for every use case - sometimes a simple REST API or function call is the right answer.

But when you need cross-platform tool sharing, stateful long-running operations, or dynamic runtime tool discovery, MCP’s architecture provides solutions that are painful to implement with alternatives.

The question isn’t whether MCP is good or bad. It’s whether the benefits justify the complexity for your specific needs. We hope this guide helps you make that decision.