MCP, five months in: what the Model Context Protocol actually standardises
Anthropic released the Model Context Protocol in November 2024. It is an open specification describing how an AI application — a chat client, an IDE assistant, an agent runtime — discovers and invokes external tools, reads external data, and receives reusable prompts. Five months in, every product team that maintains an integration layer has been asked the same question: does MCP replace what we built? The answer depends on which part of that layer we are talking about. MCP standardises more than most teams expected, and less than the demos suggest.
What the protocol defines
MCP is a client-server protocol, currently over stdio or HTTP with server-sent events. Three primitives are specified in detail:
| Primitive | What it covers | What it does not cover |
|---|---|---|
| Tools | Discovery, argument schemas (JSON Schema), invocation, results | Side-effect policy, cost, latency budgets |
| Resources | Addressable data (files, rows, records) the host can read | Freshness, staleness semantics, pagination guarantees |
| Prompts | Named, parameterised prompt templates | Evaluation, versioning, regression testing |
The wire format is JSON-RPC 2.0. Capability negotiation is explicit at connection time. The specification is versioned and published openly, with a reference SDK in TypeScript and Python.
That is the full scope. It is narrower than “an integration layer” and that narrowness is the point.
What it replaces in our integration code
Most teams that ship LLM features since 2023 maintain a function-calling glue layer. It does the same things everywhere: declare tools as JSON Schema, serialise results, handle errors, wire tools into the model’s context. These layers are per-vendor in shape — OpenAI’s function-calling format, Anthropic’s tool-use format, and each framework’s wrapper around both — but identical in substance.
MCP targets exactly this layer. A tool defined once behind an MCP server is invocable from any MCP host without rewriting the schema. For teams maintaining internal tools and three copies of the JSON Schema describing them, the consolidation value is real and immediate. The schemas, error envelopes, and capability negotiation stop being per-client work.
Two cautions. First, schemas were never the hard part of integrations; authentication, rate limits, and data-mapping were, and MCP leaves all three to the implementer. Second, MCP’s tool model is stateless per invocation. Multi-step transactional flows still need orchestration logic that the protocol does not provide.
What it does not standardise
This is the section that matters for planning:
- Authentication and authorisation. The spec is still maturing on auth. At time of writing, teams building cross-organisation MCP servers are solving OAuth delegation, tenant scoping, and audit claims themselves. Vendor SDKs handle the protocol well and the security poorly; treat auth as bespoke work.
- Egress and cost. MCP says nothing about what a call costs. A tool that fans out to paid APIs, or a resource read that moves 40 MB, is invisible to the protocol’s accounting. Budgets and tagging remain our layer.
- Context budgeting. The host decides how tools and resources enter the model’s context window. Two MCP-compatible hosts can produce very different effective behaviour with the same server because the prompt assembly differs.
- Identity of the caller. In a multi-tenant SaaS product, “which customer is this call for” is our contract to enforce. The protocol is silent on tenancy.
MCP host vs MCP server: who builds which
A strategic decision is hiding here. Most SaaS vendors should publish an MCP server exposing their product’s capabilities, because agents and assistants are the hosts — the things users will actually talk to. A smaller set of teams are building hosts: internal agent runtimes, IDE tooling, customer-facing assistants.
Publishing a server becomes part of product surface area. It is the API we expose to machines rather than developers. Concretely, it is also an attack surface and a support commitment: schema changes break agents, not just code.
What we would do with a greenfield integration layer today
If starting an integration layer in April 2025, we would:
- Treat MCP as the north star for tool and resource packaging; there is no longer a good reason to invent a third protocol for internal glue.
- Keep authentication, tenancy, rate-limiting, and cost attribution as first-class internal work — they are not going to be standardised any time soon.
- Publish an MCP server only for capabilities with stable surface semantics; do not promise stability for exploratory tools.
- Assume that agents (not only first-party UIs) will be a meaningful share of our API traffic within 12–18 months, and price and protect endpoints accordingly.
The bottom line
MCP standardises wire formats and capability negotiation. It does not standardise the hard problems: identity, cost, data mapping, and safe side-effects. Teams that treat it as “the integration layer is now free” will discover the missing pieces in production. Teams that treat it as “tool schemas stop being per-vendor” will get exactly what the spec promises.
We could not verify claims circulating that MCP will reach protocol-level auth billing primitives this quarter. At time of writing, the spec does not.