The Five-Step Breakdown of MCP Tool Calls: How AI Actually Executes Actions

An Overlooked Truth: The Model Itself Never Calls Any Tools

AI models can look up bugs on GitHub, send emails, and operate databases—that's the intuition many people have. But the fact is, models only write text; they cannot execute any operation.

So who is calling tools on your behalf? A technical explainer video on YouTube breaks down the MCP (Model Context Protocol) tool-calling mechanism into five steps using a complete request chain. Understand these five steps, and you'll see clearly where an AI Agent's "action capability" really comes from—and why the quality of tool descriptions directly determines an Agent's reliability.

The Five-Step Chain: From Question to Answer

The video runs a single concrete scenario throughout: you tell the AI, "Find unfixed bugs about login." Every step that follows is worth examining closely.

Step 1: The Client Requests the Tool List from the Server

The starting point of the request isn't the model—it's the client. The client first requests the list of available tools from the GitHub server. Each tool returns three things: a name, a description, and the schema for its input parameters.

This step is the cornerstone of the whole mechanism. The tool list isn't hardcoded into the model; it's fetched dynamically at runtime—which means the server's toolset can be added to, removed from, or changed at any time, and the world the model sees updates accordingly.

MCP (Model Context Protocol) is an open protocol proposed by Anthropic in late 2024, aimed at standardizing how AI models interact with external tools and data sources. It borrows the design philosophy of the Language Server Protocol (LSP), abstracting "how models discover and call tools" into a client-server architecture: MCP servers expose tools, resources, and prompt templates, while MCP clients (usually implemented by a host application) connect to servers and translate capabilities for the model. The protocol defines a JSON-RPC-based communication format, allowing the same server to be reused by different models and different hosts. Understanding MCP's positioning matters—it doesn't execute tools, nor does it enhance the model; rather, it solves the standardization problem of "how models learn about and request external capabilities in a unified way," which is precisely the premise that makes the five-step chain possible.

Step 2: The Host Stuffs the Tool Descriptions into the Model's Context

After receiving the tool list, the host does one thing: it puts the description text of these tools into the model's context.

Here lies the most easily underestimated detail—the model's entire knowledge of a tool is that description text. It doesn't know whether the tool is backed by the GitHub API or a local script, doesn't know whether the execution logic is safe; it only knows "what the description says." Write a vague description, and the model will pick the wrong tool or fill in the wrong parameters.

The input parameter schema is typically described using the JSON Schema format, specifying which parameters the tool accepts, each parameter's type (string, number, enum, etc.), whether it's required, and its range of values. When generating a call request, the model constructs the parameter object according to the schema constraints. The more precise the schema, the lower the chance the model fills in parameters incorrectly; conversely, if the schema is too loose (for example, everything is a string type with no enum restrictions), the model may pass in values the server can't parse. In MCP, the schemas in the tool list are injected into the context alongside the description text, so they aren't just a server-side validation basis—they're also the model's only instruction manual when "filling out the form." Tool developers should design schemas as interface documentation aimed at the model, not merely for backend validation.

Step 3: The Model Selects a Tool and Fills in Inputs

The model reads your question, picks the search_issues tool from the context, and fills in the parameters: label as bug, query as login.

But the key limitation appears again: the model can't run anything; it only writes out a structured request text. What the model outputs is "an expression of intent," not "the execution of an action." This distinction is the key to understanding the entire MCP architecture.

Step 4: The Host Requests Authorization, the Client Issues the Call

The request the model wrote goes first to the host. The host shows it to you and asks for permission. You click approve, and only then does the client actually send the call to the server.

This step is the safety valve. Tool calls aren't decided by the model; human approval is a mandatory link in the chain. For sensitive operations (writing to a database, sending messages, deleting files), this design determines whether an Agent can be trusted.

The host is the top-level program running an AI application, such as an IDE plugin, a chat client, or an Agent framework. It manages the model session, connects to one or more MCP clients, and acts as the intermediary between the user and tool calls. In the authorization step, the host decides how to present the call request to the user—it can be a confirmation popup, a command-line prompt, or automatic approval of read-only operations based on policy. The host also handles aggregating tool lists from multiple servers, maintaining the context window, and keeping audit logs. In other words, the host is the orchestration layer between "model capabilities" and "the real world": the model can't see the server, and the server doesn't know the model—all connections, authorization, and context assembly are done by the host. This also explains why the host's security policy directly determines the trust boundary of an Agent.

Step 5: The Server Executes and Returns, the Model Answers

After receiving the call, the server queries the real GitHub API and returns the result. The result re-enters the model's context, and the model writes the final answer based on it: "Three unfixed bugs, with links."

Why Developers Should Remember These Five Steps

Compress this chain into five verbs: list, select, approve, call, answer. The video emphasizes at the end that every tool call follows this pattern.

The practical value of this abstraction: when debugging an Agent, any anomaly can be traced to a specific link. Model picks the wrong tool? The problem is in the description quality at Step 2. Parameters filled in wrong? Check whether the schema is clear. Call rejected? That's the authorization policy at Step 4. Result not used correctly? Look back at the context injection at Step 5.

Another noteworthy implication is the security boundary. Since the model can only "write text," all real-world impact happens on the server side and the host side. This means permission control, audit logs, and human confirmation are the real defense lines of an Agent system—not the model's own "self-discipline."

An Easily Overlooked Design Philosophy

MCP completely decouples "model capability" from "tool execution." The model always stays at the text layer, and tool calls are completed externally through a standardized protocol. This separation brings two benefits: the model can connect to any server that implements the protocol, and the server doesn't need to care which model is running inside.

The cost is that description text becomes a single point of failure. Write a poor tool description, and even the strongest model will pick the wrong tool; define a loose schema, and the parameters will go wrong. For tool developers, writing a good tool description is no less important than writing the execution logic correctly.

The next time your Agent calls the wrong tool, try tracing back through these five steps—the problem often isn't the model, but some overlooked link in the chain.

One-line Summary

The five-step MCP tool-calling chain reveals: the model only writes text; the real operations are done by the client and server.

Paragraph Summary

The article clarifies a common misconception: AI models themselves cannot call any tools—they can only generate text. Through a "find unfixed login bugs" scenario, the article breaks down the five-step call chain under the MCP protocol—the client fetches the tool list from the server, the host injects tool descriptions into the model's context, the model selects a tool and fills in parameters, the host requests human authorization before the client issues the call, and the server executes and returns results for the model to answer. The article stresses that the model's entire knowledge of tools comes only from the description text, so the quality of descriptions and schemas directly determines an Agent's reliability; the human authorization step is the safety valve. When debugging Agent anomalies, you can trace through these five steps to locate the problem link by link—most errors stem from descriptions or schemas, not from the model's capability.