What an MCP Server Does When an Agent Calls a Tool

MCP servers process tool calls through a fixed five-step sequence: handshake, discovery, selection, execution, and result handling. Before this protocol existed, connecting M agents to N tools meant building M×N custom integrations, one for every pairing. MCP replaced that mess with a single JSON-RPC standard, cutting the math down to M+N, and the industry noticed fast: server downloads went from around 100,000 in late 2024 to several times over by spring 2025, and the Python and TypeScript SDKs now pull roughly 97 million downloads a month as of early 2026.

In December 2025, the Linux Foundation launched the Agentic AI Foundation with founding support from Anthropic, Block, and OpenAI, plus platinum members including AWS, Bloomberg, Cloudflare, Google, and others, showing the institutional weight behind this. In December 2025, the Linux Foundation launched the Agentic AI Foundation with founding support from Anthropic, Block, and OpenAI, plus platinum members including AWS, Bloomberg, Cloudflare, Google, and Microsoft. Within four months, membership hit 170 organizations. Gartner projects that 40% of enterprise applications will connect to task-specific AI agents by the end of 2026, up from under 5% today. The protocol those agents speak is mostly decided already. What actually happens, mechanically, every time an agent reaches for a tool, and where that sequence is exposed, is the question that matters.

The three roles MCP defines and why the architecture shapes what comes next

MCP splits every interaction into three parts. The Host is the application running the language model, think Claude Desktop, an IDE plugin, or a custom build, and it manages one or more Clients underneath it. The Client lives inside that Host process and holds a strict one-to-one connection with a single MCP Server; if an agent talks to three separate data sources, it spins up three separate Client instances. The Server sits on the other side, exposing tools, resources, and prompts over JSON-RPC 2.0, acting as the translator between the Client and whatever system it wraps, whether that's a database, a file system, or a REST API.

That last point matters more than it sounds. A study looked at 116 official MCP servers and found that 88.6% of them were just wrappers around REST APIs. Most servers aren't inventing new capabilities. They're translating an existing API into a shape a language model can call.

Two transport options carry this traffic, and the choice between them sets the security stakes for everything downstream. stdio handles local, same-machine communication, simple, sandboxed, low-risk by design. Streamable HTTP handles remote, multi-client traffic over HTTPS and server-sent events, and this is where authentication, rate limits, and audit logging stop being nice-to-haves and become load-bearing. Choosing stdio keeps the blast radius of most attacks small. Choosing Streamable HTTP requires the server to defend itself the way any internet-facing service does. Once that architecture is set, the five-step call sequence plays out the same way every time, and so do the places where trust can quietly fail.

Step 1 and 2: handshake, capability negotiation, and tool discovery

Every session opens with a handshake. The Client sends an initialize request stating its protocol version and what it supports. The Server answers with its own capabilities, which primitives it exposes (tools, resources, prompts), and whether those lists can change while the session is live. If the versions don't match, the connection gets torn down right there. That's the first enforcement point in the whole system, and it's a blunt one: either you speak the same protocol or you don't get in.

That detail about dynamic list changes seems minor at first glance, but it isn't. A server that says its tool list can change mid-session is setting up an assumption the agent has to live with later, and that assumption is what rug-pull attacks exploit (more on that shortly).

Step two is discovery, handled through a tools/list request. Instead of an agent shipping with a hardcoded list of tool schemas baked into its code, it asks the server, at connection time, what's actually available. The server responds with names, plain-language descriptions, and parameter schemas written in JSON Schema. The model reads those natural-language descriptions and uses them to decide which tool fits the task and how to fill in the arguments. Nothing else mediates that choice. The wording of a tool's description is doing real work in the model's reasoning, not just documentation busywork.

Scale creates its own drag here. A GitHub MCP server exposing 40 tools can add 10 to 15 KB of schema text to every single conversation turn, and as that catalog grows, tool-selection accuracy tends to slip. The practical fix gaining traction is dynamic tool loading: inject only the schemas the task actually needs at execution time, instead of dumping the entire catalog into context on every turn.

