MCP Protocol Deep Dive: Core Concepts, Workflow, and Packet Capture Analysis

What MCP Really Is: Giving LLMs Hands and Feet

MCP (Model Context Protocol) is an open protocol released by Anthropic on November 25, 2024. Anthropic is an AI safety company founded in 2021 by siblings Dario Amodei and Daniela Amodei, former OpenAI Research VP and colleagues respectively. Their flagship Claude series of large language models excel in reasoning capability and safety. Anthropic's decision to release MCP as an open protocol rather than a proprietary standard reflects their strategic intent to establish an industry standard in the AI tool ecosystem—similar to how Google pushed Kubernetes to become the container orchestration standard. This strategy has enabled MCP to quickly gain broad cross-platform, cross-vendor support.

While the name may sound abstract, the problem it solves is very straightforward—giving LLMs the ability to call external tools.

LLMs themselves are only good at conversational Q&A. They can't proactively search the internet, operate software, or access real-time data. MCP effectively gives models "hands" and "feet": through MCP, models can use browsers to look up information, operate Unity to build games, query real-time traffic conditions... vastly expanding their capability boundaries.

This article covers MCP's core concepts, data flow processes, practical configuration, and goes all the way down to protocol-level packet capture analysis to help you thoroughly understand how MCP works.

MCP Core Concepts: Host, Server, and Tool

MCP Host: The Software That Carries the Protocol

Using MCP requires software that supports the protocol—this is the MCP Host. Currently mainstream MCP Hosts include Claude Desktop, Cursor, Cline (VS Code extension), Cherry Studio, and others.

An MCP Host is essentially a "middleman program" that connects to an LLM on one end and manages and invokes various MCP Servers on the other.

MCP Server: A Locally Running Tool Program

The name "MCP Server" might make you think of remote servers, but it actually has little to do with traditional servers. An MCP Server is simply a program running locally—one that exposes services following the MCP protocol specification. The vast majority of MCP Servers are launched locally via Node.js or Python, and may or may not require internet access during runtime.

You can think of MCP Servers like apps on your phone—each app has built-in functional modules to solve specific problems, and MCP Servers work the same way.

Tool: Essentially Just a Function

The functional modules inside an MCP Server are called Tools in the MCP ecosystem. A Tool is essentially just a function in a programming language: it receives input parameters, processes them according to predefined logic, and returns output results.

For example, a weather query MCP Server might contain two Tools:

• Get Forecast: Takes latitude/longitude coordinates and returns the weather forecast for the coming days
• Get Alerts: Takes a region code and returns current weather alerts

MCP Complete Workflow: From Registration to Invocation

Now that we understand the core concepts, let's look at the complete data flow from configuration to final response.

Phase One: Registration Handshake

When you add an MCP Server to your configuration file and save it, the MCP Host (e.g., Cline) immediately launches that program using the command specified in the configuration. After startup, both sides perform a "handshake":

1. Host sends an initialization request to the Server, which responds with confirmation
2. Host asks: "What Tools do you have available?"
3. Server responds: "I have Get Forecast and Get Alerts, and they require these parameters..."
4. Host records this tool information—registration is complete

The entire handshake process happens in the instant the MCP Server starts up.

Phase Two: User Query and Tool Invocation

When a user asks "What's the weather like in New York tomorrow?", the complete call chain works as follows:

1. Host sends the user's question along with the list of all registered Tools to the LLM
2. The LLM analyzes the question, realizes it can't answer directly (knowledge cutoff or lack of real-time data), but notices the Get Forecast Tool can help
3. The LLM tells the Host: "Please call Get Forecast with parameters latitude 40°N, longitude 74°W"
4. Host forwards the request to the corresponding MCP Server, which executes the function and returns weather data
5. Host passes the execution results back to the LLM, which then formulates a natural language response
6. The user sees the complete weather reply

Hands-On: Installing and Configuring MCP Servers

JSON Configuration File Explained

In Cline, clicking "Configure MCP Servers" opens a JSON configuration file. Each MCP Server configuration contains the following core fields:

• name: Unique identifier for the MCP Server
• disabled: Whether the Server is disabled
• timeout: Connection timeout (in seconds)
• command: Startup command (e.g., uv, npx)
• args: List of startup arguments
• transport type: Communication method (stdio or sse)

