What is MCP in AI? A plain answer, and what it doesn't fix

MCP is a protocol. That's it. Model Context Protocol is a JSON-RPC 2.0 spec, open-sourced by Anthropic in November 2024, that standardises how an agent asks a server "what tools do you have" and "please run this one." It is genuinely useful. It is also being asked to carry a load it was never designed to carry. If you are evaluating MCP for an enterprise agent project, the protocol is the easy part. What sits behind it is the work.

What MCP actually is

Model Context Protocol (MCP) is a wire format. An MCP client (your agent) talks to an MCP server over JSON-RPC 2.0, asks for a list of tools, resources, and prompts, and invokes them by name with structured arguments. The server replies with structured results. That's the whole protocol surface in one paragraph.

It does three useful things. It gives tools a discoverable shape, so an agent can introspect a server it has never seen before. It standardises invocation, so the same client can talk to any compliant server. And it gives the ecosystem a shared vocabulary, so vendors stop shipping bespoke tool-calling formats per framework.

If you want the deeper technical walkthrough, we wrote a deep-dive on MCP server architecture that covers the protocol surface in detail. For this piece, the protocol-level summary is enough.

What MCP is not

MCP is not a tool. It's the envelope a tool arrives in. An MCP server with no tools wired up is a working MCP server that does nothing.

MCP is not a runtime. The protocol says nothing about how invocations are authenticated as the end user, how rate limits get enforced, how failures get retried, or how an audit trail gets written. Your server has to do all of that. Most reference servers don't.

MCP is not a generator. Nothing in the spec helps you produce tools from an existing codebase, keep them in sync as the product changes, or compose them into higher-level operations. Those are problems the protocol doesn't touch.

MCP is not a category. "MCP-native," "MCP gateway," "MCP platform" — these are positioning labels vendors have wrapped around the protocol. The protocol itself is one layer. The interesting work — what tools exist, how they stay current, how they run as the right user — is everything else.

We've written about the gap between MCP-the-protocol and MCP-the-marketing-story before. It's worth a read if you're being pitched an "MCP-first" product.

Why MCP alone won't fix your agent project

Here's the pattern we see in enterprise SaaS teams who've adopted MCP and are still stalled.

The agent works in a demo. It calls four or five tools, the tools hit four or five well-trodden API endpoints, the demo lands. Then the product team asks: can the agent do the thing the UI does on the settings page? Can it do the bulk operation? Can it act as the logged-in user with their permissions, not a service account? Can someone audit what it did last Tuesday?

At that point the protocol stops being the bottleneck. The bottleneck is that the underlying product was built for the UI, and the API layer never caught up. We've written before that the average API surface exposes only a small fraction of what the product can actually do. Wrapping that fraction in an MCP server doesn't change the number. It just gives it a nicer envelope.

The second wall is maintenance. Every product release shifts behaviour. Tools that worked last sprint silently return wrong shapes. MCP doesn't tell you that happened. Your tests do, if you wrote them, and only if the test suite covers tool-call paths the way it covers API endpoints. Most don't.

The third wall is identity. An MCP server typically runs with a single set of credentials. Agents acting as users — which is what enterprise customers actually want — need invocations to execute under the user's identity, with the user's permissions, leaving an audit trail under the user's name. The protocol is silent on this. You build it or you ship something your security team will reject.

How to think about MCP in your stack

Treat MCP as plumbing. Adopt it where it reduces integration cost — it does, particularly for connecting to third-party agent clients. Don't treat adoption as the project. The project is everything around it: which tools you generate, how you keep them current, how they run as the right user, how you know when they break.

If you're choosing between an MCP-native pitch and something that solves the harder layer, ask the vendor what happens to their product if MCP is replaced next year. If the answer is "we'd have to rebuild," they sold you a protocol implementation. If the answer is "we'd swap the transport," they sold you something durable.

How Pontil fits

Pontil is a Tools-as-a-Service platform. We generate tools from the codebases established SaaS companies already have, keep those tools current as the product changes, and run them at execution time as the authenticated user — with permissions, data visibility, and audit trails that honour the real identity.

MCP is one transport we support. It's not the product. The product is the layer underneath: connector generation against the APIs that already exist, automated maintenance tied to your SDLC, and a runtime that handles auth, failures, rate limits, and observability. If MCP changes — and protocols do change — what we generate and run keeps working. The protocol is replaceable. The work behind it isn't.

What to do next

If your team is mid-evaluation: adopt MCP for what it is, a useful protocol, and stop expecting it to solve problems it doesn't address. Audit your tool surface honestly. Ask what percentage of your product an agent can actually reach today. Ask who the tool calls execute as. Ask what happens when the next release ships. Those answers tell you where the real project is. The protocol is the last 5% of the work, not the first 95%.