MCP servers are infrastructure. Run them like it.

The first MCP server anyone ships is a demo. It runs on a laptop, it has no auth, and it works beautifully for exactly one afternoon. Then someone connects a real agent to it, the agent calls a tool 400 times in an hour, and the demo becomes a production incident with no logs, no rate limits, and no owner.

We have spent the last year running hosted MCP servers for teams whose agents do real work: filing invoices, updating orders, querying identity. This post is what changed in how we think about MCP once tool calls started carrying consequences.

A tool call is a production request

When a human misreads your docs, they retry. When an agent misreads your schema, it retries 60 times a minute with slightly different arguments, then confidently reports success to its user. The bar for correctness is higher, not lower, than a public REST API.

That means the boring infrastructure questions come first: who is calling, with what key, at what rate, and what happens when the answer is "too much." Every tool needs an owner, every key needs a scope, and every call needs to land in a log someone can query at 2am.

"The difference between a demo and infrastructure is not the code. It is whether anyone can answer: which agent broke this, and when?"

What we watch on every server

Four numbers tell you almost everything about an MCP server's health. We put them on the front page of every server dashboard:

1. Requests per agent. One agent doing 80% of your traffic is either your best integration or a retry loop. Both need to be known.
2. p95 latency, streaming included. Agents time out and retry. A slow tool does not just feel slow, it multiplies traffic.
3. Error rate per tool. A single tool with a missing output schema will quietly poison every conversation that touches it.
4. Token cost per call. Verbose tool outputs are a tax on every agent turn. We have seen a single unpaginated list endpoint double a team's token bill.

Schemas are the contract

Every MCP tool is a promise about inputs and outputs. Agents hold you to it literally. The failure mode is not an error, it is an agent acting on a field that no longer exists.

So we treat tool schemas the way we treat API contracts: versioned, diffed on every commit, and gated. If a change removes a field an agent depends on, the publish is blocked until someone approves it and the changelog says so. That single policy has prevented more agent incidents than any amount of prompt engineering.

▸ elva contract check payouts-partner
✗ breaking: response field "buildLog" removed from GET /builds/{id}
  policy: block-publish · 3 stakeholders notified
  publish blocked until approved in Elva

Fewer, better tools

The temptation is to expose all 214 endpoints as 214 tools. Resist it. Agents pick tools by reading descriptions, and a crowded toolbox makes every choice worse. Our best-performing servers expose 15 to 25 tools with unambiguous names, rich descriptions, and typed outputs, curated from a much larger catalog.

This is where scoring earns its keep. If an endpoint scores poorly on AI readiness, missing descriptions, loose types, ambiguous auth, it does not go in the server until it is fixed. The score is not a vanity metric. It is the admission test for the toolbox.

Run it like you mean it

None of this is exotic. Auth, logging, rate limits, versioned contracts, curated interfaces: it is the same discipline every production API already deserves. MCP just removes the human buffer that used to absorb the sloppiness.

The agents are already calling. The only question is whether what answers them is a demo or infrastructure.