MCP 完全指南：它是什么、怎么来的、为什么管用

Posted on In Word count in article: 6.5k Reading time ≈ 24 mins.
讲清楚 Model Context Protocol：它解决的 M×N 集成问题、2024 年发布以来的规范演进（含 2026-07-28 的无状态改造）、 Host/Client/Server 架构、工具/资源/提示三大原语、OAuth 授权、与 Skill 和 Function Calling 的区别，以及安全风险。

写于 2026-10-01。协议细节依据 modelcontextprotocol.io 官方文档与规范（当前最新版本号为 2026-07-28）；发展时间线中的早期日期与厂商采用情况来自第三方汇总，文中已标明。MCP 迭代很快，写代码前请以官方规范为准。

0. 一句话版本

MCP（Model Context Protocol）是一个开放协议，规定了"AI 应用"如何以统一方式连接"外部系统"（数据、工具、工作流）。 官方的比喻是 AI 应用的 USB-C 接口：设备和外设不用互相适配，都遵守同一个接口标准就能连。

记三件事：

  1. 解决的问题：M 个 AI 应用 × N 个外部系统，原本要写 M×N 套对接；有了协议，变成 M+N。
  2. 形态：Client–Server 架构，消息是 JSON-RPC 2.0，传输方式有 stdio（本地进程）和 Streamable HTTP（远程）。
  3. 服务端提供三类东西：Tools（模型可调用的函数）、Resources（供读取的上下文数据）、Prompts（可复用的提示模板）。

MCP 只管"上下文怎么交换"，不管模型怎么用这些上下文——官方原话大意是它"不规定 AI 应用如何使用 LLM 或管理所提供的上下文"。

1. 先看一个眼前的例子

我现在用的 Claude Code 会话里，工具列表里有一大堆名字长这样的东西：

mcp__Claude_Browser__navigate
mcp__terminal__run_in_terminal
mcp__computer-use__app_screenshot
mcp__claude-in-chrome__read_page
...

mcp__<服务器名>__<工具名> 就是 Claude Code 给 MCP 工具起名的约定。每个"服务器"是一个独立的程序：有的跑在本机（控制浏览器、终端、桌面），有的在云端（Figma、Notion、GitHub 等需要登录授权的连接器）。Claude Code 本身不知道怎么操作 Figma，它只是个 MCP Host：连上 Figma 的 MCP 服务器，问它"你有什么工具"，然后把这些工具交给模型用。

另外一个有意思的现象：这些工具里很多一开始只显示名字，要先调一次"ToolSearch"才能拿到完整参数定义再使用——这是为了省上下文，后面第 5 章会解释为什么这是 MCP 的一个真实痛点。

2. 为什么需要 MCP：M×N 问题

2.1 没有协议的时代

大模型要"做事"，得能调用外部能力。2023 年 6 月起 OpenAI 提出的 Function Calling 让模型能输出结构化的函数调用，各家随后都有类似机制。但：

  • 每个 AI 应用（IDE、聊天客户端、Agent 框架）都要自己写每个外部系统的对接代码；
  • 每个外部系统（GitHub、Slack、数据库）也得为每个 AI 应用各做一套插件。
没有协议：                         有 MCP：
 AI 应用 A ──┬── GitHub             AI 应用 A ─┐            ┌─ GitHub MCP server
 AI 应用 A ──┼── Slack              AI 应用 B ─┼── MCP ──────┼─ Slack MCP server
 AI 应用 B ──┼── GitHub             AI 应用 C ─┘            └─ 数据库 MCP server
 AI 应用 B ──┼── Slack
 ...  M × N 套对接                    M + N 套实现

2.2 它借鉴了谁

官方规范里明确写道：MCP 的灵感来自 LSP（Language Server Protocol）。LSP 让"支持一门语言"和"编辑器"解耦——写一个语言服务器，所有支持 LSP 的编辑器都能用。MCP 把同样的思路用在"AI 应用 × 外部上下文"上。

