MCP Explained for People Who Think It's Overhyped

I was skeptical of MCP for longer than I want to admit. My working theory was that it was another abstraction layer invented to justify a conference talk, one more acronym in a space already drowning in them. What changed my mind was not a demo, it was doing the math on how many integrations I would otherwise have had to build by hand, and realizing MCP was solving a problem I had personally hit and worked around badly at least three separate times.

The problem MCP is actually solving

Before MCP, if you wanted an AI assistant to pull data from your internal ticketing system, or your database, or your company wiki, you had two bad options. Option one, you write a custom integration specific to that one AI product's plugin or function-calling format. Option two, you paste context in manually every single time, which does not scale past a couple of uses. The custom integration path is the one most teams took, and it meant every AI tool you wanted to support needed its own bespoke connector to every data source you wanted to expose, an N times M problem that grows painfully fast. Ten data sources and three AI clients is not thirteen integrations, it is thirty.

MCP flips that into an N plus M problem. You write one MCP server for your ticketing system, and it works with any MCP-compatible client, Claude Desktop, an IDE integration, a custom agent you build in-house, without you touching the server code again. The client side gets the same deal in reverse, a client that speaks MCP can talk to any MCP server without custom glue code per data source. If you have ever maintained webhook integrations across multiple SaaS products, this is the exact same shape of problem, and MCP is the exact same shape of fix that a standard protocol always provides once an ecosystem gets big enough to need one.

No, it is not just another way to call a function

The skeptical version of this argument goes, isn't this just function calling with extra steps? I thought that too, and it is not quite right, because MCP standardizes more than the call format. It standardizes discovery, a client can ask a server what tools, resources, and prompts it exposes at runtime, without a human pre-registering a schema by hand in every single client separately. It standardizes context sharing beyond just tools, resources let a server expose read-only content like file contents or query results that a client can pull in without necessarily invoking a tool call, and prompts let a server ship reusable, parameterized templates. And it standardizes the transport, whether you are running a local process over stdio or a remote service over HTTP, the message shape is the same JSON-RPC framing either way, so client implementations do not need special cases per server.

Function calling, by contrast, is usually a proprietary schema format tied to one model provider's API, defined statically in your application code, with no standard way for a model client to discover what is available at runtime from an arbitrary third party server it has never seen before. MCP is closer to what LSP did for editors and language servers, one protocol, many editors, many languages, instead of every editor writing its own integration for every language.

Where the hype genuinely outran the substance

I do think some of the skepticism is fair, and it is worth naming honestly rather than pretending the whole conversation has been rational. A lot of early MCP servers published to public registries were thin wrappers around a single API endpoint with minimal thought given to tool descriptions, which matters enormously because the model relies on those descriptions to decide when and how to call a tool. A poorly described tool is worse than no tool, because it introduces a plausible-looking option the model might reach for incorrectly. The ecosystem also went through the predictable phase where every company felt obligated to ship an MCP server for marketing purposes regardless of whether it added real value over existing integrations, which is the same phase every hot protocol goes through and does not tell you much about the protocol's actual merit.

The other legitimate concern is security. Early on, a fair number of MCP server implementations did not think carefully about what happens when a tool description or a piece of returned content contains instructions aimed at the model rather than data for it, a prompt injection risk that is specific to this pattern of untrusted content flowing directly into a model's context. That is a real, ongoing concern and one worth taking seriously when you install a third-party MCP server rather than building your own, the same way you would think twice before installing an unfamiliar npm package with broad filesystem access.

What actually convinced me

What moved me from skeptic to regular user was building one server myself for an internal tool, something I cover in more detail in a separate tutorial, and watching how little code it actually took to expose something genuinely useful, a lookup against our internal deployment status API, to every AI client on my team without writing a single client-specific integration. That server took under two hours to build and has since been used unmodified across three different clients, an outcome that simply would not have happened under the old N times M model, because nobody would have bothered building three separate bespoke integrations for an internal tool that small.

If you are still skeptical, I would not tell you to trust the hype. I would tell you to build one small server yourself, for something you actually want, and see whether the discovery and reuse story holds up in practice. That is what changed my mind, and it took an afternoon, not a leap of faith.

I would also gently push back on the framing that skepticism itself was ever the wrong instinct. Healthy skepticism toward a new protocol is exactly the right starting posture, and a fair amount of what got built in the first wave of MCP adoption genuinely deserved that skepticism, thin wrappers, unclear tool descriptions, security shortcuts nobody had thought through carefully. What changed for me was not deciding to trust the ecosystem broadly, it was finding the specific, narrow claim, standardized discovery and reuse across clients, that the protocol actually delivers on reliably, and separating that from the noisier claims made by companies racing to ship something with the label attached before they had thought it through. That kind of narrow, verified trust is a healthier relationship with any new technology than either blanket adoption or blanket dismissal, and it is the approach I would recommend for whatever the next overhyped acronym turns out to be.

If you manage a team and are deciding whether to invest engineering time into MCP right now, my honest suggestion is to pick your single most-requested internal integration, the thing someone on your team pastes into a chat window manually every week, and build one server for it. Do not start with a platform strategy or an evaluation of every client that might eventually consume it. Start with the one, real, currently-annoying manual task, and let the value of solving that specific thing tell you whether further investment is warranted. That is a much better decision-making process than trying to forecast the future of an entire ecosystem from a whitepaper, and it is exactly the process that turned me from a skeptic into someone who now has four of these small servers running quietly in the background of my daily work.