The trust an agent extends to a tool's description at discovery time is precisely what tool poisoning and tool shadowing attacks are built to abuse. Plant a manipulated description in that list, and the agent carries it forward with the same weight as a trusted system instruction. Nothing distinguishes it.

Steps 3, 4, and 5: how the model selects a tool, what the server executes, and how the result re-enters reasoning

Step three is where the model actually acts. It reads the user's intent, then decides, on its own, which tool to call, when to call it, and what arguments to pass in, based on natural language reasoning rather than fixed logic. The output is a structured JSON payload aimed at a specific tool with typed arguments attached. That payload doesn't run automatically. A runtime layer intercepts it first. This argument construction is autonomous. Unlike a normal API call built by a developer who knows what values are going in, here the model's own reasoning is the only thing standing between a legitimate request and a malformed or malicious one, unless something else downstream checks it.

Step four is execution. The Client packages the tools/call request and sends it to the Server with those typed arguments. The Server validates them against the tool's JSON Schema first, that's the server-side gate. Once validation passes, the Server carries out the actual work: an API call, a database query, a file read, whatever the tool wraps. Authentication lives here too. OAuth token lifecycles, refresh flows, API credentials, all of it needs to stay server-side. Leak a credential into the client's context window and it becomes exposed to anything reading that context, a known failure mode called credential-in-context exposure. For anything multi-tenant, the server has to cryptographically bind each request to exactly one tenant. Cross-tenant data leakage carries the weight of a fatal flaw in production MCP deployments, not something dismissed as a minor bug.

Step five closes the loop. The Server returns a result object, and the runtime folds it back into the model's context window. From there the agent can call another tool, summarize what it found, or answer the user directly, and it can chain several of these steps together inside one session, with state held server-side when needed. This is the piece that separates MCP from a plain REST call: the session remembers.

For work that takes longer to finish, MCP added an official extension called Tasks, formalized in the July 2026 specification after appearing as experimental in the March 2026 roadmap. Instead of returning a result directly, the server hands back a task handle, and the client uses that handle to check status, send updates, or cancel the job. That lets an agent fire off expensive work and move on without blocking its own reasoning loop. The 2026 roadmap is upfront that Tasks isn't fully settled yet: retry behavior, how long results stick around before expiring, long-term state handling, these are still open questions. It's foundation, not finished furniture.

Where the sequence breaks: the threat surface each step creates

Five layers carry risk in an MCP deployment: transport and communication, authentication and identity, context integrity and confidentiality, authorization and privilege management, and supply chain security. Each maps almost directly onto a step in the sequence above.

Tool poisoning (cataloged as OWASP MCP03) hits at the discovery phase. An adversary compromises a tool's description or schema, and that poisoned text enters the model's reasoning with the exact same authority as a trusted system instruction, because nothing in the architecture tells the model to treat it differently. It shows up in a few forms: rug pulls, where a previously approved tool gets a malicious update after the fact; schema poisoning, where the interface definition itself is corrupted; and tool shadowing, where a duplicate tool name quietly redirects calls to the wrong server. MCP has no built-in mechanism to catch these injections, which is the structural problem common to all three. The spec only says a human in the loop "SHOULD" be involved, not that one must be.

Rug pulls deserve their own look because they exploit a specific habit: tools usually get approved once, and then nobody re-checks them. A tool can behave exactly as expected for weeks, then silently start doing something else, slipping in hidden commands that leak data or fire off requests the user never authorized, all without tripping any re-approval process. The approval happened once. Nothing said it had to happen again.

Credential aggregation is an execution-phase risk. A server that holds credentials for Slack, GitHub, Postgres, and Salesforce all at once becomes a single point of failure: compromise that one server and every downstream system goes with it. And the numbers here aren't reassuring. Only 8.5% of MCP servers use OAuth, and 1,862 are sitting exposed on the public internet. Most servers simply aren't built with the discipline a multi-system credential store demands.