2.3 它和 Function Calling 的关系

Function Calling 是模型层的能力：模型怎么表达"我要调用函数 X，参数是 Y"。MCP 是应用层的协议：这些函数从哪来、怎么发现、怎么执行。二者是上下两层，不是替代关系——Host 把 MCP 服务器提供的工具转换成模型 API 里的工具定义，模型用 Function Calling 的方式调用，Host 再把调用转发给 MCP 服务器执行。

3. 来龙去脉：发展时间线

3.1 规范版本（官方版本号，以日期命名）

版本 主要内容
2024-11-05 初版：Client–Server 架构、JSON-RPC 2.0、三大原语（tools / resources / prompts）、两种传输（stdio、HTTP+SSE）
2025-03-26 引入 OAuth 2.1 授权；用 Streamable HTTP 取代 HTTP+SSE；工具注解、音频内容、参数补全
2025-06-18 结构化工具输出、Elicitation（服务器向用户追问信息）、资源链接、MCP 服务器被归类为 OAuth 资源服务器
2025-11-25 授权引入 OpenID Connect Discovery、图标元数据、JSON Schema 2020-12 等
2026-07-28（当前） 协议无状态化、server/discover、Multi Round-Trip Requests、Tasks 与 Apps 扩展机制、正式的特性弃用政策

上表以第三方整理为底稿，并与官方 changelog 交叉核对过 2026-07-28 一版的内容（见第 4.5 节）；更早几个版本的细节以官方各版本规范页为准。

3.2 关键事件

  • 2024-11 下旬：Anthropic 开源发布 MCP（据公开资料，由 David Soria Parra 与 Justin Spahr-Summers 在 Anthropic 创建），同时放出 Python / TypeScript SDK 和一批参考服务器（Google Drive、Slack、GitHub、Git、Postgres 等）。首批合作方包括 Block、Apollo，以及 Zed、Replit、Codeium、Sourcegraph 等开发工具。（各来源对发布日期有 11-25 与 11-26 的出入，这里只写"11 月下旬"。）
  • 2025-03 ~ 05：据第三方汇总，OpenAI 在 Agents SDK 里支持 MCP，Microsoft 把它接入 Copilot Studio 并逐步成为各平台的一等公民，Google 也表态让 Gemini 支持 MCP——竞争对手相继采用，使它从"Anthropic 的协议"变成了行业事实标准。
  • 2025-09：官方 MCP Registry（服务器注册表）预览上线。
  • 2025-12：Anthropic 把 MCP 捐给 Linux Foundation 旗下新成立的 Agentic AI Foundation（AAIF），据报道由 Anthropic、Block、OpenAI 共同发起——协议治理从单一公司转向中立基金会。
  • 2026-07-28：规范大改（无状态），见 4.5。

3.3 一条主线

2023   Function Calling：模型能"表达"调用
2024-11 MCP：把"工具从哪来、怎么接"标准化（Client–Server，本地为主）
2025-03 加上 OAuth 与 Streamable HTTP：走向"远程、多租户、需授权"的服务
2025-06~11 结构化输出、Elicitation：交互更丰富、授权更完善
2025-12 捐给基金会：中立治理
2026-07 无状态化：为大规模部署（负载均衡、无服务器）铺路

可以看出方向：从"本地进程间的小玩具"演变成"可大规模部署的远程服务协议"。

4. 协议到底长什么样

4.1 三个角色

角色 是什么 例子
Host（宿主） 面向用户的 AI 应用，负责协调一个或多个 Client Claude Code、Claude Desktop、VS Code、Cursor
Client（客户端） Host 里的连接器组件，每连一个服务器就实例化一个，维持专用连接 VS Code 连 Sentry 就有一个 Client，连文件系统服务器再有一个
Server（服务器） 提供上下文和能力的程序，本地还是远程都叫 server 本地的 filesystem server；Sentry 官方的远程 server 
┌────────────── Host（AI 应用）──────────────┐
│  Client 1 ──── 专用连接 ──── Server A（本地，stdio）
│  Client 2 ──── 专用连接 ──── Server B（本地，stdio）
│  Client 3 ──── 专用连接 ──┐
│  Client 4 ──── 专用连接 ──┴─ Server C（远程，Streamable HTTP，服务多个 Client）
└──────────────────────────────────────────────┘

