MCP keeps every tool-call logging instruction outside the protocol documents

A consent dialog proves that a person was shown a tool name and an argument block and clicked approve. According to the dev.to post, that is where its value as evidence stops: it does not establish what the server did with those arguments, or whether the result it returned reflected what actually changed ^[5]. Most hosts keep the consent decision in the same transcript store as everything else the model said. That store is written by the runtime under review and editable by whoever administers it ^[6].

The strongest language in the corpus about audit trails is in the section on token passthrough, the anti-pattern where an MCP server forwards a client's upstream token to a downstream API without checking the token was issued to the server ^[9]. Under a heading the document calls "Accountability and Audit Trail Issues", it says the server cannot tell which client is calling, and that "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" ^[10]. The spec's own words for the result are that "incident investigation, controls, and auditing" become more difficult ^[11].

The three logging mentions differ in what they ask of an implementer. One describes that failure mode ^[10]. A second instructs servers to log elevation events, the scope requested against the subset granted, with correlation IDs ^[13]. The third tells proxy services that spawn local servers over stdio to "log all stdio transport usage for security monitoring", a should, and only for proxy architectures ^[14]. A non-proxy server therefore takes one logging instruction out of the corpus, and what it records is a scope grant ^[20].

Annotations are the part I would expect teams to build on, because they look like the metadata a logging policy needs. Four are behavioural: readOnlyHint, destructiveHint, idempotentHint and openWorldHint ^[16]. The schema note says: "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" ^[17]. The tools section restates it as a requirement, that clients must treat annotations as untrusted unless they come from trusted servers ^[18].

Route your logging detail on destructiveHint and you are routing on the server's description of itself. A server that declares a write tool readOnlyHint lands on the light path, and the line you keep says a read-only tool was invoked with no confirmation required ^[22]. The post's point about that line is that it does not record what the tool did ^[19].

Whether any of this reaches a given deployment depends on where the trust boundary sits. If the agent, the host and every tool server are yours, the transcript store is your own record and the annotations are your own claims about your own code. The gap opens when the tool server belongs to someone else, or when the log has to satisfy a reader who does not trust the runtime that wrote it. The spec requires consent before every invocation and leaves the contents of the record, the writer of it, and the method of checking it to the implementer ^[15][21].