The MCP spec says clients should log tool usage for audit purposes and that servers should log scope elevation events with correlation IDs. It says nothing about log format, retention, tamper protection or who reviews them. Those decisions are left to you, so write them down before the first incident.
What the spec actually says
Two places mention logging. The tools page lists, among client recommendations, that clients should log tool usage for audit purposes. The scope minimization guidance says servers should log elevation events, recording the scope requested and the subset granted, with correlation IDs. The stdio proxy guidance adds that proxy services should log all stdio transport usage.
All of these are shoulds. A client can be fully compliant and keep no audit trail.
What the spec leaves open
| Question | Spec | You decide |
|---|---|---|
| Which fields to record | Not defined | Identity, tool, arguments, result, time |
| Where logs live | Not defined | Central store the agent cannot edit |
| How long to keep them | Not defined | Per your retention rules |
| Tamper protection | Not defined | Append only or signed storage |
| Who reviews | Not defined | A named owner and a schedule |
| How to link steps | Correlation IDs for elevations | One ID per task across tools |
A minimum useful record
For each tool call, aim to capture the agent identity, the human it acted for, the server and tool name, the arguments in redacted form, the outcome, the time and a correlation ID that ties it to the wider task. A separate post on this site covers the fields in more detail.
Redact secrets and personal data before storage. A log that contains tokens becomes a target of its own.
Where logs should be written
If the only log is the one the agent's own process writes, a compromised agent can alter it. Write logs from the client, proxy or server side, ship them off the host, and restrict who can change them. The spec's token passthrough guidance makes a related point: when tokens pass through unchecked, downstream logs show a different identity from the one acting, which makes investigation harder.
Make the logs useful
- Test one scenario: pick an agent action and trace it from prompt to downstream effect.
- Alert on elevation events and on tools called for the first time.
- Review a sample every week, not only after an incident.
- Check that stdio servers write logs to stderr or files, not to the protocol stream.
Safeguard includes policies, gates and guardrails and agent identity so that actions can be tied to a named agent. A free scan is at https://gold.safeguard.sh/scan.
Try it yourself
Watch how a monitoring view records changes over time, and think about what the same view would need to show for agent tool calls.
Click through it at your own pace, or open it full screen.
Quick check
Is client side logging enough?
It is a start, but a client under attack may not be trustworthy. Add logs from a proxy or the downstream system when you can.
Should I log full tool arguments?
Log enough to reconstruct what happened, with secrets and personal data redacted. Keep the raw form only where policy and law allow.
Sources
Last reviewed: 19 October 2026.