4.2 两层结构

  • 数据层（内层）：基于 JSON-RPC 2.0 的消息格式与语义——发现、原语（tools / resources / prompts）、通知、进度。
  • 传输层（外层）：消息怎么送达——连接建立、成帧、认证。

两种传输：

传输 适用 特点
stdio 本地：Host 把服务器当子进程启动，通过标准输入输出通信 零网络开销；通常一对一；服务器以你的用户权限运行
Streamable HTTP 远程：POST 发请求，可选用 SSE 流式返回 一个服务器服务很多客户端；支持 Bearer Token、API Key 等；规范推荐用 OAuth

（早期的 HTTP+SSE 传输已被弃用，新实现应使用 Streamable HTTP。）

4.3 服务器能提供的三种原语

原语 是什么 谁来控制 典型例子
Tools 可执行的函数 模型决定何时调用 查数据库、发消息、操作文件
Resources 提供上下文的数据源 应用/用户选择放进上下文 文件内容、数据库表结构、API 响应
Prompts 可复用的提示模板 用户显式触发 带示例的系统提示、工作流模板

每种原语都有统一的方法：*/list 发现，*/get 获取，tools/call 执行。比如一个数据库服务器可以：提供查询工具，暴露表结构资源，再附带一个含 few-shot 示例的提示。

客户端也能向服务器提供能力：目前核心的是 Elicitation（服务器中途向用户追问信息或请求确认）。

4.4 一次真实交互是什么样

下面是官方文档里的简化例子（2026-07-28 版）。

① 工具发现——客户端问有哪些工具：

{ "jsonrpc": "2.0", "id": 2, "method": "tools/list",
  "params": { "_meta": { "io.modelcontextprotocol/protocolVersion": "2026-07-28" } } }

服务器返回每个工具的 name、description 和 inputSchema（JSON Schema）：

{ "name": "weather_current",
  "description": "Get current weather information for any location worldwide",
  "inputSchema": { "type": "object",
    "properties": { "location": {"type": "string"}, "units": {"type": "string", "enum": ["metric","imperial","kelvin"]} },
    "required": ["location"] } }

② 工具调用——模型决定调用后，Host 通过 Client 发出：

{ "jsonrpc": "2.0", "id": 3, "method": "tools/call",
  "params": { "name": "weather_current",
              "arguments": { "location": "San Francisco", "units": "imperial" } } }

③ 返回结果——一个 content 数组，可以是文本、图片、资源等：

{ "jsonrpc": "2.0", "id": 3,
  "result": { "resultType": "complete",
              "content": [ { "type": "text", "text": "Current weather in San Francisco: 68°F, partly cloudy…" } ] } }

整个流程对模型是透明的：模型看到的只是"有一个叫 weather_current 的工具，参数如此"，调用后得到一段文本。MCP 的全部工作都发生在 Host 与服务器之间。

4.5 2026-07-28：为什么改成"无状态"

之前（到 2025-11-25）的流程是：连接建立后先 initialize 握手协商版本和能力，服务器再通过 Mcp-Session-Id 维持会话。会话是有状态的，意味着请求必须落到同一台服务器，不利于负载均衡和无服务器部署。

2026-07-28 版的主要改动（来自官方 changelog）：

