MCP server intake: a registration record that survives review

Govern MCP tools before your agents get them

Companion to "Govern MCP tools before your agents get them". Engineering reference, not security advice for a specific deployment.

The test for this record is not whether it exists. It is whether, eleven months from now, you can say which tools an agent could reach on a given day and what those tools were defined to do at the time.

1. The server record

Fields a reviewer should be able to read without asking anyone:

Provenance. Who publishes it, from which repository or registry, at which version or commit. Transport. Local process, HTTP, or hosted by a third party. A hosted server means someone else's incident is your incident. Authentication posture. How the server authenticates to its upstream, where those credentials live, and what their blast radius is if leaked. Trust classification. Yours, not the server's. First-party, vendor-supported, or community. Approver and date. A name, not a team. Last reviewed. With a review interval that matches the trust classification. Endpoints it backs. One server frequently backs several, and the blast radius is the union.

2. Per-tool classification

Do this per tool. A server is not a unit of risk.

Every exposed tool is classified as read, write, or destructive, by you. The server's own annotations (read-only, destructive, idempotent, open-world) are recorded alongside your classification, and where the two disagree, yours governs and the disagreement is itself a finding. Unannotated tools are treated as destructive and open-world, which is the specification's own default. Tools that return content controlled by an outside party are marked, because their output is untrusted text entering the model's context. Tools that can send data outside the boundary are marked separately from tools that merely reach the network. Tools nobody could name a use case for are not exposed. This removes more risk than any other line on this list.

3. Definition pinning and change control

The gap between approval and the next human review is the window a rug pull needs.

Tool name, description, and input schema are hashed at approval, and the hash is stored with the record. A change to any of those is detected rather than silently reloaded. A material change requires re-approval before the tool is available again. The diff is retained, so "what was this tool allowed to do in March" is answerable from storage. A newly appearing tool on an approved server is not automatically exposed. Appearance is a change event. Scanning for poisoned descriptions runs at intake and on change, understood as a point-in-time check rather than a standing guarantee.

4. Composition review, per endpoint

Judged on the union of tools an agent can reach, not server by server.

Does this endpoint give one agent access to private data, content controlled by outsiders, and a way to send data out? If all three, say why that is acceptable, or remove one. Which tool in this set is the egress path? There is usually exactly one, and it is usually not the one people worry about. Would a compromised tool result be able to steer the agent into calling the destructive tools in this set? Does the agent need the destructive tools for the job it was approved to do, or did they arrive because they shipped in the same server?

5. Runtime posture

Destructive tools require confirmation, and the confirmation surfaces the actual arguments. Tool calls pass through the same path as model calls, so one record covers the chain. Tool results are subject to the same inspection as prompts, since they are untrusted input arriving mid-conversation. Failure mode is defined: if the governance layer cannot classify a tool, the call stops rather than proceeding. Rate and budget limits apply per agent, not only per user.

6. The record, per tool call

Which endpoint, which server, which tool, which version of the definition. The arguments, subject to the same redaction standard as a prompt. The result, marked as untrusted content. The approval that made this tool available to this agent. The whole run as one chain, so model turns and tool calls read in order rather than as unrelated calls in three systems.

A note on scanning versus structure

Every control on this list is cheaper than the incident, but they are not equally leveraged. In rough order of value per hour spent:

1. Not exposing tools nobody needs.
2. Pinning definitions and treating change as an event.
3. Classifying per tool on your side rather than trusting server metadata.
4. Reviewing composition per endpoint.
5. Scanning descriptions.

Scanning is last not because it is useless, but because it answers a question about this moment, and every other item on the list answers a question about every moment after it.