MCP Protocol Explained: The Unified Standard and Complete Workflow for LLM Tool Calling

MCP is the unified communication standard for standardizing LLM tool calling
MCP (Model Context Protocol) is an open-source protocol released by Anthropic in 2024 to unify communication standards between LLMs and tools. It defines five core roles—Host, LLM, MCP Client, MCP Server, and Tools—and implements standardized tool discovery, invocation, and result return workflows through JSON-RPC 2.0 message format, reducing development costs, improving cross-platform compatibility, and serving as critical infrastructure for building AI Agents.
What is the MCP Protocol?
MCP (Model Context Protocol) is a standardized specification protocol for LLM tool calling. Its core purpose is to build a unified communication bridge between large language models and various tools, solving the pain point of inconsistent tool calling methods and the need to repeatedly write adapter code.
The MCP protocol was officially released and open-sourced by Anthropic in November 2024, aiming to address the fragmentation of tool calling in the LLM ecosystem. Before MCP, OpenAI's Function Calling, LangChain's Tool interface, and others each defined different tool calling specifications, forcing developers to write adapter code repeatedly for different platforms. The emergence of MCP is similar to how the USB interface unified peripheral connection standards—it provides an open, vendor-neutral interoperability protocol for the AI tool ecosystem.
Simply put, the MCP protocol is like a "rulebook" that defines the request format, response format, and interaction rules for LLM tool calling, enabling developers to standardize and streamline tool invocation without writing custom adapter code for each tool.
It's worth noting that MCP has a close relationship with LLM Function Calling capabilities. Function Calling is the foundational mechanism that gives LLMs the ability to call tools, first introduced by OpenAI in GPT-3.5/4. It allows models to output structured function call requests (including function names and parameters) during inference, rather than plain text responses. MCP can be understood as a higher-level standardized wrapper around Function Calling—it doesn't replace Function Calling capabilities but rather standardizes the complete communication pipeline from the model generating a call intent, to actual tool execution, to result return, making it universal across platforms and models.

