A friend asked me last week: "With MCP, can we trace who is doing what? Most MCPs don't have any traces or logs when someone uses them."
He's correct. People have thought about it, but the tooling isn't there yet. Extensive observability for MCP, agent-to-agent (A2A) calls, and AI tool calling in general is still an open problem. The frameworks are new, the standards are unsettled, and most existing logging infrastructure was built around HTTP requests made by humans or deterministic services, not around a model deciding at runtime which tools to call and with what arguments. Awareness of the gap is ahead of the solutions for closing it.
What MCP Actually Hands Out
MCP is not a read-only chat interface. It is a protocol for giving an LLM structured access to tools: your APIs, your databases, your infrastructure. Through an MCP server, Claude or Cursor can:
- silence an alert,
- delete a record,
- push a config change,
- trigger a deployment.
No human clicked anything. No form was submitted. No approval was requested. The action just happened.
Most teams ship an MCP server as a feature without registering what they just handed out: write access to production, delegated to a model, with no record of what it does.
The Compliance Problem
Something will go wrong. An alert gets deleted. A record disappears. A config changes in a way that takes the service down. This is not speculation; it is the natural consequence of giving any caller write access to production without testing every code path it will ever reach.
When the auditor asks who deleted that alert at 3am, "an AI agent, probably" is not an answer. The compliance team does not care that it was an LLM. They care that you cannot say who authorised the action, what parameters were passed, or whether it was intentional. Every regulatory framework that requires an audit trail requires it regardless of whether the actor is human or automated. The MCP client is not a special case.
And the blast radius is wider than it looks. Most MCP servers today authenticate with a service account that has broad permissions, because scoping access tightly requires knowing in advance exactly what the model will try to do. You do not know that. So the service account has more access than any individual human in your organisation, and the model can reach all of it, and there is no log.
The Fix Is Not New
MCP is just another caller hitting the same API. The agent does not get a separate category of access. It authenticates, it calls an endpoint, it gets a response. That the caller is an LLM rather than a human in a browser does not change the shape of the HTTP request.
That means the fix is the same fix you would apply to any other caller with write access: route every action through the audit log.
- who called it,
- when,
- with what parameters,
- and what the result was.
If your API already emits an audit event for human actions and the MCP server calls the same API, the event fires for the agent too. You did not build a separate "MCP logging" feature. It lands in the same place everything else already lands.
OpenObserve works this way. An LLM talking through MCP shows up in the audit trail the same way a human in the UI does, because MCP is just another caller hitting the same API. The audit log does not need to know it is an LLM. It needs to know the action, the identity, and the timestamp. The model fills those fields the same way any other client does.
When the Audit Log Stops Being Optional
If your MCP server is read-only, an audit trail is still good practice, but the urgency is low. You can reconstruct what happened from other signals.
The moment the MCP server can write to production, the audit log is not optional. It is the only thing that answers the question "who did that" when the answer is not a person. You cannot go back and add it after the incident. You cannot reconstruct it from memory. Either the event was recorded when it happened, or it was not recorded at all.
Ship the audit log before you ship the MCP server. Not after the first incident. Before.
A friend asked: "With MCP, can we trace who is doing what? Most MCPs don't have any traces or logs." He's right. Observability for MCP, agent-to-agent calls, and AI tool-calling in general is still an open problem: most logging was built around HTTP requests made by humans or deterministic services, not around a model deciding at runtime which tools to call and with what arguments.
What MCP hands out
MCP isn't a read-only chat interface. It gives an LLM structured access to your tools: your APIs, your databases, your infrastructure. Through an MCP server, a model can:
- silence an alert;
- delete a record;
- push a config change;
- trigger a deployment.
No human clicked anything, no form was submitted, no approval was requested. Most teams ship an MCP server as a feature without registering what they just handed out: write access to production, delegated to a model, with no record of what it does.
Why it's a compliance problem
Something will go wrong, an alert deleted, a record gone, a config change that takes the service down. When the auditor asks who deleted that alert at 3am, "an AI agent, probably" is not an answer. Every regulatory framework that requires an audit trail requires it whether the actor is human or automated; the MCP client isn't a special case.
And the blast radius is wide: most MCP servers authenticate with a broad service account, because scoping access tightly means knowing in advance what the model will try to do, and you don't. So the agent can reach more than any individual human in your org, and there is no log.
"An AI agent, probably" is not an answer to "who deleted that alert at 3am."
The fix isn't new
MCP is just another caller hitting the same API. It authenticates, calls an endpoint, gets a response; the caller being an LLM doesn't change the shape of the request. So the fix is the one you'd apply to any caller with write access: route every action through the audit log.
- who called it;
- when;
- with what parameters;
- what the result was.
If your API already emits an audit event for human actions and the MCP server calls the same API, the event fires for the agent too, with no separate "MCP logging" feature. Read-only, an audit trail is good practice. The moment the server can write to production, it is the only thing that answers "who did that," and you cannot add it after the incident. Ship the audit log before you ship the MCP server.