The quick way to add Model Context Protocol support is to stand up an MCP server that calls your REST API over HTTP. It works in an afternoon and it is a mistake.
You now have two entry points. One of them — the original — passes through auth, metering, quota, audit and cursor handling. The other passes through whatever the MCP server happens to do, using whatever credential the MCP server happens to hold.
That second credential is usually broad, because it has to serve every caller. Which means every agent gets the union of what any agent needs.
Behind the same chain
Ours sits behind the identical wrapper chain as the REST routes:
request -> auth -> quota -> meter -> audit -> handlerAn agent calling through MCP is metered like a script, limited like a script, and audited like a script. The only difference is the shape of the envelope.
One schema, not two
The tool’s input schema is derived from the same wire contract that shapes the actor’s output. There is no second definition to drift, and adding a field to the contract is how a tool gains a parameter.
The moment those are two artefacts maintained by two people, they diverge. It takes about one quarter.
Scoping is the good part
Issue a key scoped to one actor and the MCP surface exposes exactly one tool.
This turns out to be the feature people actually want. “Give this agent the ability to search listings” is a sentence with an obvious implementation, and “give it the catalogue and trust the prompt” is not.
Marcus Ellery
Platform Lead
