The Model Context Protocol has become the default way an AI agent reaches a tool. That is convenient for the people wiring agents up and awkward for the people who later have to answer for what those agents did, because the protocol standardises the call and says almost nothing about the record. This piece goes through what the current spec actually asks you to log, where a tool call gets written down today, and what each of those records can and cannot establish when someone who does not trust you asks.
The 2025-11-25 revision of the specification is blunt about what a tool is. Under its key principles: "Tools represent arbitrary code execution and must be treated with appropriate caution," and "Hosts must obtain explicit user consent before invoking any tool." The tools section adds that clients should prompt for confirmation on sensitive operations and show tool inputs to the user before sending them to the server.
All of that is about permission. None of it is about evidence. A consent dialog establishes that a person was shown a tool name and an argument block and clicked approve. It does not establish what the server did with those arguments, whether the result it returned reflected what changed, or whether the dialog the person saw was the one the model intended. Most hosts keep the consent decision in the same transcript store as everything else the model said, which puts it in the same position as any other line of that transcript: written by the runtime under review, editable by whoever administers the store. We went through why that fails an auditor's test in the SOC 2 piece.
The protocol documents proper contain no logging requirement for tool calls. What exists lives in the security best practices document, which sits alongside the authorisation spec rather than inside it, and it appears in three places.
The first is the section on token passthrough, the anti-pattern where an MCP server forwards a client's upstream token to a downstream API without checking it was issued to the server. The document lists the consequences under a heading it calls "Accountability and Audit Trail Issues": the server cannot tell which client is calling, and "the downstream Resource Server's logs may show requests that appear to come from a different source with a different identity, rather than the MCP server that is actually forwarding the tokens." The spec's own words for the result are that "incident investigation, controls, and auditing" become more difficult. It is one of the clearer statements anywhere in the MCP corpus that a log written by the wrong party is worse than useful.
The second is scope minimisation, where broad omnibus scopes are said to obscure audit trails because "a single omnibus scope masks user intent per operation." The mitigation includes a concrete instruction to servers: log elevation events, meaning the scope requested and the subset granted, with correlation IDs.
The third is in the proxy guidance, where proxy services that spawn local servers over stdio are told to "log all stdio transport usage for security monitoring." That is a should, not a must, and it applies only to proxy architectures.
So the sum of the spec's position is: log identity so the downstream system does not attribute your agent's actions to someone else, log scope changes so intent per operation is recoverable, and log process spawns if you proxy. Sensible, and thin. Nothing here says what a record of a tool call should contain, who should write it, or how anyone would check it later.
There is a detail in the tools spec that matters more for logging than it first appears. Tools can carry annotations, of which four are behavioural: readOnlyHint, destructiveHint, idempotentHint and openWorldHint. A host that wants to decide which calls need a human in the loop, or which calls to record in detail, will naturally reach for these. The schema says, in a note that is easy to skim past:
All properties in ToolAnnotations are hints. They are not guaranteed to provide a faithful description of tool behavior (including descriptive properties like title). Clients should never make tool use decisions based on ToolAnnotations received from untrusted servers.
The tools section restates it as a requirement: clients must consider annotations untrusted unless they come from trusted servers. Which means a log line reading read-only tool invoked, no confirmation required is not recording what the tool did. It is recording what the tool's author said the tool does, and the author is a party whose code the agent is about to execute. If the server was swapped, updated or compromised through the content it serves, the annotation is exactly the field an attacker would set to true. A record that inherits its risk classification from the server being classified has the same structural flaw as a transcript written by the agent being audited.
Follow one call through a typical deployment and it leaves traces in four places, each written by a different party with a different interest.
None of the four is signed by anyone. None is bound to the code that ran: the host records a tool name, and tool names are only required to be unique within a server, so the same name can point at different code tomorrow. And none of them can be handed to a third party without also handing over the trust you place in whoever wrote it. That is the gap between having logs and having evidence, and it is the gap that the receipts primer is about.
The test worth applying: for each record of a tool call, ask who wrote it and whether they had the ability, and any reason, to write something else. If the answer to the first is "the agent" or "the tool", the record is testimony, not evidence.
If the aim is a record that survives that test, the shape is not exotic. Per call, capture the server's identity as a hash of its code or manifest rather than its display name, the tool name and a hash of the exact arguments, a hash of the result, the identity that authorised the call and how (interactive consent, allowlist, or scope elevation with its correlation ID), and the constraints the call ran under, meaning the sandbox profile if there was one. Then sign the whole thing with a key the agent process cannot reach, and put the signature somewhere append-only that a third party can check.
That is deliberately the shape of a Traceseal execution receipt. The specification binds a skill manifest hash, a sandbox profile hash, input and output hashes, exit code and timing under an ed25519 signature from an operator key that never enters the sandbox, and the verifier is a single command that needs nothing but the receipt. The walkthrough shows what an [OK] does and does not establish.
Two limits, stated plainly. A receipt covers what passes through the receipting boundary. A local MCP server launched over stdio runs with the client's privileges, and the security document is explicit that without sandboxing it can read anything the client can; if the agent can reach a tool through a path that produces no receipt, the receipt for the path it did use proves nothing about the other one. And a receipt records that a hashed input produced a hashed output under a hashed policy. It does not say the output was correct or the policy adequate. Our sandbox write-up covers where a containment boundary stops being demonstrable, and the same line applies here.
The spec does not define a log format for tool calls, does not require servers to identify their code by hash, and leaves annotation trust to each client's judgement of which servers are "trusted". Every host currently records tool use in its own shape, which means two organisations that both "log all MCP calls" have records that cannot be compared, let alone verified by the same tool. Whether that changes depends on the protocol's maintainers and the vendors shipping hosts, not on anything a single deployment can do.
What a single deployment can do is stop treating the transcript as the record. The spec has already conceded that tools are arbitrary code execution and that a tool's own description of itself cannot be trusted. The consistent next step is to conclude that the tool's, and the agent's, description of what happened cannot be trusted either, and to keep a record they did not write.
Originally published at traceseal.io. Traceseal issues signed execution receipts for AI agents: an open spec and an open verifier, one command to check.