MCP Protocol Deep Dive: A Standardized Connection Solution for AI Agents

If you're building AI agents, you've almost certainly run into this dilemma: every time you integrate a new tool, you have to write a new set of integration code and new authentication logic. The more tools you have, the more integrations multiply quadratically. The Model Context Protocol (MCP) is an open protocol designed to solve exactly this problem.

Based on an in-depth explanation from the technical channel LearnTech, this article systematically breaks down the complete technical landscape of MCP—from architecture design and protocol messages to transport mechanisms and production practices.

Why We Need MCP: From M×N to M+N

Suppose you have M AI applications and N tools. In the traditional approach, every pair requires a separate integration, resulting in M×N integration solutions in total. MCP reduces this complexity to M+N: each application only needs to implement an MCP Client once, and each tool only needs to implement an MCP Server once.

This design approach didn't come out of nowhere. The Language Server Protocol (LSP) solved the adaptation problem between code editors and programming languages in the same way—before LSP, every editor had to write separate support for every language. MCP drew its inspiration from LSP's success.

Three-Layer Architecture: Host, Client, and Server

MCP's architecture consists of three roles. The Host is the application the user directly runs, such as Claude Desktop, code editors like Cursor, or an agent application you build yourself. The Client lives inside the Host, and each Client maintains a one-to-one connection with a Server. The Server is a lightweight program responsible for exposing the capabilities of a specific system—GitHub, a PostgreSQL database, Slack, or a company's internal API.

The model running in the Host decides which Server permissions to grant the agent. If the Host connects to three Servers, it runs three independent Clients internally. The key advantage of this one-to-one design is isolation: one Server cannot peer into another Server's interactions.

Protocol Layer: JSON-RPC 2.0 and Capability Negotiation

All MCP messages use the JSON-RPC 2.0 format, with three message types: Request (a request that expects a response), Response (the response to a request), and Notification (a notification that requires no response).

Every connection goes through a lifecycle. The Client first sends an initialize request, declaring its protocol version and capabilities; the Server states in its response which capabilities it supports—whether it provides Tools, Resources, or Prompts; the Client then sends an initialized notification, and the connection is formally established. This process is called Capability Negotiation, where both sides only use the features they have both agreed to support.

JSON-RPC 2.0 is a lightweight remote procedure call protocol that uses JSON as its data exchange format. Its message structure is very simple: a request contains jsonrpc: "2.0", method (the method name), params (the parameters), and id (the request identifier); a successful response contains result, an error response contains an error object (with an error code, message, and data); and notifications omit the id field, indicating that no response is needed. Compared with REST, JSON-RPC's semantics are closer to function calls, making it naturally suited to scenarios that require bidirectional interaction and state management. MCP chose JSON-RPC 2.0 because it can express all three message types—request, response, and notification—in a unified format and is decoupled from the transport layer: the same message format can run over STDIO or over HTTP, making it easy to implement and debug.

Transport Mechanisms: STDIO and Streamable HTTP

How do messages travel between the two ends? MCP defines two standard transports.

STDIO is suited to scenarios where the Server runs on the local machine; the Host launches it as a subprocess and communicates through standard input and output. Streamable HTTP targets remote Servers: the Client sends messages via HTTP POST, and the Server can return results and updates through streaming responses as needed. The latter replaced the earlier HTTP+SSE approach.

The early MCP remote transport was HTTP+SSE: the Client sent messages via HTTP POST, and the Server pushed messages to the Client through a long-lived Server-Sent Events (SSE) connection. This approach had clear drawbacks—it required maintaining two separate connections and was prone to problems with reconnection, load balancing, and multi-instance deployment, and some infrastructure would buffer or interrupt long-lived connections. Streamable HTTP improves on this: the Client uniformly sends messages via HTTP POST, and the Server can either return a plain HTTP response or return an SSE stream when streaming output is needed. It also supports maintaining state across multiple requests via a session ID and supports recovery after disconnection. It turns "long-lived connections" from a requirement into an option, making it more compatible with existing HTTP infrastructure (such as CDNs and API gateways) and better suited to serverless deployments.

The Three Server Primitives: Tools, Resources, and Prompts

An MCP Server provides three core capabilities, each with a different party in control.

Tools are controlled by the model. The model decides on its own when to call which tool. Each tool includes a name, a description, and an input parameter schema.

