Agent infrastructure
Platform integration
MCP protocol explained: what Model Context Protocol standardises, what it leaves open, why generated tool contracts matter, and what production MCP takes.
The Model Context Protocol (MCP) is now the default answer when a technical evaluator asks how AI agents should reach external systems. That's a real shift — a year ago, every team was hand-rolling a tool-calling contract per model, per framework, per product. Now there's a shared vocabulary.
But MCP is a protocol, not a product. It standardises the wire format between an agent and a tool server. It doesn't tell you how to build the server, what tools to expose, how to keep them current as your product changes, or how to run them safely for thousands of authenticated users. Those are the harder problems, and they're where agent projects still stall.
This piece walks through what the MCP protocol actually specifies, what it deliberately leaves open, why generated tool contracts matter more than the protocol layer for SaaS companies with real products, and what a production MCP deployment needs beyond the spec. The reader we're writing for already knows what an agent is and has probably already stood up an MCP server that works in a demo. The question is what happens next.
MCP, released by Anthropic in late 2024 and now supported across most major foundation model providers, is a JSON-RPC 2.0 protocol between two parties: an MCP client (embedded in the agent or its host) and an MCP server (which exposes tools, resources, and prompts).
The protocol standardises four things:
tools/list returns the tools a server offers, each with a name, description, and JSON Schema for its input. tools/call invokes one with arguments and returns a structured result.That's the surface. It's a small, well-scoped protocol, and that's a strength — it's easier to implement, easier to reason about, easier to argue with. Compare it to the sprawl of past integration standards and MCP looks refreshingly disciplined.
But the small surface is also the point. MCP tells you how a tool call gets on the wire. It doesn't tell you what tools should exist, how they should map to your product's real capabilities, or how you'll keep them working when your API changes next quarter.
Every time a new standard lands, teams project their own hardest problem onto it. MCP is no exception. Reading the discourse, you'd think the protocol solves capability discovery, permissioning, observability, and the connector maintenance problem. It doesn't. It wasn't designed to.
Here's what MCP explicitly leaves to the implementer:
The right-hand column is where agent projects live or die. A team can build a spec-compliant MCP server in an afternoon. Keeping that server useful across twelve months of product changes, three model upgrades, and a security review is a different problem — and the protocol is silent on all of it.
This isn't a criticism of the spec. Protocols should do one thing. But it means that when a CTO asks "are we MCP-ready," the honest answer is that MCP-readiness is the easy 10% of the work. The other 90% is deciding what your product exposes to agents and running that surface reliably.
For a small tool — a weather lookup, a calculator, a filesystem browser — writing an MCP server by hand works fine. Pick the four or five functions you want to expose, define their input schemas, wire up the handlers, ship. This is what most of the public MCP server directories contain, and it's why the demos look so clean.
Established B2B SaaS products don't look like that. A mature product has hundreds to thousands of API endpoints, most of which weren't designed for an agent caller. The UI can do things the API can't. The auth model was built for humans clicking buttons, not tokens issued per tool call. Product teams ship changes weekly, and the API surface drifts. "Just expose your API as MCP tools" — the advice that dominates most getting-started guides — is where the real problems start.
Three failure modes show up in every SaaS MCP project:
The 1:1 mapping trap. Teams script a converter that turns every OpenAPI operation into an MCP tool. The result is a tool list with 400 entries, most of which the model can't distinguish, half of which return errors in agent hands because they assume a user session that doesn't exist. Curating the tool surface — deciding what's a workflow-shaped tool versus a raw endpoint — is the actual product design problem, and it's the one the protocol won't help you with. We've written about OpenAPI endpoint curation for MCP in more depth.
Auth as a service account. The path of least resistance is a shared token for the whole MCP server. It works in the demo. It fails the security review, because every agent action shows up in your audit log as the same synthetic user, and there's no way to enforce that a user's agent can only reach what the user themselves can reach. MCP's OAuth 2.1 requirements point at the right answer — delegated identity per tool call — but implementing token exchange, refresh, and scope enforcement across a large tool catalogue is its own body of work.
Maintenance as an event, not a condition. The API changes. The tool schema doesn't. The agent starts calling a tool with a parameter shape that no longer matches, gets a 400, retries, gets the same 400, and either loops or gives up. There's no protocol-level answer to this. Someone has to notice, and someone has to update the tool contract. At the scale of a single hand-built server that's a Jira ticket. At the scale of a multi-product SaaS portfolio, it's a full-time integration engineering team — a cost that's rarely on the roadmap.
None of these are MCP's fault. They're the problems MCP surfaces because it makes the tools layer legible for the first time.
If the protocol is settled and the hard work is generating and maintaining the tools behind it, the interesting design question becomes: how do the tool contracts get built?
There are three postures:
Hand-written. An engineer writes each tool by hand — schema, description, handler, auth wiring, tests. Highest quality for the first ten tools. Doesn't survive the eleventh product change, and doesn't scale past one or two products in a portfolio.
Scanned. A vendor points a browser or an HTTP recorder at your product and reverse-engineers a tool surface from observed behaviour. Fast to demo. Has no contract — when the product changes, the tools silently drift, and there's no CI signal to catch it. This is the approach many browser-automation and "agent-native" vendors take, and it's why their tools break in ways that look like model problems.
Generated from the codebase you own. Tools are generated from the systems that already define your product's behaviour — your API definitions, your route handlers, your existing test infrastructure. The contract is derived, not observed. When your code changes, the generation runs again, the tools regenerate, and your CI catches breaking changes before they reach an agent.
Generated is the posture that composes with the way SaaS teams already work. It doesn't ask for a rewrite. It doesn't ask for a spec that doesn't exist. It doesn't invent a shadow surface that drifts from the real one. It treats tool contracts as an artefact of the codebase — the same way an SDK or an OpenAPI spec generated from route handlers is an artefact of the codebase.
The trade-off: generation is only as good as what it can read. If the product's capabilities aren't in the API layer at all — a common structural problem where the UI does things no endpoint exposes — generation alone won't reach them. That's a real limit, and it's why the honest framing of "agent-readiness" starts with a gap analysis, not a protocol choice.
Pontil sits in the tools layer of the agent stack. We're not an MCP gateway, and we're not an agent framework. We're a Tools-as-a-Service platform: we generate tool contracts from the codebases SaaS companies already own, run them through a managed runtime that authenticates as the real user, and maintain them as products change. MCP is one of the protocols we speak — but the harder work is upstream of the protocol, in generating and running the tools it carries.
For established SaaS companies whose agent projects have stalled on tool coverage or connector maintenance, the shape of the problem is usually the same: the API surface is a fraction of what the product can do, the two obvious fixes (rewrite or bespoke connectors) are both unfundable at portfolio scale, and MCP-compliance alone doesn't close the gap. If that's the shape of your project, have a look at how our approach differs or book a demo to walk through the specifics.
MCP will keep evolving — the auth spec is still stabilising, streaming semantics are still being worked out, and the resource and prompt primitives are less mature than the tool primitive. That's normal for a young standard. What's more interesting is what stops being interesting.
A year from now, arguing about MCP versus a proprietary tool-calling API will feel the way arguing about REST versus SOAP feels today. The protocol will be table stakes. The question that stays hard is the one the protocol was never meant to answer: what does an agent get to do inside your product, how do you generate and maintain that surface as the product changes, and how do you run it under a real user's identity without giving up your audit trail.
The teams that ship agents that survive contact with production won't be the ones that had MCP working first. They'll be the ones that treated MCP as an implementation detail and put their engineering effort into the tools it carries.
Stay up to date on the ever changing agentic landscape.
GET STARTED
Start with a 30-minute discovery call
contactus@pontil.com