改动 含义
移除协议级会话与 Mcp-Session-Id 列表接口不再随连接而异；需要跨调用状态的，由服务器发"句柄"，作为普通工具参数传递
移除 initialize 握手 每个请求自带协议版本和客户端能力（放在 _meta 字段），服务器逐请求独立处理
新增 server/discover 服务器必须实现，用来声明支持的版本、能力、身份；客户端可选地在最前面调一次，结果可缓存
subscriptions/listen 取代原来的 GET 端点和 resources 订阅：一个长连接流，客户端主动声明想收哪些变更通知
Multi Round-Trip Requests 取代"服务器反向发请求"：服务器返回 input_required，客户端带着答案重试原请求
Tasks 移出核心 长任务变成官方扩展：轮询 tasks/get
缓存提示 列表类结果必带 ttlMs、cacheScope，减少轮询
弃用 Roots、Sampling、Logging 保留一个弃用窗口（政策要求至少 12 个月）；建议直接对接 LLM 供应商 API、用 stderr/OpenTelemetry 打日志
Dynamic Client Registration 弃用 授权侧改推 Client ID Metadata Documents

这是我的归纳：整体方向是"让 MCP 服务器像普通 HTTP API 一样好部署"——无状态请求可以随便打到任意实例后面，配合缓存头就能放到 CDN/网关之后。

4.6 扩展机制

核心协议之外，规范定义了可选扩展（双方协商启用）。官方列出的包括：

  • Tasks：长任务（轮询、中途输入、持久句柄）。
  • MCP Apps：在对话里直接渲染交互式界面（图表、表单、视频播放器）。
  • Skills over MCP：通过 MCP 发现和使用结构化的 Agent 工作流说明——也就是说，上一篇的 Skill 与 MCP 正在融合（见第 8 章）。

5. 原理：模型是怎么"用上"MCP 的

5.1 完整链路

启动      Host 读配置 → 为每个 server 建立 Client → server/discover
发现      tools/list（及 resources / prompts）→ 汇总成统一的"工具注册表"
呈现给模型  把每个工具的 name + description + inputSchema 放进模型 API 的 tools 参数
模型决策   模型输出"调用 weather_current(...)"（普通的 Function Calling）
路由执行   Host 找到该工具属于哪个 Client → tools/call → Server 真正执行
回灌      结果（content）作为工具结果放回对话 → 模型继续

关键认识：模型对 MCP 一无所知。它面对的永远是"一组带 JSON Schema 的工具"。MCP 是 Host 与外部系统之间的管道标准。这也解释了为什么同一个 MCP 服务器能被不同厂商的不同模型使用。

5.2 description 又是路由规则

和 Skill 一样，模型选哪个工具、怎么填参数，完全靠工具的 description 与 inputSchema 理解。所以：

  • 工具名称要清晰（官方示例建议 calculator_arithmetic 而不是 calculate）；
  • 描述要写"做什么、什么时候用"；
  • Schema 里每个参数的 description 也是给模型看的提示词。

5.3 代价：工具定义吃上下文

这是 MCP 实践中最现实的问题：所有已连接服务器的所有工具定义，默认全量放进上下文。

  • 一个服务器十几二十个工具，每个带完整 Schema，很容易占掉几千上万 token；
  • 连几个服务器，工具上百个，既费 token，又会降低模型选对工具的准确率；
  • 中间结果（比如先读一个大文档、再把内容塞进另一个工具）还会反复穿过模型的上下文。

业界的应对方式（这一段是行业做法的归纳，细节各家不同）：

  1. 按需加载工具定义：初始只给工具名，需要时再取完整 Schema。官方客户端最佳实践里也有"progressive tool discovery（渐进式工具发现）"；本会话里看到的 "ToolSearch" 就是这种做法。
  2. 让模型写代码来编排工具：不是一个一个调用工具，而是让模型生成一段程序，在沙箱里批量调用并只返回最终结果——中间数据不进上下文。我另一篇笔记讲的 DeepSeek Harness 的 PTC 模式就是这个思路：[[AI Agent/DeepSeek Harness：PTC 模式是如何用 TypeScript 编排工具调用的|DeepSeek Harness：PTC 模式与 TypeScript 工具编排]]。
  3. 缓存：服务器按确定顺序返回工具列表（规范建议），有利于客户端缓存和模型的 prompt cache 命中。

