--- title: "What's Inside a Tool Call" canonical: "https://current.tinyfish.ai/issue/37/foundations/article/29911/whats-inside-a-tool-call" publication: "TinyFish" publisher: "TinyFish" language: "en-US" guide: "https://current.tinyfish.ai/llms.txt" format: "Reading the Spec" author: "Rina Takahashi" author_url: "https://current.tinyfish.ai/team/25" issue: 37 section: "foundations" section_name: "Foundations" published: 2026-07-08 updated: 2026-07-09 description: "MCP tool calls carry enough to execute an action but nothing about who authorized it, under what scope, or how to reverse it." word_count: 764 source_links: 8 --- # What's Inside a Tool Call *By [Rina Takahashi]()* *July 8, 2026* [Read on the website]() Here's what crosses the wire when an MCP client [calls a tool](https://modelcontextprotocol.io/specification/2025-06-18/server/tools): ```json { "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: ```ts 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](https://modelcontextprotocol.io/specification/2025-06-18/schema) 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](https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization). 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](https://arxiv.org/abs/2605.22333) 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. ## Things to follow up on... - **Identical logs, different authority:** A June 2026 preprint argues that [standard audit logs can look identical under incompatible delegation assignments](https://arxiv.org/abs/2606.09692), 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](https://arxiv.org/abs/2603.22489) 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](https://arxiv.org/abs/2606.17114) 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](https://collaborate.princeton.edu/en/publications/%CF%84-bench-a-benchmark-for-tool-agent-user-interaction-in-real-world/), a gap that matters when tool calls need to be not just possible but consistently accountable. ## More - [Foundations — Issue 37]() - [Issue 37]() - [Publication guide]()