Two Main Startup Methods

UVX method (Python ecosystem): UVX is a shortcut command for the UV tool that automatically downloads dependencies, configures the environment, and launches Python-based MCP Servers. UV is a next-generation Python package manager built by Astral (the same company behind the popular Python linter Ruff), written in Rust, and 10-100x faster than traditional pip. UVX is similar to NPX in the Node.js ecosystem—it can temporarily download and run Python packages without polluting the global environment. UV's emergence addresses Python's long-standing pain point of chaotic environment management (pip, conda, virtualenv, poetry, etc. all coexisting), and its widespread adoption in the MCP ecosystem reflects Python's toolchain modernization. To use it, first install the UV tool, then specify uvx as the command in your configuration.

NPX method (Node.js ecosystem): NPX is Node.js's built-in package execution tool, functionally similar to UVX, used to automatically download and run Node.js-based MCP Servers. It's available immediately after installing Node.js.

Pro tip: When loading an MCP Server for the first time, UVX or NPX needs to download dependency packages, which may exceed the default 60-second timeout. It's recommended to first manually run the startup command in your terminal, wait for all dependencies to finish downloading, then reload the Server in the Host.

Where to Find MCP Servers

There are already several MCP Server aggregation marketplaces available for browsing and installation, including mcp.so, mcpmarket.com, smithery.ai, and others—the experience is similar to a mobile app store.

From Function Calling to MCP: The Technical Evolution

The Original Approach: Hardcoding in Prompts

The earliest method for getting LLMs to call external tools was quite crude—directly writing complete tool usage instructions into the prompt, including names, functional descriptions, parameter formats, return value structures, etc. But early LLMs were unreliable at following instructions and frequently returned chaotically formatted content that middleman programs simply couldn't parse reliably.

Function Calling: Toward Standardization

OpenAI subsequently introduced Function Calling technology, using JSON Schema to standardize descriptions of external tool information and separating it from user prompts. JSON Schema is a declarative language for describing JSON data structures, defining data types, required fields, value ranges, and other constraints. In Function Calling, developers need to precisely describe each tool function's input parameter structure using JSON Schema—for example, specifying that a parameter is a string type, has a maximum length of 100, and is required. LLMs undergo specialized fine-tuning during training to understand JSON Schema descriptions and generate function call instructions that conform to format requirements—this is why Function Calling requires native model support, as it relies on structured output capabilities built into the model during training. The model's response includes dedicated fields that clearly indicate the tool name and parameters to call, dramatically improving reliability.

However, Function Calling has an obvious pain point: every tool requires developers to manually write detailed API Schema descriptions, resulting in high maintenance costs. In real AI Agent scenarios, a single agent might interface with dozens or even hundreds of external tools, and any interface change requires synchronous Schema updates—an enormous workload.

MCP's Solution: Unified Tool Interface Encapsulation

MCP's core approach is: since every tool function requires tedious interface descriptions, just add a unified encapsulation layer at the tool level. External tools no longer expose themselves directly to callers via HTTP APIs; instead, they uniformly wrap themselves in the MCP "shell" and provide services through this standardized shell. The middleman program only needs to interact with the shell.

Using Python as an example, with MCP's official SDK, developers can register ordinary functions as MCP Tools through a simple decorator—no need to write additional web servers to expose interfaces, and no need to maintain cumbersome API Schema files.

Under the Hood: Packet Capture Analysis of MCP Communication

Communication Between Client and Server

The MCP protocol supports two communication modes:

STDIO mode: The MCP Server launches as a child process of the Client, and both sides exchange data through standard input (stdin) and standard output (stdout). Standard I/O is the most fundamental inter-process communication mechanism provided by operating systems, natively supported by virtually all programming languages, making STDIO mode extremely easy to implement. This method is suitable for scenarios where Client and Server are on the same machine, and is currently the most common deployment approach.

