What's Inside a Tool Call

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.

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.