这是个有意思的对照：Skill 的核心设计就是"渐进式披露"来省上下文，而 MCP 的原生设计是"全量暴露"，所以两边都在互相借鉴对方的优点——MCP 加上渐进式工具发现，Skill 加上 MCP 的远程分发。

6. 授权：远程服务器怎么安全地"认人"

stdio 本地服务器通常直接从环境变量里取凭证，规范说它不应走下面这套流程。远程（HTTP）服务器才用 OAuth 授权，规范里授权是可选的，但一旦支持，应遵循规范。

6.1 角色

  • MCP 服务器 = OAuth 2.1 资源服务器（接受并校验访问令牌）；
  • MCP 客户端 = OAuth 2.1 客户端（代表用户去请求受保护资源）；
  • 授权服务器：与用户交互、签发令牌，可以和 MCP 服务器是同一个，也可以是独立的。

6.2 流程（简化）

1. 客户端不带令牌访问 MCP 服务器 → 401 + WWW-Authenticate（指向元数据地址）
2. 客户端读取"受保护资源元数据"（RFC 9728）→ 得知授权服务器在哪
3. 客户端读取授权服务器元数据（RFC 8414 / OIDC Discovery）
4. 客户端取得 client_id：Client ID Metadata Documents（推荐）/ 预注册 / 动态注册（已弃用）
5. 生成 PKCE 参数，带上 resource 参数（RFC 8707），打开浏览器让用户授权
6. 回调拿到授权码 → 校验 iss（RFC 9207）→ 换取访问令牌
7. 之后每个请求都带 Authorization: Bearer <token>

6.3 几条硬规则（规范原文要求）

  • 令牌必须放在 Authorization 头，不得放进 URL 查询串；
  • 令牌必须是签发给这个服务器本身的（resource / audience 绑定），服务器不得接受或转发其他令牌——防止"令牌透传"和混淆代理攻击；
  • 客户端发请求必须带 resource 参数标明目标服务器；
  • 权限不够时返回 403 + insufficient_scope，客户端可走逐步升级授权（step-up）；
  • 遵循最小权限原则：只申请当前操作需要的 scope。

7. 和相邻概念的区别

它是什么 与 MCP 的关系
Function Calling / Tool Use 模型 API 层：怎么表达和接收工具调用 下层。MCP 工具最终都被转成这种形式交给模型
ChatGPT 插件（2023） 单厂商的插件机制 MCP 是跨厂商开放协议，且不绑定某个产品
直接调 REST API 应用自己对接每个服务 MCP 把"发现 + 描述 + 调用"标准化，AI 应用不必为每个服务写适配
LSP 编辑器 ↔︎ 语言服务器 MCP 的灵感来源，思路相同、领域不同
Skill（Agent Skill） 教模型"怎么做"的手册，按需读取，可带脚本 互补：MCP 给手，Skill 给手册。见第 8 章
Subagent 隔离上下文的子执行者 正交。子代理内部也可以用 MCP 工具
A2A（Agent2Agent）等 Agent 之间互相通信的协议 层次不同：MCP 是 Agent↔︎工具/数据；A2A 是 Agent↔︎Agent（本文未逐项查证 A2A 的细节）

8. MCP 与 Skill：到底怎么选

我上一篇讲 Skill 时给过一个对照：[[AI Agent/Agent Skill 完全指南：它是什么、怎么来的、为什么管用|Agent Skill 完全指南]]。把两者放一起：

MCP Skill
给模型什么 能力（能调用什么外部功能/数据） 知识（遇到这类任务该怎么做）
本质 运行中的程序/服务 + 协议 磁盘上的文件夹（Markdown + 可选脚本）
上下文成本 工具定义默认全量常驻（可优化为按需） 简介常驻，正文按需加载
需要部署吗 要（起进程或有远程服务） 不要，拷文件即可
能访问外部系统吗 能，这正是它的目的，并带授权机制 自身不能；只能让模型用已有工具做
适合 连接 Figma、GitHub、数据库、内部系统 公司流程、写作规范、操作手册、"用 X 工具时的最佳实践"