Core Roles in the MCP Protocol
The MCP protocol defines five core roles, each with clear responsibilities that work together to complete the entire tool calling workflow.
MCP Server
The MCP Server is like a "toolbox"—a centralized management container for various tools. It internally stores and deploys pre-built tools that are ready to be called. Its core responsibilities include:
- Receiving tool call requests from the MCP Client
- Finding the corresponding tool in the toolbox and executing it
- Returning execution results to the MCP Client according to protocol specifications
The MCP Server also features an important Capability Declaration mechanism. When an MCP Client first connects to a Server, a "handshake" process occurs where the Server returns its supported tool list, functional descriptions of each tool, JSON Schema definitions of input parameters, and return value formats. This metadata is passed to the LLM, helping the model determine when to call which tool and what parameters to pass during inference, enabling intelligent tool selection and invocation.
MCP Client
The MCP Client serves as the "bridge" between the MCP Server and the LLM, responsible for relaying information between both parties to enable communication. It's important to note that the MCP Client does not directly execute tools—it only handles "translation" and "relay" functions:
- Passing the LLM's tool call requirements to the MCP Server according to MCP protocol specifications
- Feeding back tool execution results from the MCP Server to the LLM according to protocol specifications
At the transport layer, the MCP protocol supports two communication methods: one is local communication based on standard input/output (stdio), suitable for scenarios where the MCP Server and Client run on the same machine; the other is remote communication based on HTTP Server-Sent Events (SSE), suitable for scenarios where the MCP Server is deployed on a remote server. This dual-mode design balances the convenience of local development and debugging with the distributed deployment needs of production environments. The protocol's underlying layer uses JSON-RPC 2.0 as the message format standard, ensuring structured and parseable requests and responses.
Host
The Host is the runtime environment that carries the LLM—the starting point connecting the LLM and MCP Client. When a user poses a question to the LLM within the Host that requires tool calling, the Host detects the LLM's tool calling need and is responsible for creating the MCP Client and initiating the subsequent tool calling workflow.
In practice, Hosts come in various typical forms, including: Claude Desktop (Anthropic's official desktop client), Cursor (AI programming IDE), Continue (VS Code AI plugin), and more. These applications have built-in MCP Client implementations—users only need to declare the MCP Server addresses to connect to in configuration files, enabling the LLM within to gain the ability to call external tools. The Host's design philosophy is to let end users extend AI's capability boundaries through simple configuration without needing to understand the underlying protocol details.
LLM (Large Language Model)
The LLM is the core entity that needs to call tools. When the LLM cannot directly answer a user's question (e.g., needing to query real-time data, perform calculations, call external APIs, etc.), it generates a tool calling requirement and initiates a call request through the MCP Client.
Tools
Tools are the various functional modules that can be called by the LLM, such as real-time query tools, calculation tools, file processing tools, external API calling tools, and more. These tools are pre-built and deployed on the MCP Server, waiting for call instructions.
Complete MCP Protocol Workflow: From Question to Response
The best way to understand the MCP protocol is to walk through a complete call chain. Using "query today's weather" as an example, the entire process consists of eight steps:
Step 1: User Initiates a Request
The user poses a question to the LLM within the Host (the LLM's runtime environment) that requires tool calling to answer, such as "query today's weather" or "calculate the square root of 100."
Step 2: Host Creates MCP Client
The LLM recognizes that it cannot answer directly and needs to call a tool. After the Host detects this need, it creates an MCP Client and completes initialization configuration. During the initialization phase, the MCP Client establishes a connection with pre-configured MCP Servers and obtains the available tool list and their descriptions through the handshake. This information is provided to the LLM as context to assist its tool selection decisions.
Step 3: Request Passed to Client
The LLM passes its tool calling requirements (specifying which tool to call, parameters to pass, etc.) to the created MCP Client according to MCP protocol specifications. For example, the LLM might output a structured call request like {"tool": "weather_query", "params": {"city": "Beijing", "date": "today"}}.
Step 4: Client Connects to Server
The MCP Client further encapsulates the LLM's call requirements into JSON-RPC 2.0 format messages according to the MCP protocol and sends them to the MCP Server, initiating the tool call request.
Step 5: Server Executes Tool
After receiving the request, the MCP Server finds the corresponding tool in its toolbox and executes it (e.g., calling a weather API to query data, executing calculation logic, etc.).
Step 6: Execution Results Returned to Server Side
The MCP Server returns the tool execution results to the MCP Client according to MCP protocol specifications.
Step 7: Results Relayed Back to LLM
The MCP Client passes the received execution results to the LLM.
Step 8: LLM Completes Response
The LLM combines the tool execution results, organizes them into natural language, and feeds back to the user through the Host. The entire call workflow is complete.
Core Value and Design Philosophy of the MCP Protocol
The MCP protocol's design embodies a clear separation of concerns:
- LLM focuses on logical reasoning: No need to worry about the underlying implementation details of tools
- Tools focus on functional execution: Only need to provide services according to specifications
- Protocol focuses on interaction standards: Ensures smooth communication between all parties
This clearly defined architecture brings several significant advantages:
- Reduced development costs: Tool developers only need to follow MCP protocol specifications without adapting separately for each LLM
- Improved compatibility: Any LLM that follows the MCP protocol can call any tool that follows the same protocol
- Enhanced extensibility: Adding new tools only requires deploying them to the MCP Server without modifying the LLM or client code
MCP Protocol and AI Agent Synergy
The MCP protocol is a critical infrastructure for building AI Agents. One of an Agent's core capabilities is autonomous decision-making and multi-step task execution, and tool calling is the key means for Agents to interact with the external world. Through the MCP protocol, Agents can dynamically discover available tools, call them on demand, obtain results, and reason about next steps based on those results, forming a "Thought-Action-Observation" loop. Mainstream Agent frameworks like ReAct and Plan-and-Execute can all use MCP as the standardized implementation of the tool calling layer, greatly simplifying Agent development complexity.
For example, a travel planning Agent might need to sequentially call flight query tools, hotel booking tools, weather query tools, and map navigation tools. With the MCP protocol, the Agent doesn't need to understand each tool's specific API format—it can discover and call all tools through the unified MCP interface, greatly improving development efficiency in multi-tool collaboration scenarios.
Summary
The emergence of the MCP protocol marks the beginning of a standardized era for LLM tool calling. By defining unified communication specifications, it enables each role in the LLM ecosystem to fulfill its responsibilities and collaborate efficiently. For AI developers, understanding the MCP protocol is a foundational skill for building complex AI applications. As more tools and platforms adopt the MCP protocol, a more open and interoperable AI tool ecosystem is rapidly taking shape.
Key Takeaways
- MCP (Model Context Protocol) is an open-source standardized protocol for LLM tool calling released by Anthropic in 2024, solving the pain point of inconsistent tool calling methods
- The core architecture includes five roles: Host, LLM, MCP Client, MCP Server, and Tools
- The transport layer supports two modes: stdio for local communication and HTTP SSE for remote communication, with JSON-RPC 2.0 as the underlying message format
- The complete call chain: User asks → Host creates Client → Client requests → Server executes tool → Client relays results → LLM responds to user
- The core value of MCP lies in clear separation of concerns: LLM handles reasoning, tools handle execution, protocol handles standards—reducing development costs and improving compatibility
- MCP is critical infrastructure for building AI Agents, supporting dynamic tool discovery and invocation for multi-step autonomous task execution
Related articles
Deep DivesDeep Dive into How OpenClaw (Open-Source Crayfish) AI Agent Works
Deep analysis of OpenClaw AI Agent internals: System Prompt, tool calling, SubAgents, Skill system, memory, and Context Engineering explained.
Deep DivesDemystifying Transformer: A Word-Continuation Function, Deconstructed
Understand Transformer through the lens of word continuation. Breaking down language generation into Embedding, Transformer Block, and Probability output modules for intuitive understanding.
Deep DivesFive Core Differences Between Claude Code and Regular AI Chat
A detailed comparison of Claude Code vs regular AI chat across five dimensions: interaction, context understanding, execution, memory, and tool integration.