Prompt injection shows up at the result phase, step five specifically. Hidden instructions buried in a tool's output, a data return, or a scraped web page can hijack the agent's reasoning the moment that result lands back in context. Raw API tokens sitting in a system prompt allow a single injected instruction to exfiltrate them straight out.

Scope creep lives in the authorization layer. Permissions granted temporarily, or defined loosely to begin with, tend to expand rather than shrink, and agents end up holding far more capability than any single task calls for. An attacker who finds weak scope enforcement can ride that excess straight into repository changes, system control, or data theft.

Agentic supply chain vulnerabilities, tracked under OWASP ASI04, come from the registries themselves. Malicious tool descriptors get distributed through public listings using typosquatting, fake version updates, or manipulated schemas, and a trojanized tool can end up wired into MCP infrastructure without the operator ever knowing it happened.

The scale of exposure across independent audits is hard to ignore. Equixly found 43% of tested MCP servers vulnerable to command injection. Endor Labs, scanning 2,614 implementations in 2025, found 82% had file operations prone to path traversal. Enkrypt AI, scanning 1,000 servers, found 33% carrying critical vulnerabilities. That said, methodology swings these numbers hard: an audit from AppSec Santa found YARA-based MCP scanners returning a false-positive rate near 78%, so any bare "X% vulnerable" statistic deserves a second look at how it was measured.

A logging problem keeps every other issue alive longer than it should. Traffic using that remote-procedure-call standard doesn't map cleanly onto traditional SIEM patterns. As a result, most security teams can't reconstruct what actually happened during an attack on those deployments after it's over. More than 30 CVEs were filed against MCP implementations in a single 60-day stretch in early 2026, and most organizations lack the visibility to catch that volume as it happens.

What trust and governance at tool-call depth require

None of this is bad luck. The attack surface exists because natural-language tool descriptions get treated as authoritative, because tools get approved once and then trusted indefinitely, and because credentials for multiple systems keep piling up on servers that were never built to be vaults. Fixing it means intervening at each step of the sequence, not bolting on a single control at the edge.

At the handshake (step 1), identity needs to attach to the session from the very first initialize call, tied into SSO and SCIM rather than scattered per-server credentials that nobody's tracking centrally. Just-in-time credential issuance helps contain the damage from a compromised server: credentials exist only for the length of a task, not sitting on the server indefinitely waiting to be stolen.

At tool-call depth, steps three and four, policy enforcement has to reach down to the individual tools/call request, not stop at "this agent may talk to this server." A server exposing ten tools at ten different privilege levels can't be governed with a single yes/no switch. What's needed is an enterprise-managed model: the organization decides which agents touch which systems, under what conditions, using which identity, rather than leaving authorization to accumulate per user, per server, in a way that stops scaling almost immediately. And scope has to be checked again and again, not assumed stable just because it was approved once.

Back at discovery, tool descriptions need to be treated as untrusted until proven otherwise, meaning version checks and signature verification become the actual defense against rug pulls, not a nice-to-have. Tool shadowing and supply chain attacks call for registry hygiene that tracks provenance, not just tool names that happen to match.

Logging needs a rebuild too. Standard SIEM tooling wasn't built to parse JSON-RPC 2.0, so audit systems have to be purpose-made for MCP's call structure specifically. Tamper-proof logs paired with full OTEL tracing are the baseline for answering a basic question after the fact: what did the agent do, in what order, using which credentials. Right now, that's the exact gap the logging leaves wide open.

Logs alone won't catch everything, either. Prompt injection and tool poisoning happen inside the call itself, so detection has to run in real time, at the moment of the call, not just show up later during a review. Intent drift detection, flagging when an agent's sequence of tool calls starts diverging from what it was actually supposed to be doing, is the kind of check that can catch a problem before data leaves the building rather than after.

None of this works if security is bolted on as friction. Security and IT teams function best here as the infrastructure that makes adoption possible in the first place, not a checkpoint standing in its way. When governance gets built into the foundation instead of layered on top, the secure path and the easy path end up being the same path, and shadow MCP usage, the workaround behavior that occurs whenever governance feels like an obstacle, stops having a reason to exist.