典型的组合方式：MCP 提供"能操作 Figma 的工具"；Skill 写明"在我们公司，把设计转成代码时先查设计系统 token、命名遵循 …、完成后跑 …"。工具负责"能不能做"，手册负责"做得对不对"。

怎么选：

  • 要访问外部系统/数据 → MCP（或一个脚本，若只有你自己用）；
  • 要固化流程/规范/经验 → Skill；
  • 只是几条"永远成立"的规矩 → AGENTS.md / CLAUDE.md；
  • 必须 100% 发生的动作 → Hook / 脚本，不要指望模型自觉。

趋势上两者在融合：MCP 规范里已经列出 Skills over MCP 扩展，设想通过 MCP 来发现和分发 Skill；Skill 里也可以写"怎么用某个 MCP 服务器"。

9. 动手：怎么用、怎么写

命令与 SDK 接口细节变化较快，下面是常见形态，以官方文档为准。

9.1 在 Claude Code 里接一个 MCP 服务器

# 远程服务器（Streamable HTTP）
claude mcp add --transport http <名字> <URL>

# 本地服务器（stdio：Host 把它当子进程启动）
claude mcp add <名字> -- npx -y <某个-mcp-server-包>

claude mcp list      # 查看已配置的服务器

项目级配置通常放在仓库根目录的 .mcp.json，形如：

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/allowed/dir"]
    }
  }
}

接入之后，工具会以 mcp__<服务器名>__<工具名> 出现。需要登录的远程服务器会走第 6 章的 OAuth 流程。

9.2 自己写一个最小服务器（Python SDK 的常见写法）

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("demo")

@mcp.tool()
def add(a: int, b: int) -> int:
    """把两个整数相加。当用户要求做加法时使用。"""
    return a + b

if __name__ == "__main__":
    mcp.run()   # 默认 stdio

SDK 会根据函数签名自动生成 inputSchema，用函数的 docstring 作为 description——所以 docstring 就是写给模型看的提示词。官方提供 Python、TypeScript 等多语言 SDK，以及调试工具 MCP Inspector，可以不接任何 AI 应用就直接测试你的服务器。

9.3 设计工具时的几点经验（归纳）

  1. 工具要少而精：每个工具的定义都吃上下文；不要把 REST API 的几十个接口一股脑包成几十个工具。
  2. 按"任务"而不是按"接口"设计：一个工具完成一件有意义的事，比让模型串联五次调用更可靠。
  3. 名称与描述写清楚，参数给 description 和 enum。
  4. 返回精简的结果：别把几万字原始数据直接返回，先在服务端过滤、摘要。
  5. 有副作用的操作要可确认：可以用 Elicitation 让用户确认；Host 一般也会在调用前请求授权。
  6. 工具列表保持确定的顺序，利于缓存。

10. 局限与安全风险

规范开篇就说得很直白：MCP 通过任意数据访问和代码执行路径提供能力，因此带来重要的安全与信任问题，而且 "协议本身无法在协议层强制执行这些安全原则"，需要实现者自己做好。

10.1 规范强调的原则

  1. 用户同意与控制：用户必须明确同意并理解所有数据访问与操作。
  2. 数据隐私：Host 在把用户数据暴露给服务器前必须获得明确同意，不得擅自转发。
  3. 工具安全：工具等同于任意代码执行；工具行为的描述（包括注解）应被视为不可信，除非来自可信服务器；调用任何工具前必须获得用户明确同意。

10.2 具体的攻击面（归纳，非规范原文）