Resources are controlled by the Host. These are data identified by URI, such as file paths or database tables. The Host decides which Resources go into the model's context.

Prompts are controlled by the user. These are predefined templates that the user actively chooses to use.

Client-Side Capabilities: Sampling, Elicitation, and Notifications

MCP is not a one-way channel. The Client also offers several capabilities to the Server. Sampling allows the Server to ask the Client to generate completions using its model, so the Server doesn't need to build its own AI capabilities. Elicitation lets the Server request information from the user during an interaction, such as confirming an action or filling in missing details. In addition, when the Server's tool list changes, it sends a list changed notification so the Client is immediately aware.

Complete Call Flow: A GitHub Scenario

The user says: "Summarize all open issues in this repository for me." The model in the Host determines that it needs to call a GitHub-related tool, and the Host first requests authorization from the user; the Client then sends a tools/call request with parameters. The Server calls the GitHub API and returns the results to the Client, which enter the model's context, and the model generates a summary based on them.

Throughout this process, the model never directly touches the GitHub API, and the credentials always remain on the Server side. This is precisely the elegance of MCP's design—capability exposure and credential management are completely decoupled.

OAuth 2.1 is the security foundation for authorizing MCP remote Servers. Compared with earlier versions, OAuth 2.1 mandates PKCE (Proof Key for Code Exchange), prohibits the implicit grant flow, and requires exact redirect URI matching to reduce the risk of authorization codes being intercepted. In the MCP context, the Client must first obtain an access token from the authorization server and then carry that token when calling the Server; the Server is responsible for validating the token and determining the scope of accessible resources accordingly. The key constraint lies in token audience binding: the token the Server receives can only be used for itself and must never be forwarded to downstream APIs—otherwise, if the downstream is compromised, the token would leak laterally. This is the protocol basis behind the statement "the Server must never forward the Client's token to other APIs."

Quickly Building an MCP Server in Python

The barrier to building an MCP Server is not high. The official Python SDK provides the FastMCP approach: create a Server object, write an ordinary Python function, and add the @mcp.tool decorator. The function name becomes the tool name, the docstring becomes the tool description, and the type annotations automatically generate the input schema. For testing, you can use the MCP Inspector tool to directly call and inspect the Server's Tools, Resources, and Prompts in the browser.

Three Design Guidelines for Production

Write good tool descriptions. The model can't see your code—it only reads the description. The quality of the description directly determines how accurately the tool is called.

Control the number of tools. Every tool definition consumes part of the model's context window. Ten carefully designed tools are better than fifty trivial ones.

Return errors clearly. Return error messages in explicit language so the model has a chance to correct itself.

Security Risks: Prompt Injection and Tool Poisoning

The security threat to watch out for most is Prompt Injection. When a tool's returned results come from web pages or emails, hidden instructions within them may mislead the model. Tool Poisoning is when a malicious Server embeds concealed instructions in its tool descriptions. Countermeasures include installing only Servers from trusted sources and reviewing their source code.

Authorization for remote Servers is based on OAuth 2.1. The Server must never forward the Client's token to other APIs. Follow the principle of least privilege, and always require user confirmation for dangerous operations such as deleting data or making payments.

Conclusion

MCP is more than just a connector—it provides AI agents with a complete protocol: architecture, lifecycle, transport, primitives, and security model are all standardized. Understanding the design logic of this protocol is the foundation for building reliable agent systems.

One-line Summary

MCP uses a standardized protocol to reduce the integration complexity between AI applications and tools from M×N to M+N.

Paragraph Summary

This article systematically breaks down the complete technical landscape of the Model Context Protocol (MCP). Drawing on LSP's approach, MCP reduces the integration complexity between M AI applications and N tools from M×N to M+N. Architecturally, it adopts a three-layer model of Host, Client, and Server, with one-to-one Client-Server connections to ensure isolation. The protocol is based on JSON-RPC 2.0, completes capability negotiation through an initialize request, and supports two transports: STDIO and Streamable HTTP. The Server exposes three types of primitives—Tools (model-controlled), Resources (Host-controlled), and Prompts (user-controlled)—while the Client in turn provides Sampling and Elicitation capabilities. The article also covers how to quickly build a Server with Python FastMCP, three design guidelines for production, and security essentials such as prompt injection, tool poisoning, and OAuth 2.1 authorization.