Can You Prove What Your AI Agent Did? I Checked 8,216 MCP Servers.
Your auditor asks: “Show me every action Agent X took on behalf of User Y last Tuesday.”
You check the MCP server logs. There aren’t any. The MCP spec doesn’t define an audit format. The server doesn’t log tool calls. The agent runtime logged a conversation but not the tool-level details. Your database has write operations but no record of which agent — or which user — initiated them.
You can’t answer the question.
I checked whether the MCP ecosystem is ready for this question. It isn’t.
Methodology
I scanned 8,216 MCP servers across three registries (Official MCP Registry, ToolSDK, Awesome MCP Servers). For each server, I:
- Fetched the GitHub README (6,833 successfully retrieved)
- Scanned for audit-related terms:
audit,logging,trace,tracing,monitor,monitoring,observability,telemetry,access log,activity log,event log - For servers without GitHub URLs, scanned descriptions and tool metadata for the same patterns
This is a lower bound. A server could implement logging without documenting it. But if your auditor asks “does this system log tool calls?” and the documentation says nothing, that’s already a problem.
The numbers
| Metric | Count | % |
|---|---|---|
| Servers mentioning audit/logging/tracing | 2,061 | 25.1% |
| Servers with no audit mention | 6,155 | 74.9% |
| Critical/High sensitivity servers with no audit | 1,341 | 73.0% of critical/high |
Three out of four MCP servers have no documented audit capability. Among servers handling critical or high-sensitivity data (databases, cloud platforms, payment processing, email), the rate is the same: 74% have no audit mention.
By category
The categories with the worst audit coverage:
| Category | With Audit | Total | Coverage |
|---|---|---|---|
| Translation services | 1 | 13 | 7.7% |
| Support/service management | 5 | 59 | 8.5% |
| Art and culture | 12 | 117 | 10.3% |
| Location services | 14 | 102 | 13.7% |
| Code execution | 14 | 90 | 15.6% |
| Customer data platforms | 10 | 56 | 17.9% |
| File systems | 37 | 187 | 19.8% |
| Finance/fintech | 102 | 470 | 21.7% |
| Search/data extraction | 98 | 437 | 22.4% |
Finance servers — the category with the highest compliance requirements — have audit coverage of just 21.7%. That means nearly 4 out of 5 financial MCP servers have no documented audit logging.
The “monitoring” category does better (39.6%), which makes sense — these are servers that already deal with observability. But monitoring your monitoring tool isn’t the same as auditing what your agent did.
The spec gap
The MCP specification (as of the 2025-12-11 schema) defines:
- Transport types (stdio, streamable-http, SSE)
- Tool schemas (name, description, input parameters)
- Resource types (URIs for data the server exposes)
- Prompts (templates for the LLM)
It does not define:
- A structured audit log format
- A standard for recording tool invocations
- A mechanism for correlating agent actions with user identity
- A way to request the audit trail for a specific user or session
- Any logging primitives at all
This isn’t an oversight in the ecosystem. It’s an absence in the protocol. Server authors have no standard to implement even if they wanted to.
Compare this with HTTP, where access logs are a convention so universal that every web server implements them by default. Or with database protocols, where query logging is a built-in capability. MCP has no equivalent.
The compliance problem
This matters because AI agents are being deployed into regulated environments. Every major compliance framework requires audit trails for systems that access sensitive data:
| Framework | Requirement | What it means |
|---|---|---|
| SOC 2 CC7.2 | System activity monitoring | You must log and review system activity for anomalies |
| HIPAA §164.312(b) | Audit controls | You must implement mechanisms to record and examine access to ePHI |
| GDPR Article 30 | Records of processing activities | You must maintain records of all data processing operations |
| PCI DSS 10.1 | Audit trail for system components | You must link access to system components to individual users |
The common thread: you must be able to attribute actions to users. Not to service accounts. Not to “the agent.” To the specific human whose request initiated the action.
MCP servers can’t do this. The protocol doesn’t carry user identity. The server doesn’t know who initiated the tool call. Even if it logged every invocation, the log would show “tool X was called with parameters Y” — not “User Z asked Agent A to call tool X.”
What a compliance-ready audit trail looks like
An audit record for an agent tool call needs:
{
"timestamp": "2026-03-30T14:22:01Z",
"user_id": "user_abc123",
"agent_session": "session_xyz",
"tool": "database.query",
"server": "postgres-mcp",
"parameters": { "sql": "SELECT * FROM orders WHERE user_id = $1" },
"result_summary": "47 rows returned",
"latency_ms": 142,
"policy_evaluation": {
"allowed": true,
"rules_matched": ["allow-read-own-orders"],
"scopes": ["orders:read"]
}
}
This record tells you:
- Who: user_abc123 (not a service account)
- What: a database query against the orders table
- When: precise timestamp
- Whether it was allowed: the policy evaluation result
- What happened: 47 rows returned in 142ms
None of this is available from the MCP server alone. The server doesn’t know the user. It doesn’t evaluate policy. It doesn’t correlate with a session. And for 74.9% of servers, it doesn’t log anything at all.
1,341 critical servers with no audit
The scariest number in this dataset: 1,341 servers classified as critical or high sensitivity have no audit documentation. These are database connectors, cloud provisioning tools, payment processors, and CRM integrations.
These servers can:
- Write to production databases
- Provision cloud infrastructure
- Send emails on behalf of users
- Access customer records
- Process financial transactions
And for 74% of them, there is no documented way to answer “what did the agent do, and on whose behalf?”
What to do about it
The fix isn’t asking 8,000+ server authors to implement audit logging. Even if they did, each would implement it differently — different formats, different storage, different retention policies. That doesn’t give you a unified audit trail.
The fix is logging at the layer that sees every tool call: the control plane.
An Agentic Control Plane sits between the agent runtime and the MCP server. Every tool call passes through it. It knows:
- The user’s identity (because it handles the identity binding)
- The policy evaluation (because it enforces authorization)
- The full request and response (because it proxies the call)
This is the explicabl pattern. The MCP server doesn’t need to log. The control plane logs everything, in a structured format, with user attribution, queryable and exportable for compliance.
The server does what it does. The control plane records what it did. Your auditor gets the answer.
Methodology notes
Audit coverage assessed via pattern matching on README content and server descriptions. Terms searched: audit, logging, trace/tracing, monitor/monitoring, observability, telemetry, access log, activity log, event log.
This is a documentation scan, not a code audit. A server could implement logging without documenting it. The reported 25.1% coverage is a ceiling on documented audit capability, which is what matters for compliance assessments — if you can’t point to documentation showing the system logs access, the auditor won’t accept “trust us, it probably does.”
Read the reference architecture → · Get started free →