SSE mode (Server-Sent Events): Communication via HTTP protocol. SSE is a technology defined in the HTML5 specification for one-way server-to-client data pushing. Unlike WebSocket's full-duplex communication, SSE natively only supports unidirectional data flow from server to client, but is simpler to implement and supports automatic reconnection. In MCP's SSE mode, the protocol cleverly achieves bidirectional communication through two HTTP endpoints: one long-lived connection endpoint for server-side message pushing (the SSE channel), and one standard POST endpoint for client requests. This design avoids the problem of WebSocket being blocked by firewalls in some enterprise network environments. SSE mode is suitable for remote invocation scenarios where Client and Server are deployed on different machines.

Both modes implement data exchange based on the JSON-RPC 2.0 protocol underneath. JSON-RPC 2.0 is a lightweight remote procedure call protocol using JSON as its data encoding format. Compared to heavier alternatives like gRPC (based on Protocol Buffers) or SOAP (based on XML), JSON-RPC's advantage lies in its minimalist protocol design—a request only needs three fields: method (method name), params (parameters), and id (request identifier), while a response contains either result or error. This simplicity makes it well-suited for MCP's frequent, rapid interaction scenarios while also lowering the implementation barrier for MCP Server developers. Through packet capture, you can clearly see: the Client's request contains the tool name and parameters to invoke, and the Server's response contains the function's execution result.

Communication Between Client and LLM: An Unexpected Discovery

By analyzing HTTPS communication between the Cline plugin and the AI model through Fiddler proxy packet capture, we discover a surprising fact: Cline does NOT use Function Calling technology. Instead, it uses the most primitive approach—writing all external tool information directly into the System Prompt.

This system prompt is over 60,000 characters long, containing:

• Tool information for all registered MCP Servers (names, parameters, purposes)
• Usage instructions for Cline's built-in tools
• Detailed invocation tutorial examples
• Agreed-upon format conventions (such as using <use_mcp_tool> XML tags)

The LLM indeed responds in the agreed format, using XML tags to specify the tool name and parameters to call. While this approach consumes a large number of tokens, the benefit is that theoretically any LLM with sufficiently good instruction-following capability can use MCP, without depending on whether the model natively supports Function Calling.

It's worth noting that in LLM API pricing systems, tokens are the most basic unit of measurement—roughly 1-2 tokens per English word, and about 1-2 tokens per Chinese character. Over 60,000 characters of tool information means this content must be sent in full to the LLM with every user query. Based on mainstream API pricing (e.g., Claude 3.5 Sonnet's input price of approximately $3 per million tokens), the tool description portion alone costs approximately $0.05-0.10 per request. In high-frequency calling scenarios, this expense is considerable. This is also why the Function Calling approach is more token-efficient—tool descriptions are passed through dedicated fields that the model can process more efficiently.

Key Conclusion: MCP's True Value

Consulting Anthropic's official documentation confirms: The MCP protocol currently only specifies the communication standard between Client and Server. How the Client communicates with the AI model is not restricted by the protocol.

In terms of specific implementation, you can stuff tool information into the system prompt like Cline does, or pass it via Function Calling—each approach has its tradeoffs. The former offers stronger compatibility and works with virtually all LLMs; the latter is more token-friendly but requires native Function Calling support from the model.

This also reveals MCP's true value: it unifies the interface standard on the tool side, making MCP Server development, distribution, and reuse unprecedentedly simple. As for how to interface with LLMs, that's left for individual MCP Host developers to choose freely based on their actual needs. This design philosophy of "tool standardization + integration flexibility" is the key reason MCP has been rapidly adopted across the ecosystem.

Key Takeaways

• MCP (Model Context Protocol) is essentially a standardized protocol enabling LLMs to call external tools. MCP Servers are local programs following this protocol specification, and Tools are their constituent functions
• MCP's complete workflow includes a registration phase (Host obtains Server's Tool list) and an invocation phase (LLM analyzes problem → requests Tool call → Host forwards execution → results returned)
• MCP is a further encapsulation of Function Calling technology, greatly simplifying tool function development and description through the official SDK, eliminating the need to manually write API Schemas
• Packet capture analysis reveals that the Cline plugin actually writes all tool information (over 60,000 characters) directly into the system prompt rather than using Function Calling, meaning any model with good instruction-following capability can use MCP
• The MCP protocol currently only standardizes communication between Client and Server (based on JSON-RPC 2.0); how the Client communicates with the LLM is determined by each Host independently