MCP概念与实践全解析

- [1. MCP 到底解决了什么问题](#1. MCP 到底解决了什么问题)
- - [1.1 从 Function Calling 到 MCP](#1.1 从 Function Calling 到 MCP)
  - [1.2 为什么 Tool Calling 还需要协议](#1.2 为什么 Tool Calling 还需要协议)
  - [1.3 没有 MCP 的 Agent 是怎么接工具的](#1.3 没有 MCP 的 Agent 是怎么接工具的)
  - [1.4 Tool Integration 为什么会越来越复杂](#1.4 Tool Integration 为什么会越来越复杂)
  - [1.5 MCP 的核心目标是什么](#1.5 MCP 的核心目标是什么)
  - [1.6 MCP 解决什么，不解决什么](#1.6 MCP 解决什么，不解决什么)
- [2. MCP 的整体架构](#2. MCP 的整体架构)
- - [2.1 MCP 中有哪些角色](#2.1 MCP 中有哪些角色)
  - [2.2 Host、Client、Server 分别是什么](#2.2 Host、Client、Server 分别是什么)
  - [2.3 MCP 在 Agent 架构中的位置](#2.3 MCP 在 Agent 架构中的位置)
  - [2.4 Client 与 Server 是什么关系](#2.4 Client 与 Server 是什么关系)
  - [2.5 MCP Server 后面到底连接着什么](#2.5 MCP Server 后面到底连接着什么)
  - [2.6 本地 MCP 与远程 MCP](#2.6 本地 MCP 与远程 MCP)
- [3. MCP 协议的基础：JSON-RPC](#3. MCP 协议的基础：JSON-RPC)
- - [3.1 为什么 MCP 需要消息协议](#3.1 为什么 MCP 需要消息协议)
  - [3.2 JSON-RPC 是什么](#3.2 JSON-RPC 是什么)
  - [3.3 Request](#3.3 Request)
  - [3.4 Response](#3.4 Response)
  - [3.5 Notification](#3.5 Notification)
  - [3.6 Request ID](#3.6 Request ID)
  - [3.7 Error](#3.7 Error)
  - [3.8 MCP 如何建立在 JSON-RPC 之上](#3.8 MCP 如何建立在 JSON-RPC 之上)
- [4. MCP 的生命周期与协议交互](#4. MCP 的生命周期与协议交互)
- - [4.1 MCP 请求是怎么产生的](#4.1 MCP 请求是怎么产生的)
  - [4.2 Client 如何了解 Server](#4.2 Client 如何了解 Server)
  - [4.3 Capability 是什么](#4.3 Capability 是什么)
  - [4.4 Discovery](#4.4 Discovery)
  - [4.5 Request / Response 的完整生命周期](#4.5 Request / Response 的完整生命周期)
  - [4.6 Stateless MCP 与 Stateful Application](#4.6 Stateless MCP 与 Stateful Application)
- [5. MCP 的核心 Primitive：Tools、Resources、Prompts](#5. MCP 的核心 Primitive：Tools、Resources、Prompts)
- - [5.1 Tools](#5.1 Tools)
  - - [5.1.1 Tool 是什么](#5.1.1 Tool 是什么)
    - [5.1.2 `tools/list`](#5.1.2 tools/list)
    - [5.1.3 Tool Schema](#5.1.3 Tool Schema)
    - [5.1.4 `tools/call`](#5.1.4 tools/call)
    - [5.1.5 Tool Arguments](#5.1.5 Tool Arguments)
    - [5.1.6 Tool Result](#5.1.6 Tool Result)
    - [5.1.7 Tool Error](#5.1.7 Tool Error)
  - [5.2 Resources](#5.2 Resources)
  - - [5.2.1 Resource 是什么](#5.2.1 Resource 是什么)
    - [5.2.2 Resource URI](#5.2.2 Resource URI)
    - [5.2.3 `resources/list`](#5.2.3 resources/list)
    - [5.2.4 `resources/read`](#5.2.4 resources/read)
    - [5.2.5 Resource Template](#5.2.5 Resource Template)
    - [5.2.6 Resource 与 Tool 的区别](#5.2.6 Resource 与 Tool 的区别)
  - [5.3 Prompts](#5.3 Prompts)
  - - [5.3.1 Prompt 是什么](#5.3.1 Prompt 是什么)
    - [5.3.2 `prompts/list`](#5.3.2 prompts/list)
    - [5.3.3 `prompts/get`](#5.3.3 prompts/get)
    - [5.3.4 MCP Prompt 与普通 System Prompt 的区别](#5.3.4 MCP Prompt 与普通 System Prompt 的区别)
- [6. 一次 Tool Calling 究竟是怎么发生的](#6. 一次 Tool Calling 究竟是怎么发生的)
- - [6.1 Client 发现 Tool](#6.1 Client 发现 Tool)
  - [6.2 Server 返回 Tool Definition](#6.2 Server 返回 Tool Definition)
  - [6.3 Agent 将 Tool 提供给 LLM](#6.3 Agent 将 Tool 提供给 LLM)
  - [6.4 LLM 决定调用 Tool](#6.4 LLM 决定调用 Tool)
  - [6.5 Client 发起 `tools/call`](#6.5 Client 发起 tools/call)
  - [6.6 Server 执行真正的业务逻辑](#6.6 Server 执行真正的业务逻辑)
  - [6.7 Server 返回 Tool Result](#6.7 Server 返回 Tool Result)
  - [6.8 Client 将结果交给模型](#6.8 Client 将结果交给模型)
  - [6.9 模型生成最终答案](#6.9 模型生成最终答案)
- [7. MCP Transport：消息到底怎么传过去](#7. MCP Transport：消息到底怎么传过去)
- - [7.1 Transport 是什么](#7.1 Transport 是什么)
  - [7.2 STDIO](#7.2 STDIO)
  - [7.3 Streamable HTTP](#7.3 Streamable HTTP)
  - [7.4 Local MCP 的通信方式](#7.4 Local MCP 的通信方式)
  - [7.5 Remote MCP 的通信方式](#7.5 Remote MCP 的通信方式)
  - [7.6 HTTP Headers](#7.6 HTTP Headers)
  - [7.7 Streaming](#7.7 Streaming)
  - [7.8 为什么旧的 HTTP+SSE 已经被弃用](#7.8 为什么旧的 HTTP+SSE 已经被弃用)
- [8. MCP 的 Capability 与协议扩展](#8. MCP 的 Capability 与协议扩展)
- - [8.1 Capability 是什么](#8.1 Capability 是什么)
  - [8.2 Client Capabilities](#8.2 Client Capabilities)
  - [8.3 Server Capabilities](#8.3 Server Capabilities)
  - [8.4 为什么 MCP 需要 Capability Negotiation](#8.4 为什么 MCP 需要 Capability Negotiation)
  - [8.5 Extension 是什么](#8.5 Extension 是什么)
  - [8.6 Core 与 Extension 的区别](#8.6 Core 与 Extension 的区别)
  - [8.7 MCP 如何进行协议演进](#8.7 MCP 如何进行协议演进)
- [9. MCP 的高级能力](#9. MCP 的高级能力)
- - [9.1 Sampling（已弃用）](#9.1 Sampling（已弃用）)
  - [9.2 Elicitation](#9.2 Elicitation)
  - [9.3 Tasks（Extension）](#9.3 Tasks（Extension）)
  - [9.4 Notifications](#9.4 Notifications)
  - [9.5 Subscriptions](#9.5 Subscriptions)
  - [9.6 Annotations](#9.6 Annotations)
  - [9.7 Structured Content](#9.7 Structured Content)
  - [9.8 MCP Apps（Extension）](#9.8 MCP Apps（Extension）)
- [10. MCP 的安全与授权](#10. MCP 的安全与授权)
- - [10.1 为什么 MCP Server 是安全边界](#10.1 为什么 MCP Server 是安全边界)
  - [10.2 MCP Authentication](#10.2 MCP Authentication)
  - [10.3 OAuth](#10.3 OAuth)
  - [10.4 Authorization](#10.4 Authorization)
  - [10.5 Client Identity](#10.5 Client Identity)
  - [10.6 Token 与 Credential](#10.6 Token 与 Credential)
  - [10.7 权限控制](#10.7 权限控制)
  - [10.8 Tool Abuse](#10.8 Tool Abuse)
  - [10.9 Prompt Injection](#10.9 Prompt Injection)
  - [10.10 Confused Deputy](#10.10 Confused Deputy)
  - [10.11 Remote MCP 的安全问题](#10.11 Remote MCP 的安全问题)
- [11. 从零实现一个 MCP Server](#11. 从零实现一个 MCP Server)
- - [11.1 MCP Server 最小结构](#11.1 MCP Server 最小结构)
  - [11.2 创建第一个 Tool](#11.2 创建第一个 Tool)
  - [11.3 定义 Tool Schema](#11.3 定义 Tool Schema)
  - [11.4 启动 STDIO Server](#11.4 启动 STDIO Server)
  - [11.5 用 MCP Client 连接](#11.5 用 MCP Client 连接)
  - [11.6 发现 Tool](#11.6 发现 Tool)
  - [11.7 调用 Tool](#11.7 调用 Tool)
  - [11.8 返回 Tool Result](#11.8 返回 Tool Result)
  - [11.9 从 STDIO 改成 Streamable HTTP](#11.9 从 STDIO 改成 Streamable HTTP)
- [12. 从零实现一个 MCP Client](#12. 从零实现一个 MCP Client)
- - [12.1 为什么需要 MCP Client](#12.1 为什么需要 MCP Client)
  - [12.2 建立连接](#12.2 建立连接)
  - [12.3 获取 Server 能力](#12.3 获取 Server 能力)
  - [12.4 获取 Tools](#12.4 获取 Tools)
  - [12.5 调用 Tool](#12.5 调用 Tool)
  - [12.6 处理 Result](#12.6 处理 Result)
  - [12.7 把 MCP Tool 接入 LLM](#12.7 把 MCP Tool 接入 LLM)
  - [12.8 一个最小 Agent + MCP 架构](#12.8 一个最小 Agent + MCP 架构)
- [13. MCP Server 到底应该部署在哪里](#13. MCP Server 到底应该部署在哪里)
- - [13.1 本地 MCP Server](#13.1 本地 MCP Server)
  - [13.2 远程 MCP Server](#13.2 远程 MCP Server)
  - [13.3 Docker](#13.3 Docker)
  - [13.4 Kubernetes](#13.4 Kubernetes)
  - [13.5 Load Balancer](#13.5 Load Balancer)
  - [13.6 Stateless Server](#13.6 Stateless Server)
  - [13.7 多实例部署](#13.7 多实例部署)
  - [13.8 Gateway](#13.8 Gateway)
  - [13.9 企业内部 MCP](#13.9 企业内部 MCP)
- [14. MCP 与其他技术到底是什么关系](#14. MCP 与其他技术到底是什么关系)
- [15. 一个生产级 MCP 系统长什么样](#15. 一个生产级 MCP 系统长什么样)
- [16. MCP 的发展与未来](#16. MCP 的发展与未来)
- - [16.1 MCP 从本地 Tool 协议开始](#16.1 MCP 从本地 Tool 协议开始)
  - [16.2 生态快速发展](#16.2 生态快速发展)
  - [16.3 从 Stateful 到 Stateless](#16.3 从 Stateful 到 Stateless)
  - [16.4 从 Core Features 到 Extensions](#16.4 从 Core Features 到 Extensions)
  - [16.5 Remote MCP](#16.5 Remote MCP)
  - [16.6 Enterprise MCP](#16.6 Enterprise MCP)
  - [16.7 Agentic Messaging](#16.7 Agentic Messaging)
  - [16.8 MCP 下一步会解决什么问题](#16.8 MCP 下一步会解决什么问题)
- [17. 总结：真正理解 MCP](#17. 总结：真正理解 MCP)
- - [17.1 MCP 的核心抽象](#17.1 MCP 的核心抽象)
  - [17.2 MCP 的完整请求链路](#17.2 MCP 的完整请求链路)
  - [17.3 MCP 与 Agent 的关系](#17.3 MCP 与 Agent 的关系)
  - [17.4 MCP 与 Function Calling 的关系](#17.4 MCP 与 Function Calling 的关系)
  - [17.5 一个 MCP Server 本质上是什么](#17.5 一个 MCP Server 本质上是什么)
  - [17.6 什么时候应该使用 MCP](#17.6 什么时候应该使用 MCP)
  - [17.7 什么时候没必要使用 MCP](#17.7 什么时候没必要使用 MCP)

本文定位为 MCP 协议的"全解析"，聚焦于 MCP 到底是怎么工作的 ------从 Client 到 Server，一条请求究竟发生了什么。所有内容均基于 2026-07-28 规范，这是 MCP 迄今为止最大的一次版本更新。

1. MCP 到底解决了什么问题

在进入协议细节之前，先理解为什么需要 MCP。

1.1 从 Function Calling 到 MCP

大模型 Function Calling 让模型能够"调用函数"，但它解决的是模型如何表达工具调用的问题------模型输出一个 JSON 结构，表示"我要调用某个函数，参数是什么"。这只解决了"说"的问题，没有解决"做"的问题。

1.2 为什么 Tool Calling 还需要协议

当你想让模型真正去执行一个操作------查数据库、发邮件、调用 API------你需要一个标准化的方式来完成从"模型说要调用"到"实际执行并返回结果"的闭环。不同的工具有不同的接口、不同的认证方式、不同的数据格式，如果没有一个统一的协议，每接入一个新工具就要写一套新的集成代码。

1.3 没有 MCP 的 Agent 是怎么接工具的

在没有 MCP 的时代，Agent 接工具通常是这样：为每个工具写一个 Python 函数或 HTTP 封装，把工具描述硬编码进 system prompt，然后解析模型的输出再路由到对应的函数。这种做法的核心问题是紧耦合------工具和 Agent 绑定在一起，换一个 Agent 就要重写一遍集成。

1.4 Tool Integration 为什么会越来越复杂

随着工具数量的增长（从几个到几十个），问题开始爆发：工具描述格式不统一、参数校验分散在各处、错误处理不一致、认证方式各异、无法动态发现新工具。每一个新工具都意味着改代码、发版、重启。

1.5 MCP 的核心目标是什么

MCP 的核心目标是：为 AI 应用访问外部工具、数据和能力定义一套标准化的协议层。让任何 MCP Host（Claude Code、VS Code、Cursor 或你自己写的应用）都能以统一的方式连接任何 MCP Server，发现并使用 Server 暴露的能力。

1.6 MCP 解决什么，不解决什么

MCP 解决的是标准化接入 的问题------工具如何描述、如何发现、如何调用、结果如何返回。MCP 不解决模型如何推理、Agent 如何决策、任务如何编排------这些是 Agent Framework 的范畴。

2. MCP 的整体架构

2.1 MCP 中有哪些角色

MCP 遵循 client-server 架构，包含三个核心角色：

复制代码

User
  ↓
Agent / Host
  ↓
MCP Client
  ↓
MCP Protocol（JSON-RPC over STDIO / Streamable HTTP）
  ↓
MCP Server
  ↓
Tool / Resource / 外部系统

2.2 Host、Client、Server 分别是什么

MCP Host：AI 应用程序，负责协调和管理一个或多个 MCP Client。例如 Claude Desktop、VS Code、Cursor。
MCP Client：由 Host 创建，维护与单个 MCP Server 的专用连接，从 Server 获取上下文供 Host 使用。
MCP Server：向 MCP Client 提供上下文（工具、资源、提示词）的程序。

2.3 MCP 在 Agent 架构中的位置

MCP 位于 Agent Runtime 和外部系统之间。Agent Runtime 负责决策和编排，MCP 负责标准化地接入工具和数据。两者分工明确、互不替代。

2.4 Client 与 Server 是什么关系

一个 Host 可以为每个 MCP Server 创建一个专用的 Client，每个 Client 维护一条与对应 Server 的独立连接。本地 MCP Server（使用 STDIO）通常服务单个 Client，而远程 MCP Server（使用 Streamable HTTP）可以服务多个 Client。

2.5 MCP Server 后面到底连接着什么

MCP Server 本身是一个"适配层"------它后面可以是 REST API、数据库、文件系统、消息队列、企业内部系统等任何东西。Server 负责把这些外部能力包装成 MCP 标准化的 Tools、Resources 和 Prompts。

2.6 本地 MCP 与远程 MCP

本地 MCP：Server 与 Client 在同一台机器上，通过 STDIO 通信。
远程 MCP：Server 作为独立服务运行，通过 Streamable HTTP 通信。

3. MCP 协议的基础：JSON-RPC

3.1 为什么 MCP 需要消息协议

MCP 需要在 Client 和 Server 之间传递请求和响应，需要一个标准的消息格式。JSON-RPC 2.0 被选中作为这个基础。

3.2 JSON-RPC 是什么

JSON-RPC 是一种轻量级的远程过程调用（RPC）协议，使用 JSON 作为数据格式。它定义了 Request、Response、Notification 和 Error 四种基本消息类型。

3.3 Request

一个 JSON-RPC 请求包含 jsonrpc、id、method 和 params 四个字段：

json 复制代码

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": { "name": "search", "arguments": { "q": "otters" } }
}

3.4 Response

响应包含 jsonrpc、id、result 三个字段：

json 复制代码

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": { ... }
}

3.5 Notification

Notification 是不需要响应的消息，没有 id 字段：

json 复制代码

{
  "jsonrpc": "2.0",
  "method": "notifications/initialized"
}

3.6 Request ID

id 用于将响应与请求关联起来。Client 发起请求时生成一个 ID，Server 在响应中带上相同的 ID，Client 据此匹配。

3.7 Error

错误响应包含 error 对象，其中有 code 和 message 字段：

json 复制代码

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": { "code": -32000, "message": "Tool not found" }
}

3.8 MCP 如何建立在 JSON-RPC 之上

MCP 将 JSON-RPC 作为数据层协议 。MCP 的所有核心操作------tools/list、tools/call、resources/read、prompts/get------都是通过 JSON-RPC 消息来完成的。MCP 在 JSON-RPC 之上定义了具体的 method 名称、params 结构、result 格式以及错误码语义。

4. MCP 的生命周期与协议交互

4.1 MCP 请求是怎么产生的

请求由 MCP Client 发起。当 Host（如 Claude Desktop）需要调用一个工具或读取一个资源时，它会通过 MCP Client 发送一个 JSON-RPC 请求到 MCP Server。

4.2 Client 如何了解 Server

在 2026-07-28 规范中，Client 可以通过可选的 server/discover RPC 预先了解 Server 支持的能力。但这不是必需的------每个请求都自描述，可以直接发送。

4.3 Capability 是什么

Capability 是 Server 或 Client 声明自己支持的功能集合。Server 通过 Capabilities 告诉 Client 它提供了哪些 Tools、Resources、Prompts。

4.4 Discovery

Discovery 是 Client 发现 Server 能力的过程。可以通过 server/discover 主动获取，也可以在后续请求中逐步发现。

4.5 Request / Response 的完整生命周期

Client 构造 JSON-RPC 请求
请求通过 Transport（STDIO 或 Streamable HTTP）发送到 Server
Server 解析请求、执行业务逻辑
Server 构造 JSON-RPC 响应
响应通过 Transport 返回 Client

4.6 Stateless MCP 与 Stateful Application

这是 2026-07-28 规范最核心的变化。

旧规范（2025-11-25 及之前）要求 Client 和 Server 之间先完成 initialize / initialized 握手，建立会话（Session），后续所有请求都绑定到这个会话。

新规范彻底移除了握手和会话：

退休了 initialize / initialized 交换
退休了 Mcp-Session-Id Header
每个请求独立携带协议版本、Client 身份和 Capabilities（在 _meta 中）
任何请求都可以落在负载均衡的任意实例上，无需共享存储

这意味着 MCP Server 现在可以无状态地水平扩展，天然适配普通 HTTP 基础设施。这正是为了改善远程部署、负载均衡和扩展性。

5. MCP 的核心 Primitive：Tools、Resources、Prompts

5.1 Tools

Tool 是 MCP 中最核心的 Primitive------它代表 Server 暴露的一个"可执行操作"。

5.1.1 Tool 是什么

Tool 是一个可被 AI 调用的函数。它有一个名称、一段描述、一个输入参数的 Schema（JSON Schema），以及一段执行逻辑。

5.1.2 `tools/list`

Client 调用 tools/list 获取 Server 提供的所有 Tool 列表。

5.1.3 Tool Schema

Tool 的输入参数使用 JSON Schema 2020-12 标准定义。在 TypeScript SDK 中，可以使用 Zod 来定义 Schema。

5.1.4 `tools/call`

Client 调用 tools/call 来执行一个 Tool。请求中需要指定 Tool 名称和参数。

5.1.5 Tool Arguments

参数以 JSON 对象形式传递，必须符合 Tool Schema 的定义。

5.1.6 Tool Result

Tool 执行完成后返回结果，结果可以是文本、结构化数据或多种内容的组合。

5.1.7 Tool Error

如果 Tool 执行失败，Server 返回 JSON-RPC 错误响应，包含错误码和错误信息。

5.2 Resources

5.2.1 Resource 是什么

Resource 代表 Server 提供的可读取的数据------文档、文件、数据库记录等。

5.2.2 Resource URI

每个 Resource 有一个唯一的 URI，Client 通过 URI 来读取它。

5.2.3 `resources/list`

Client 调用 resources/list 获取 Server 提供的所有 Resource 列表。

5.2.4 `resources/read`

Client 调用 resources/read 读取某个 Resource 的内容。

5.2.5 Resource Template

Resource Template 允许动态生成 Resource URI（例如 /users/{id}/profile），Client 填入参数后即可读取对应的 Resource。

5.2.6 Resource 与 Tool 的区别

Resource 是"读数据"------获取信息，无副作用
Tool 是"做事情"------执行操作，可能有副作用

5.3 Prompts

5.3.1 Prompt 是什么

Prompt 是 Server 提供的结构化提示词模板。Client 可以获取这些模板，填充参数后发送给 LLM。

5.3.2 `prompts/list`

Client 调用 prompts/list 获取 Server 提供的所有 Prompt 列表。

5.3.3 `prompts/get`

Client 调用 prompts/get 获取某个 Prompt 的完整内容。

5.3.4 MCP Prompt 与普通 System Prompt 的区别

普通 System Prompt 是硬编码在 Agent 中的；MCP Prompt 是由 Server 动态提供的，可以根据上下文动态生成，且支持参数化。

6. 一次 Tool Calling 究竟是怎么发生的

从协议报文层面完整走一遍 Tool Calling 的全过程。

6.1 Client 发现 Tool

复制代码

→ {"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}

6.2 Server 返回 Tool Definition

复制代码

← {"jsonrpc":"2.0","id":1,"result":{"tools":[
     {"name":"search","description":"Search the web",
      "inputSchema":{"type":"object","properties":{"q":{"type":"string"}}}}
   ]}}

6.3 Agent 将 Tool 提供给 LLM

Agent 把 Tool 列表（名称、描述、参数 Schema）通过 Function Calling 的格式传递给 LLM。

6.4 LLM 决定调用 Tool

LLM 根据用户的问题和 Tool 的描述，决定调用某个 Tool，并生成参数。

6.5 Client 发起 `tools/call`

在 2026-07-28 规范中，请求的协议版本、方法名和 Tool 名称都通过 HTTP Header 传递：

复制代码

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search

{"jsonrpc":"2.0","id":2,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"}},
 "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-client"}}}

这样设计的好处是：网关和负载均衡器可以直接通过 Header 路由和授权，无需解析 JSON Body。

6.6 Server 执行真正的业务逻辑

Server 解析请求，根据 name 找到对应的 Tool 实现，用 arguments 调用真正的业务逻辑（API、数据库、文件系统等）。

6.7 Server 返回 Tool Result

复制代码

← {"jsonrpc":"2.0","id":2,"result":{
     "content":[{"type":"text","text":"Otters are semiaquatic mammals..."}]
   }}

6.8 Client 将结果交给模型

Client 将 Tool Result 传递给 Agent，Agent 将其作为 Function Calling 的结果返回给 LLM。

6.9 模型生成最终答案

LLM 根据 Tool 返回的结果，生成最终的自然语言回答。

总结：

整个流程的第一步是配置和启动。MCP 支持两种连接方式，分别对应本地和远程场景。对于本地运行的 MCP Server，我们需要在配置中提供启动命令和参数，Host 启动时会直接将它作为子进程拉起，双方通过 STDIO（标准输入输出）进行通信；而对于远程部署的 MCP Server，配置中只需要提供它的 URL 地址，Host 会通过 Streamable HTTP 协议直接向该地址发送请求。所有这些 Server 的信息都会统一存放在一个大列表或字典中，由 Host 集中管理。Host 启动后，会立即遍历这个列表，与每个 MCP Server 建立连接，并马上调用 tools/list 方法去拉取所有可用的工具列表，然后把这些列表缓存在内存中，方便后续使用，而不必每次都去询问 Server。

用户发起提问后，就进入了决策环节。此时 Host 并不会直接去调用工具，而是先把缓存在内存中的所有工具定义拿出来，经过格式转换后，连同用户的原始问题一起发送给大模型。注意，这里发送给大模型的并不是原始的 MCP 报文，而是各大模型 API 原生支持的 tools 参数结构。大模型看到当前可用的所有工具描述后，会根据用户的具体问题做出判断。如果它认为需要调用某个工具，它会在响应中返回一个 tool_calls 指令，里面明确包含了要调用的工具名称，以及填充好的具体参数值，也就是 Tool Arguments，例如 {"city": "长沙"}。这里一定要区分清楚，大模型返回的是具体的参数值，而不是用来描述参数规则的 JSON Schema，因为那把校验用的"尺子"已经在请求大模型时给它看过了，它只需要给出符合这把尺子要求的"答案"即可。

Host 收到大模型返回的调用指令后，开始执行请求。它会从 tool_calls 中提取出工具名称和具体的参数值，然后封装成一个标准的 JSON-RPC 请求，其中的 method 字段设置为 tools/call，并将工具名和 Arguments 填入 params 中，发送给对应的 MCP Server。这个 JSON-RPC 请求会通过我们之前配置好的连接方式（STDIO 或 Streamable HTTP）传输过去。MCP Server 收到请求后，会立刻做一件事：校验。它会拿出自己提前定义好的那把"尺子"，也就是 Tool Schema（符合 JSON Schema 规范），去校验收到的参数值类型是否正确、必填字段是否齐全。只有校验完全通过，Server 才会去调用真正的业务逻辑，比如请求第三方天气 API 或操作数据库。执行完毕后，Server 将结果封装在 JSON-RPC 的响应中返回给 Client。

最后一步是把结果转化为用户能看懂的答案。Client 拿到 Server 返回的 Tool Result 后，并不会直接输出，而是会开启第二轮与大模型的对话。它将工具的执行结果拼接到上下文中，作为一个类型为 tool 角色的消息发送给大模型。大模型接收到这个执行结果后，终于拥有了回答问题的依据，它会根据这些信息组织语言，最终生成一段自然流畅的文字回复给用户。至此，一次完整的 Tool Calling 流程才算真正结束。

7. MCP Transport：消息到底怎么传过去

7.1 Transport 是什么

Transport 是 MCP 的传输层，负责 Client 和 Server 之间的实际通信。MCP 定义了两个标准 Transport。

7.2 STDIO

STDIO Transport 中，Client 将 MCP Server 作为子进程启动，通过标准输入（stdin）读取消息，通过标准输出（stdout）发送消息。消息以换行符分隔。Server 可以通过 stderr 输出日志。

STDIO 主要用于本地部署，是桌面 IDE 客户端中最快的起步方式。

7.3 Streamable HTTP

Streamable HTTP 是在 2025-03-26 版本中引入的，用于替代旧的 HTTP+SSE Transport。

在 2026-07-28 规范中，Streamable HTTP 的行为发生了变化：

移除了 GET 流端点
移除了协议级会话
Server 暴露单个 HTTP POST 端点
Client 每个 JSON-RPC 请求独立发送一个 HTTP POST
Server 可以用单个 JSON 对象或 SSE 流响应
Server-to-Client 交互（如 elicitation）通过 Multi Round-Trip Requests (MRTR) 实现

7.4 Local MCP 的通信方式

本地 MCP 使用 STDIO Transport。

7.5 Remote MCP 的通信方式

远程 MCP 使用 Streamable HTTP Transport。

7.6 HTTP Headers

在 2026-07-28 规范中，Streamable HTTP 要求 Client 在每个 POST 请求中包含以下 Header：

MCP-Protocol-Version: 2026-07-28------协议版本
Mcp-Method: tools/call------JSON-RPC 方法名
Mcp-Name: search------Tool/Resource 名称（如适用）

Client 还必须包含 Accept Header，同时支持 application/json 和 text/event-stream。

7.7 Streaming

Server 可以通过 Server-Sent Events (SSE) 流式返回响应，在同一个流中先发送相关通知，最后发送最终响应。

7.8 为什么旧的 HTTP+SSE 已经被弃用

旧的 HTTP+SSE Transport（来自 2024-11-05 规范）已被 Streamable HTTP 取代。主要原因：

HTTP+SSE 依赖长连接和会话状态，不利于水平扩展
Streamable HTTP 更符合标准 HTTP 语义，更易于部署在普通 HTTP 基础设施上

8. MCP 的 Capability 与协议扩展

8.1 Capability 是什么

Capability 是 Client 或 Server 声明自己支持的功能集合。

8.2 Client Capabilities

Client 声明自己支持的能力，例如支持 sampling、支持 elicitation 等。

8.3 Server Capabilities

Server 声明自己提供的能力，例如提供了哪些 Tools、Resources、Prompts。

8.4 为什么 MCP 需要 Capability Negotiation

因为不同的 Client 和 Server 可能有不同的能力。通过 Capability Negotiation，双方可以了解对方支持什么，从而做出合理的交互决策。

8.5 Extension 是什么

Extension 是 MCP 的扩展机制------允许在核心协议之外添加新能力，而无需修改核心协议。

8.6 Core 与 Extension 的区别

Core：协议的核心部分，所有实现都必须支持
Extension：可选扩展，由需要特定能力的实现选择性支持

8.7 MCP 如何进行协议演进

2026-07-28 规范正式建立了 Extensions Framework。一些能力（如 Tasks）已经从实验性核心功能转为正式扩展。这保证了核心协议的稳定性，同时允许生态快速创新。

9. MCP 的高级能力

9.1 Sampling（已弃用）

Sampling 允许 Server 请求 Client 从 LLM 采样。在 2026-07-28 规范中已被标记为 deprecated。

9.2 Elicitation

Elicitation 允许 Server 向 Client 请求额外信息（如用户输入）。在 2026-07-28 规范中通过 MRTR 实现。

9.3 Tasks（Extension）

Tasks 支持长时间运行的操作。在 2026-07-28 规范中，Tasks 已从实验性核心功能转为正式扩展。

9.4 Notifications

Notification 是单向消息，不需要响应。用于事件通知等场景。

9.5 Subscriptions

Subscription 允许 Client 订阅 Server 的变更通知。

9.6 Annotations

Annotations 为消息添加额外的元数据信息。

9.7 Structured Content

MCP 支持结构化的内容返回，不仅限于纯文本。

9.8 MCP Apps（Extension）

MCP Apps 允许 Server 渲染交互式 UI，直接在对话中展示。是 2026-07-28 规范中首批正式扩展之一。

重要提示：MCP 不同版本之间变化很快。Roots、Sampling、Logging 在 2026-07-28 规范中已被标记为 deprecated，新实现不建议继续采用。

10. MCP 的安全与授权

10.1 为什么 MCP Server 是安全边界

MCP Server 是 AI 应用访问外部系统的入口。一旦 Server 被攻破或滥用，攻击者可能通过 AI 应用间接访问敏感系统。因此 Server 是安全的关键边界。

10.2 MCP Authentication

Authentication 验证"谁"在调用。2026-07-28 规范强化了认证机制，包括 RFC 9207 issuer validation。

10.3 OAuth

MCP 支持 OAuth 2.1 作为授权框架。OAuth 提供委托用户授权、令牌生命周期管理和携带 scope 的凭证。

10.4 Authorization

Authorization 评估"这个调用者能否执行这个具体操作"。OAuth 提供的是框架，而运行时授权需要策略执行机制来判断每个具体操作是否应该执行。

10.5 Client Identity

在 2026-07-28 规范中，每个请求在 _meta 中携带 Client 身份信息。

10.6 Token 与 Credential

2026-07-28 规范将凭证更紧密地绑定到特定 issuer，减少了跨 issuer 的凭证重用风险。

10.7 权限控制

2026-07-28 规范正式弃用了 Dynamic Client Registration (DCR)，转向 Client ID Metadata Documents (CIMD)。

10.8 Tool Abuse

Tool 可能被滥用------例如调用删除数据的工具、发送大量邮件的工具。需要通过运行时授权来防范。

10.9 Prompt Injection

攻击者可能通过精心构造的输入，诱导模型调用非预期的 Tool。需要在使用 Tool 前进行校验和授权。

10.10 Confused Deputy

Confused Deputy 攻击是指一个权限较高的实体被欺骗去执行攻击者的指令。MCP 中需要确保 Tool 调用的目标和参数是经过授权的。

10.11 Remote MCP 的安全问题

远程 MCP 暴露在网络上，面临更多安全挑战。Streamable HTTP Transport 要求 Server 验证 Origin Header 以防止 DNS rebinding 攻击，本地运行时应该只绑定 localhost。

11. 从零实现一个 MCP Server

11.1 MCP Server 最小结构

一个完整的 MCP Server 可以只有一个文件。使用 TypeScript SDK：

typescript 复制代码

import { McpServer } from '@modelcontextprotocol/server';
import { serveStdio } from '@modelcontextprotocol/server/stdio';
import * as z from 'zod/v4';

11.2 创建第一个 Tool

typescript 复制代码

serveStdio(() => {
  const server = new McpServer({ name: 'weather', version: '1.0.0' });

11.3 定义 Tool Schema

使用 Zod 定义输入参数的 Schema：

typescript 复制代码

  server.registerTool(
    'get-forecast',
    {
      description: 'Get the weather forecast for a city',
      inputSchema: z.object({ city: z.string() })
    },

11.4 启动 STDIO Server

typescript 复制代码

    async ({ city }) => ({
      content: [{ type: 'text', text: `Sunny in ${city} all week.` }]
    })
  );
  return server;
});

11.5 用 MCP Client 连接

任何 MCP Host（Claude Code、VS Code、你自己的应用）启动这个程序后，就可以发现并调用 get-forecast Tool。

11.6 发现 Tool

Host 通过 tools/list 发现 Server 提供的所有 Tool。

11.7 调用 Tool

Host 通过 tools/call 调用 Tool，SDK 会自动用 Zod Schema 校验参数。

11.8 返回 Tool Result

Handler 返回的结果会被自动包装成标准的 MCP Tool Result。

11.9 从 STDIO 改成 Streamable HTTP

将 serveStdio 替换为相应的 HTTP Server 集成（Express、Hono、Fastify 等）。

12. 从零实现一个 MCP Client

12.1 为什么需要 MCP Client

MCP Client 是 Host 与 MCP Server 之间的桥梁。如果你在构建一个 AI 应用，需要连接各种 MCP Server，你就需要实现或使用 MCP Client。

12.2 建立连接

Client 通过 Transport（STDIO 或 Streamable HTTP）与 Server 建立连接。

12.3 获取 Server 能力

Client 可以通过 server/discover 获取 Server 的能力。

12.4 获取 Tools

Client 调用 tools/list 获取所有 Tool 列表。

12.5 调用 Tool

Client 调用 tools/call 执行 Tool。

12.6 处理 Result

Client 解析 Tool Result，提取内容交给 Host。

12.7 把 MCP Tool 接入 LLM

Client 将 Tool 列表转换为 LLM 的 Function Calling 格式，将 Tool Result 转换为 Function Calling 的返回结果。

12.8 一个最小 Agent + MCP 架构

复制代码

User → LLM → Agent Runtime → MCP Client → MCP Server → Tool

13. MCP Server 到底应该部署在哪里

13.1 本地 MCP Server

复制代码

Agent → 启动进程 → STDIO → MCP Server

本地 Server 通过 STDIO 与 Agent 通信，适合开发测试和单用户场景。

13.2 远程 MCP Server

复制代码

Agent → Internet → Streamable HTTP → MCP Server

远程 Server 通过 Streamable HTTP 提供服务，适合多用户和生产环境。

13.3 Docker

MCP Server 可以容器化部署，便于环境一致性和分发。

13.4 Kubernetes

远程 MCP Server 可以部署在 K8s 集群中，利用 K8s 的服务发现和负载均衡能力。

13.5 Load Balancer

2026-07-28 规范的无状态设计意味着 MCP Server 可以部署在普通轮询负载均衡器后面，无需共享存储。

13.6 Stateless Server

无状态 Server 不保存任何会话状态，每个请求独立处理。

13.7 多实例部署

无状态设计让多实例部署变得简单------任意请求可以路由到任意实例。

13.8 Gateway

Gateway 可以通过 Mcp-Method 和 Mcp-Name Header 直接路由和授权请求，无需解析 Body。

13.9 企业内部 MCP

企业可以在内部网络部署 MCP Server，通过 MCP Tunnels 安全连接到外部 AI 应用。

14. MCP 与其他技术到底是什么关系

技术	解决的问题
Function Calling	模型如何表达工具调用
REST API	服务如何提供 HTTP 接口
RPC	服务间如何调用
OpenAPI	REST API 如何描述
MCP	AI 应用如何标准化发现与使用上下文/工具能力
Agent Framework	如何组织 Agent 的执行过程

MCP 不是要替代 REST API 或 RPC，而是在它们之上增加一层面向 AI 应用的标准化接入层。

15. 一个生产级 MCP 系统长什么样

生产级 MCP 系统需要关注：

Tool Registry：Tool 的注册、发现和管理
Authentication：Client 身份认证
Authorization：细粒度的权限控制
Rate Limiting：防止滥用
Timeout：防止长时间阻塞
Retry：处理临时故障
Logging：操作审计
Observability：监控和告警
Metrics：性能指标
Tool Schema 管理：Schema 版本控制
Versioning：协议和 Tool 的版本管理
Compatibility：向后兼容

完整架构：

复制代码

                     ┌───────────────┐
                     │      LLM      │
                     └───────┬───────┘
                             │
                             ▼
                     ┌───────────────┐
                     │ Agent Runtime │
                     └───────┬───────┘
                             │
                       MCP Client
                             │
                    Streamable HTTP
                             │
                             ▼
                ┌─────────────────────────┐
                │       MCP Server        │
                │                         │
                │ Tool / Resource / ...   │
                └────────────┬────────────┘
                             │
            ┌────────────────┼────────────────┐
            ▼                ▼                ▼
          API             Database         Files

16. MCP 的发展与未来

16.1 MCP 从本地 Tool 协议开始

MCP 最初是作为本地 Tool 协议设计的，主要用于桌面 IDE 场景。

16.2 生态快速发展

MCP 已成为连接 AI Agent 到应用的事实标准，TypeScript 和 Python SDK 月下载量接近 5 亿次。

16.3 从 Stateful 到 Stateless

2026-07-28 规范的最大变化是从有状态双向协议转向无状态请求/响应模型。

16.4 从 Core Features 到 Extensions

建立了正式的 Extensions Framework，MCP Apps 和 Tasks 成为首批正式扩展。

16.5 Remote MCP

无状态设计让 MCP Server 可以部署在 Serverless 和 Edge 基础设施上。

16.6 Enterprise MCP

企业级功能持续增强，包括 Enterprise-Managed Authorization (EMA)、Observability 仪表板等。

16.7 Agentic Messaging

MCP 的 Roadmap 重点包括 agentic messaging、HTTP-native transport、agent identity、enterprise security 等方向。

16.8 MCP 下一步会解决什么问题

未来 MCP 将继续向分布式 Agent 通信 、更完善的企业安全 、更丰富的交互模式方向演进。

17. 总结：真正理解 MCP

17.1 MCP 的核心抽象

MCP 的核心抽象是 Tools（可执行操作）、Resources（可读数据）、Prompts（提示词模板）------三种 Server 可以暴露给 AI 应用的能力。

17.2 MCP 的完整请求链路

复制代码

用户 → Host → Client → JSON-RPC → Transport → Server → 外部系统 → 原路返回

17.3 MCP 与 Agent 的关系

MCP 是 Agent 的工具接入层，不是 Agent 本身。Agent 负责决策和编排，MCP 负责标准化接入。

17.4 MCP 与 Function Calling 的关系

Function Calling 是模型侧 的协议（模型如何表达调用意图），MCP 是系统侧的协议（系统如何标准化地提供可调用能力）。两者互补，不互相替代。

17.5 一个 MCP Server 本质上是什么

MCP Server 本质上是一个适配层------把任意外部能力（API、数据库、文件、消息队列）包装成 MCP 标准化的 Tools、Resources 和 Prompts。

17.6 什么时候应该使用 MCP

你需要让 AI 应用接入多种外部工具/数据源
你希望工具接入是标准化的、可插拔的
你需要支持多种 AI 应用（Claude、Cursor、VS Code、自研应用）接入同一套工具

17.7 什么时候没必要使用 MCP

你只有一个工具、一个 AI 应用，且未来不会扩展
你的场景非常简单，自定义集成比学习 MCP 成本更低
你不需要多应用、多工具的标准化接入

MCP 的本质不是"让大模型调用函数"，而是为 AI 应用访问外部工具、数据和能力定义了一套标准化的协议层。

MCP概念与实践全解析

目录

1. MCP 到底解决了什么问题

1.1 从 Function Calling 到 MCP

1.2 为什么 Tool Calling 还需要协议

1.3 没有 MCP 的 Agent 是怎么接工具的

1.4 Tool Integration 为什么会越来越复杂

1.5 MCP 的核心目标是什么

1.6 MCP 解决什么，不解决什么

2. MCP 的整体架构

2.1 MCP 中有哪些角色

2.2 Host、Client、Server 分别是什么

2.3 MCP 在 Agent 架构中的位置

2.4 Client 与 Server 是什么关系

2.5 MCP Server 后面到底连接着什么

2.6 本地 MCP 与远程 MCP

3. MCP 协议的基础：JSON-RPC

3.1 为什么 MCP 需要消息协议

3.2 JSON-RPC 是什么

3.3 Request

3.4 Response

3.5 Notification

3.6 Request ID

3.7 Error

3.8 MCP 如何建立在 JSON-RPC 之上

4. MCP 的生命周期与协议交互

4.1 MCP 请求是怎么产生的

4.2 Client 如何了解 Server

4.3 Capability 是什么

4.4 Discovery

4.5 Request / Response 的完整生命周期

4.6 Stateless MCP 与 Stateful Application

5. MCP 的核心 Primitive：Tools、Resources、Prompts

5.1 Tools

5.1.1 Tool 是什么

5.1.2 tools/list

5.1.3 Tool Schema

5.1.4 tools/call

5.1.5 Tool Arguments

5.1.6 Tool Result

5.1.7 Tool Error

5.2 Resources

5.2.1 Resource 是什么

5.2.2 Resource URI

5.2.3 resources/list

5.2.4 resources/read

5.2.5 Resource Template

5.2.6 Resource 与 Tool 的区别

5.3 Prompts

5.3.1 Prompt 是什么

5.3.2 prompts/list

5.3.3 prompts/get

5.3.4 MCP Prompt 与普通 System Prompt 的区别

6. 一次 Tool Calling 究竟是怎么发生的

6.1 Client 发现 Tool

6.2 Server 返回 Tool Definition

6.3 Agent 将 Tool 提供给 LLM

6.4 LLM 决定调用 Tool

6.5 Client 发起 tools/call

6.6 Server 执行真正的业务逻辑

6.7 Server 返回 Tool Result

6.8 Client 将结果交给模型

6.9 模型生成最终答案

7. MCP Transport：消息到底怎么传过去

7.1 Transport 是什么

7.2 STDIO

7.3 Streamable HTTP

7.4 Local MCP 的通信方式

7.5 Remote MCP 的通信方式

7.6 HTTP Headers

7.7 Streaming

7.8 为什么旧的 HTTP+SSE 已经被弃用

8. MCP 的 Capability 与协议扩展

8.1 Capability 是什么

8.2 Client Capabilities

8.3 Server Capabilities

8.4 为什么 MCP 需要 Capability Negotiation

8.5 Extension 是什么

8.6 Core 与 Extension 的区别

8.7 MCP 如何进行协议演进

5.1.2 `tools/list`

5.1.4 `tools/call`

5.2.3 `resources/list`

5.2.4 `resources/read`

5.3.2 `prompts/list`

5.3.3 `prompts/get`

6.5 Client 发起 `tools/call`