MCP：模型上下文协议

一句话定义

MCP（Model Context Protocol）是 Anthropic 于 2024 年 11 月开源的标准协议，统一了"AI 应用如何发现并调用外部工具、资源与提示"的接口——被业界称为"AI 应用的 USB-C"：一次接入，任何支持 MCP 的客户端都能用。

为什么重要

协议出现之前的集成世界是 M×N 地狱：M 个 AI 应用 × N 个数据源（Slack、GitHub、数据库…）各自写适配器。MCP 把它变成 M+N：数据源写一次 MCP Server，所有 MCP Client（Claude Desktop/Code、Cursor、Zed、各类 Agent 框架……）即插即用。对开发者的现实意义：你写的每个内部系统 MCP 化一次，全公司的 AI 工具都能安全地用它——工具生态从"每家自留地"变成公共基础设施。2025 年 OpenAI、Google 相继宣布兼容，事实上成为行业标准。

前置知识

kp-009（函数调用）、kp-010（工具设计）。

核心概念

三方角色

┌────────────┐   MCP    ┌────────────┐   API    ┌──────────┐
│ MCP Host    │◄────────►│ MCP Server │◄────────►│ 数据源    │
│ (Claude/Cursor│        │ (你写的封装) │          │ (GitHub…) │
│  = Client)  │          └────────────┘          └──────────┘
└────────────┘

Host / Client：运行业务逻辑、发起 MCP 连接的一方（宿主应用，可同时连多个 server）
Server：暴露能力的轻量程序，把数据源翻译成 MCP 语义
传输：本地走 stdio（子进程），远程走 HTTP（Streamable HTTP），消息格式基于 JSON-RPC 2.0

Server 能暴露的三类原语

原语	方向	作用	例子
Tools	模型可调用（要经用户同意）	改变世界 / 查询	`create_issue`、`query_orders`
Resources	应用按需读取（不主动给模型）	提供上下文数据	`file://report.pdf`、`db://schema`
Prompts	用户主动调用的模板	封装工作流	"/summarize-pr"

关键区分：Tools 面向模型自主决策（有安全含义）；Resources 面向应用装配上下文（更可控）。设计时问一句"这该由模型决定用，还是应用决定给"。

与裸函数调用的关系

MCP 不替代 kp-009 的协议，而是其上的发现与传输标准：server 通过 tools/list 声明清单（名称/描述/schema 与函数调用同构），client 把它们注入模型的 tools；模型发起调用后，client 经 MCP 转发给 server 执行。多出来的能力是动态发现、标准化生命周期与鉴权——包括 2025 年加入的授权规范（OAuth）。

原理与机制

一次会话的生命周期：

initialize：握手，协商版本与能力（client 与 server 互报"我支持什么"）
发现：client 调 tools/list / resources/list 拿到清单
注入：client 把工具清单放入模型上下文（注意：全部注入会吃窗口——见下方误区）
调用：模型发出 tool_use → client 经 tools/call 转发 → server 执行返回内容（文本/图片/资源引用）
回填：结果进入对话，循环继续（kp-006）

进阶机制：sampling（server 反向请求 client 的模型做补全，用于实现 server 侧的智能逻辑而不自带 API key）；roots（client 告知 server 其可操作的资源边界）；notifications（进度与日志流）。

直观类比

USB-C 的类比足够精确：过去每台设备一种充电口（每应用一套集成），现在统一接口——但插上就能用 ≠ 插上就该用：每插一个 server，模型多看到一批工具（占用"桌面"，kp-003），用户多授一份权限（安全面扩大，kp-026）。协议解决"通"，不解决"该不该通"。

实例与案例

一个 30 行的 MCP Server（Python SDK，官方风格简化）：

pythonfrom mcp.server.fastmcp import FastMCP
mcp = FastMCP("orders")

@mcp.tool()
def query_order(order_id: str) -> str:
    """查询订单状态。order_id 形如 ORD-12345。
    返回状态与最近一次物流事件。"""
    o = db.orders.get(order_id)
    if not o:
        return f"错误：订单 {order_id} 不存在。请核对格式 ORD-数字。"
    return f"状态：{o.status}；最新物流：{o.last_event}"

mcp.run()   # stdio 模式，宿主以子进程拉起

注意它就是 kp-010 的工具设计守则 + MCP 的薄封装：工具质量守则不因协议而变。

常见误区

误区一："MCP 让工具更强了"。MCP 只是标准化接入；调用正确率仍取决于描述与 schema 质量（kp-010）。
误区二：把 50 个工具的 server 全量挂上。工具注入挤占上下文并稀释选择注意力（kp-003/009）；好的 server 按"任务域"切分，client 支持按需启用。
误区三："Resources 和 Tools 差不多，随便用"。Tools 给模型自主权（高风险需审批），Resources 由应用控制注入（低风险）——安全设计的第一道选择（kp-026）。
误区四：远程 MCP server 不做鉴权。远程暴露 = 公网 API，OAuth/网关/最小权限一个不能少。

自测题

MCP 把哪种复杂度从 M×N 降到 M+N？
Tools 与 Resources 的本质区别是什么？
为什么"挂载的 server 越多越强"不成立？

（参考答案：1. 应用与数据源之间的集成适配；2. 谁发起与谁负责——tools 由模型决定调用（需同意、有副作用），resources 由应用装配（可控、只读为主）；3. 上下文占用与工具选择注意力稀释，且权限面扩大。）

与其他知识点的关系

底层协议 → kp-009；工具质量 → kp-010；安全 → kp-026
框架对 MCP 的支持 → kp-021；Agent 间协议（A2A）→ kp-032