风险 说明
提示注入（间接） 工具返回的内容（网页、邮件、工单）里夹带指令，诱导模型执行别的操作。工具结果是数据，不是指令。
工具投毒 恶意服务器在工具 description 里写入隐藏指令，模型读到就照做
"地毯式更换"（rug pull） 服务器先以无害工具获得批准，之后通过变更通知悄悄改掉工具定义
本地服务器 = 以你的权限跑任意程序 stdio 服务器是你机器上的进程，npx 某个包 等同于执行该包
混淆代理 / 令牌透传 服务器拿着不是发给自己的令牌去访问别的服务——规范明确禁止接受或转发其他令牌
过度授权 一个令牌给了太宽的 scope；规范要求最小权限与逐步升级
上下文膨胀 工具太多既费钱，又降低选对工具的概率（见 5.3）
跨服务器组合 多个服务器同时连着时，一个服务器的内容可能影响模型对另一个服务器工具的使用（数据外泄路径）

10.3 实践建议

  • 只装来源可信的服务器；第三方 stdio 服务器像安装软件一样审查；
  • 读写分离、最小权限：只给需要的 scope，能只读就只读；
  • 危险操作保持人工确认，别全局"自动批准"；
  • 把工具结果当不可信输入；
  • 对远程服务器检查它的授权方式与数据留存政策；
  • 保持工具集精简，不用的服务器及时断开。

11. 回到这个博客

  • 我的 AGENTS.md 里"密钥绝不进仓库或前端"这条规矩，对 MCP 同样适用：MCP 服务器的令牌和 API Key 应该放在环境变量或密钥管理里，不要写进 .mcp.json 提交到仓库（项目级配置会随源码一起推送）。
  • 看板喵目前是自己的 Cloudflare Worker 接口，没必要为了"用 MCP"而改造。一个可选的想法：如果以后想让别的 Agent 直接检索我的笔记（比如"按标签列文章""读某篇全文"），可以把这些能力包成一个远程 MCP 服务器——但要先想清楚认证与限流，否则等于把内容接口公开。
  • 做判断时可以直接套第 8 章的选择表：要连系统用 MCP，要固化流程用 Skill，要永远成立的规矩放 AGENTS.md，要必须发生的动作写脚本。

12. 术语表

术语 含义
MCP Model Context Protocol，连接 AI 应用与外部系统的开放协议
Host / Client / Server 宿主应用 / 宿主内每个连接的连接器 / 提供上下文的程序
JSON-RPC 2.0 MCP 的消息格式（请求、响应、无需响应的通知）
stdio / Streamable HTTP 两种传输：本地子进程标准输入输出 / 远程 HTTP + 可选 SSE 流
Tools / Resources / Prompts 服务器的三大原语：可执行函数 / 上下文数据 / 提示模板
inputSchema 工具参数的 JSON Schema，既是校验规则也是给模型看的说明
Elicitation 服务器中途向用户追问或请求确认
Sampling / Roots / Logging 已在 2026-07-28 弃用的客户端特性
server/discover 服务器声明版本、能力与身份的必备请求
_meta 每个请求携带协议版本、客户端能力等元数据的字段
Tasks / MCP Apps / Skills over MCP 官方扩展：长任务 / 对话内交互界面 / 通过 MCP 分发技能
OAuth 2.1 / PRM / PKCE 授权框架 / 受保护资源元数据（RFC 9728）/ 防授权码截获
AAIF Agentic AI Foundation，Linux Foundation 旗下，2025-12 起托管 MCP
MCP Inspector 官方调试工具，直接连服务器测试

附：参考来源

  • 官方介绍：What is MCP?
  • 官方架构文档：Architecture overview
  • 规范（最新）：Specification，其中 2026-07-28 Key Changes 与 Authorization
  • 第三方版本与采用时间线（仅作参考）：hidekazu-konishi：MCP Specification Version Timeline、Wikipedia：Model Context Protocol

关于可信度的说明：第 4 章（协议结构、2026-07-28 变更）、第 6 章（授权）和第 10.1 节直接依据官方文档；第 3 章的早期发布日期、厂商采用与基金会捐赠来自第三方汇总，各来源之间日期略有出入；第 5.3、第 7、第 9、10.2 节含我的归纳与经验判断，已尽量标明；A2A 与 Claude Code 命令行细节未逐项对照官方页面核实。