What to log when an AI agent calls a tool over MCP — and what logs can prove

The Model Context Protocol (MCP) has settled in as the standard route for AI agents reaching external tools, and that convenience comes with a blind spot: the protocol specifies how a call is made while saying almost nothing about how it should be recorded. A recent analysis on dev.to walks through the current specification, maps where tool calls actually get written down today, and argues that most of those records would not survive contact with a sceptical auditor.

Consent is not evidence

According to the dev.to piece, the 2025-11-25 revision of the MCP spec is direct about risk: tools amount to running arbitrary code, hosts must obtain explicit user consent before invoking any tool, and clients should confirm sensitive operations and surface tool inputs before sending them. All of that governs permission rather than proof. A consent dialog shows that a person saw a tool name and an argument list and clicked yes; it says nothing about what the server did with those arguments or whether the returned result matched the actual change. Consent decisions are also typically stored in the same transcript as everything else the model produced, a store written by the very runtime under review and editable by whoever administers it.

What the official documents say

The protocol documents themselves contain no logging requirement for tool calls. Logging appears only in the companion security best practices guide, in three places, the analysis finds:

• Token passthrough: when an MCP server blindly forwards a client's token to a downstream API, the downstream logs can attribute actions to the wrong identity, which the spec acknowledges makes incident investigation and auditing harder, an implicit admission that a log kept by the wrong party can be actively misleading.
• Scope minimisation: broad catch-all scopes hide user intent per operation, so servers are told to log elevation events, recording the scope requested versus the subset granted, with correlation IDs.
• Proxy guidance: proxies that spawn local servers over stdio should log all such transport usage, a recommendation that applies only to that architecture.

The cumulative position, per the source, is to log identity, log scope changes and log process spawns. Sensible, but thin: nothing defines what a record should contain, who writes it, or how anyone verifies it later.

Annotations describe intentions, not behaviour

Tools can carry behavioural annotations such as readOnlyHint and destructiveHint, and a host deciding which calls need a human in the loop, or which to record in detail, will naturally lean on them. But the schema states these are hints that may not faithfully describe behaviour, and clients must treat annotations from untrusted servers as untrusted. A log line asserting that a read-only tool ran without confirmation therefore records the tool author's claim, not the observed effect. If a server is swapped, updated or compromised through the content it serves, the annotation is exactly the field an attacker would set.

Four traces, none independent

Following a single call through a typical deployment, the dev.to author identifies four records: the host's transcript (complete but self-written), the MCP server's own log (controlled by you, or by a vendor who may only share it at their discretion), the downstream system's log (the best available account of what actually changed, but prone to misattribution through token passthrough or shared service accounts), and the user's approval (stored in the host, so it collapses into the first bucket). None is signed, and none is bound to the code that ran, since tool names need only be unique within a server and the same name can point at different code tomorrow. The proposed test: for each record, ask who wrote it and whether they had the ability, and any reason, to write something else. If the writer is the agent or the tool, the record is a claim by an interested party.

What a durable record would contain

The shape of a fix 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 with hashed arguments, a hash of the result, the authorising identity and the mechanism behind it (interactive consent, allowlist, or scope elevation with its correlation ID), and the sandbox profile the call ran under. Then sign the whole thing with a key the agent process cannot reach and store it somewhere append-only that a third party can check. The source notes this mirrors Traceseal's execution receipts, which bind 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, with a single-command verifier.

Why it matters

MCP is now the default integration layer for agents touching production systems: repositories, databases, ticketing APIs. Every compliance regime that applies to those systems implicitly applies to the agents acting on them, and incident response depends on records that people outside your runtime can trust. Until the protocol grows a logging story, teams wiring agents to real tools are generating activity without generating evidence, and that difference only becomes visible after something goes wrong.