Here's what crosses the wire when an MCP client calls a tool:
{
"jsonrpc": "2.0",
"id": 2,
"method": "tools/call",
"params": {
"name": "get_weather",
"arguments": {
"location": "New York"
}
}
}That's the complete method-specific request. A name (required) and arguments (optional, a dictionary of whatever the tool expects). The JSON-RPC envelope adds an id and method. There is no field for who authorized this call, under what policy, with what scope, referencing which approval, or capturing what state existed before the action fired. Those concepts have no named place in CallToolRequest.
The response matches:
interface CallToolResult {
content: ContentBlock[];
structuredContent?: { [key: string]: unknown };
isError?: boolean;
}Content comes back as text, images, audio, or resource links. An optional error flag. An optional structured object. The result tells you what happened. It carries nothing about whether the action had authority to happen.
One step earlier, at discovery: when a client calls tools/list, each Tool object arrives with a name, description, input schema, and optional behavioral hints like readOnlyHint or destructiveHint. The spec is explicit that these annotations are "not guaranteed to be faithful" and should be treated as untrusted unless the server is trusted. So at discovery time, an organization learns how to call a tool and gets non-authoritative signals about what it might do. Nothing about who should call it, under what conditions, or what happens if the action needs reversal.
Where does authorization live? At the transport layer. MCP defines an OAuth 2.1-based flow for HTTP transports, with bearer tokens in the Authorization header. The token travels with every HTTP request but never enters the JSON-RPC body. The call payload and the authorization evidence exist in structurally separate layers. A tool receives name and arguments. The fact that an authorized session delivered them is a property of the connection. The invocation itself knows nothing about it.
This separation has a concrete consequence. A measurement study of 7,973 live MCP servers found roughly 40% exposing tools without authentication at all. When authorization is absent, the tool call looks identical. The payload doesn't change. No field goes empty. The call simply arrives without the transport-layer context that was already structurally separate from it.
When auth is missing, nothing in the payload changes. The call looks the same either way.
And even when transport-layer auth is present, it answers a narrower question than organizations actually need answered. A bearer token confirms the session is valid. It says nothing about whether the person behind the session had authority to take this specific action at this specific moment. An organizationally meaningful invocation would need to carry: which mandate authorized this action, what scope bounded it, a reference to an approval record, a snapshot of relevant state before the action fired, enough information to support dispute or reversal. In the current spec, every one of those would need to be packed into the generic arguments dictionary or into _meta (an optional metadata field in the request params, with no standardized semantics for organizational context). They'd be implementation-specific additions riding on surfaces designed for other purposes.
The spec does recommend that clients "log tool usage for audit purposes" and "prompt for confirmation on sensitive operations." Good advice. But recommendations addressed to client implementations are different from fields in the protocol. They describe practices that should wrap around a tool call. The call itself still carries the same fields either way.
What remains in the payload is a name, some arguments, and a result. Enough to execute. Authorization, scope, reversibility — those live somewhere else, if they live anywhere at all.
- Identical logs, different authority: A June 2026 preprint argues that standard audit logs can look identical under incompatible delegation assignments, meaning execution traces alone cannot reconstruct whether an agent's action was properly authorized.
- Tool poisoning through metadata: A March 2026 threat-modeling study found that malicious tool descriptions were the most prevalent client-side vulnerability across seven major MCP clients, which matters more when tool annotations are explicitly labeled as untrustworthy by the spec itself.
- Task success versus safe handling: An AI Safety Institute evaluation found that agents completing tasks correctly still made data-handling errors like unnecessary access or inappropriate disclosure, separating "the tool call worked" from "the tool call was acceptable."
- Pass@1 versus pass@8 reliability: Tau-bench showed that agents succeeding on individual attempts dropped below 25% success when measured across eight consecutive retail trials, a gap that matters when tool calls need to be not just possible but consistently accountable.