MCP architecture

MCP, the Model Context Protocol, is a way for a model to call tools through a shared contract instead of a one-off function list in every app. Architecture means you decide which servers exist, who may call them, what they may touch, and where those calls are logged. A pile of ad-hoc tools bolted onto a prompt is not MCP architecture. It is a weekend demo.

This post is the enterprise cut. It is not a spec reprint. The product page is MCP servers. We implement the control plane next to the LLM gateway: identity in, policy on the request, tools out. No invented product SKU. No "we invented MCP."

If you cannot name the tools a model may use this week, you are not ready for more servers. You are ready for an allow list.

Treat MCP servers as production dependencies

Each server is software that can read or write a real system. Ticket search, calendar, warehouse query, file fetch. That is a dependency with an owner, a data class, and a failure mode. Put it on the same inventory as models.

For every server:

• A name, a purpose, an environment (dev, staging, prod).
• An owner who can turn it off.
• The system of record it talks to, and whether it can write.
• A risk tier. A read-only wiki search is not a refund tool.
• How you deploy and pin a version. Floating "latest" on a write server is how you ship an accident.

Yes/no:

• You can list production MCP servers without asking Slack.
• A retired server is marked retired, not deleted, so an auditor can see history.
• A new server cannot appear because a developer pointed the client at a URL they found.

If the client can discover arbitrary servers on the public internet, you do not have architecture. You have a supply chain.

Identity and allow lists sit in front of the protocol

The protocol moves messages. It does not decide who is allowed. That is your job.

• The calling app has a service identity.
• When a user is in the loop, their token or a narrower delegated role reaches the tool, not a god-mode bot.
• The gateway or an equivalent policy hop allow-lists server plus method plus data class.
• Writes that change money, access, or customer records wait for a human, same as any other high-risk act.

MCP does not get a bypass on data governance. If the user cannot open the record, the tool must not return it. If the tool can send mail, it is a write. Log it like a write.

A local stdio server on a laptop is fine for a spike. It is not how you expose production tickets. Production servers live where you can fail them closed, with secrets in a store you control.

Put tool calls on the same hop as model calls

If completions go through a gateway and tool calls go around it, you will not reconstruct an incident. The useful picture is one request id: prompt, tool list, tool results, completion, cost.

The hop should record:

• Which server and method ran.
• Whether policy denied the call.
• How much data came back (and its class).
• Whether a write was proposed or committed.

Then you can answer "what did it do at 14:12" without reading three vendor dashboards. Cost includes tool chatter. A server that dumps a warehouse table into context is a token event and a leakage event.

Do not confuse this with a chat UI. Users stay in the system they already use. MCP is how the model reaches that system, not a new portal.

Version the contract the way you version an API

Schemas change. A tool that used to return three fields starts returning a file. Clients break, or worse, they start sending more data than you intended.

• Pin server versions for production routes.
• Review schema changes like an API review when the tool is medium or high risk.
• Keep a stub or mock for eval so you are not hitting production data to test a prompt.
• Eval the tool path: deny cases, empty results, oversized results, a user who asks the model to ignore the allow list.

If you cannot replay a tool conversation in staging, you cannot promote a prompt change that depends on that tool.

Start with two servers, not a mesh

A catalog of forty MCP servers is a science project. Pick the two tools the first workflow actually needs. Put them behind identity and the gateway. Prove you can deny a method, log a write, and turn a server off. Then add the third.

Personal or public servers stay off the production client. If someone needs one for a spike, time-box it and keep it off customer data.

We do not publish a package of MCP servers. We will tell you whether the first two belong in your environment, or whether you should wait. If you want that read from an engineer, talk to an engineer.