MCP 是什么：AI 应用怎样连接资源与工具

先看结果：MCP 减少了连接适配，却没有替你完成业务设计和安全判断

独立项目顾问沈棠每次启动新客户项目，都要从批准资料中找客户背景和交付边界，从项目台账读取负责人、里程碑与风险，再按固定模板生成启动包。原来她分别维护桌面 AI 脚本、命令行脚本和一个编辑器插件；同一个“查客户资料”动作有 3 种输入格式、2 种错误语义和 3 份权限配置。任一数据源改字段，都可能让某个入口悄悄失效。

她没有把 MCP 理解成“让 AI 拥有所有工具”的总开关，而是搭了两台范围很窄的服务器。“客户保险库”在本机通过标准输入输出运行，只能访问批准目录，提供 3 类资源、1 个提示模板和 2 个只读工具；“项目账本”通过受保护的可流式 HTTP 提供 2 个精确查询工具。AI 桌面应用是主机，它为两台服务器各创建一个客户端连接，决定哪些资源进入模型上下文、什么时候允许调用工具、怎样把结果展示给人。

MCP 解决的核心问题是：AI 应用与外部能力之间有一套共同的发现、描述、调用和生命周期协议。它没有规定模型一定怎样使用这些能力，也不会自动把危险服务器变安全、把模糊工具变可靠、把错误结果变正确。本文是虚构教学案例；具体主机支持、开发工具包成熟度、协议版本、认证和部署方式都会变化，应以实际产品与官方当前文档为准。

先认清原问题：不是 AI 不会调用函数，而是每一对应用与数据源都在重复发明接口

没有 MCP 时，AI 应用当然也能调用 REST 接口、本地函数、数据库驱动或命令行。真正的摩擦在于，每个主机都要重新理解认证、能力列表、输入结构、输出内容、错误、进度和连接生命周期；每个工具提供者又要分别适配多个 AI 应用。标准化协议的价值在兼容边界，而不是凭空创造原先做不到的能力。

沈棠先画出现状，不急着安装服务器。桌面 AI 读取 JSON 清单，命令行脚本接收参数，编辑器插件使用自己的工具结构；三者都在访问同一批准目录。台账端又有 HTTP 接口和本地导出两条路径。表面只有两个业务数据源，实际却形成 7 份映射、5 处错误转换和 3 套凭证处理。

如果只有一个固定主机、一个稳定接口和一次性脚本，直接调用可能更简单。只有当兼容、复用、能力发现或主机切换真的构成成本时，MCP 才可能减少重复工作。

还要区分 MCP 与常说的函数调用。函数调用通常描述模型怎样输出结构化调用意图，以及主机怎样把工具结构交给模型；MCP 描述主机内部的客户端怎样与外部服务器协商、发现并交换这些能力。主机可以把 MCP 工具转换成模型可见的功能，也可以完全不让模型自主选择，而由固定工作流调用。两者经常一起出现，却不在同一个层级。

因此，“主机已经支持函数调用”不说明它支持 MCP，“服务器能列出工具”也不说明当前模型必须看到全部工具。把两层拆开后，沈棠可以在 MCP 连接不变的情况下更换模型，也可以在模型不变时替换符合相同合同的服务器。

一张图放对角色：主机不是模型，客户端不是用户，服务器也不一定在远端

沈棠
  ↓ 选择资料、批准调用、验收结果
AI 桌面应用（MCP 主机，内部包含模型与编排）
  ├─ MCP 客户端 A ⇄ 标准输入输出 ⇄ 客户保险库服务器 ⇄ 批准目录
  └─ MCP 客户端 B ⇄ 可流式 HTTP ⇄ 项目账本服务器 ⇄ 项目台账接口

主机是用户正在使用的 AI 应用，负责协调模型、用户界面、上下文、权限与多个连接。客户端是主机内部的协议组件；官方架构说明，一个主机可创建多个客户端，每个客户端与一个特定服务器保持专用连接。服务器是提供上下文或能力的程序，既可能是主机启动的本地进程，也可能是网络上的远端服务。

说“我把模型连到 MCP”会掩盖关键责任：通常是主机实现 MCP 客户端，并决定哪些结果进入模型；服务器不会自动看到整个对话或其他服务器的数据。跨服务器组合由主机控制，这正是之后做权限和审计时要抓住的边界。

一台主机连接两台服务器时，会建立两个客户端会话而不是共享一条万能通道

客户端 A 只知道保险库服务器的连接与能力，客户端 B 只知道账本服务器。协议架构强调每个客户端与某个服务器保持一对一会话；这让版本、能力、订阅、错误和连接状态可以分别管理。保险库崩溃不应让账本客户端假装成功，账本撤权也不该把保险库的本地资源一并暴露。

隔离并不意味着服务器之间永远不会间接影响。主机可能把保险库读出的客户编号作为账本工具输入，也可能把两个结果放进同一个模型上下文；因此跨服务器数据流仍由主机的编排和策略审查。服务器 A 不能自行要求主机把服务器 B 的完整结果发送给它，除非主机明确支持，并允许相应客户端共享能力与上下文。

“多服务器可组合”是主机可编排多个独立来源，不是把它们放进一个互相信任的内网。对于个体用户，至少要能逐服务器查看来源、开发者、启动命令、网络访问、资源范围、工具和凭证。

MCP 有数据层和传输层：一边规定说什么，另一边规定怎样送达

数据层基于 JSON-RPC 2.0，定义请求、回复、通知、生命周期以及资源、工具、提示等原语。传输层处理连接建立、消息封装和相应授权方式。相同的工具列表语义可以通过本地标准输入输出，也可以通过远端可流式 HTTP 传输，但进程权限、网络暴露、认证与运维风险完全不同。

MCP 不是网络协议、认证协议和智能体框架的混合别名。它借助现有传输和授权标准定义互操作规则；模型选择、任务规划、业务数据库结构、主机用户体验、沙盒与最终质量评价，仍在协议之外，或由具体实现决定。

初始化不是寒暄：先协商协议版本、双方身份和能力，再开始工作

连接建立后，客户端发送初始化请求，其中包含它支持的最新协议版本、客户端能力和客户端信息；服务器返回它选择的版本、服务器能力与服务器信息。客户端若不支持服务器返回的版本，就应断开。协商成功后再发送“已初始化”通知，表示正常操作可以开始。

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": { "roots": { "listChanged": true } },
    "clientInfo": { "name": "shentang-workbench", "version": "1.4.0" }
  }
}

本案例在 2026-07-21 以官方已发布的 2025-11-25 修订版作为稳定基线，没有把未来草稿能力写进生产合同。协议版本采用日期字符串，开发工具包版本则是另一套编号；主机支持某个开发工具包，不等于已经支持规范中的全部功能。沈棠把主机版本、开发工具包版本、协商后的协议版本和服务器版本四项同时记入追踪。

因此，看到服务器“已连接”还不够，必须检查最终协商出的版本和能力。很多所谓 MCP 故障其实发生在生命周期：主机没有支持服务器需要的功能，服务器升级后输入结构变了，或重连后仍沿用旧目录。

能力协商说明“会不会说这种协议消息”，不说明“准不准读这位客户”

服务器声明工具能力，表示它支持相关工具方法；声明资源，表示可响应资源发现/读取。客户端声明根目录、抽样或需求引出，表示服务器可以在符合规范和主机政策时请求这些客户端能力。能力是协议功能开关，不是业务授权、文件访问控制列表或用户同意。

账本服务器声明工具，并不代表沈棠已经获得 A-17 项目的权限；OAuth 令牌、台账的角色访问控制和工具内部账户保护仍需分别通过。保险库服务器看得到根目录能力，也不意味着它应该收到整个个人目录。把能力与权限混在一起，会产生“协商成功，所以允许”的危险推理。

每次目录变化都应重新做能力差异和权限检查。主机可以技术上支持某功能，却按用户设置禁用；服务器可以声明功能，但当前身份下返回的具体对象更少。两层结果都要记录。

资源、工具和提示是三类不同能力

资源是可寻址的上下文，不是“服务器能碰到的所有文件”

资源用统一资源标识符指向一份可读取的上下文，例如客户档案、批准文件索引或启动检查清单。主机通常控制什么时候把资源放进上下文；服务器可以提供已知资源列表或资源模板。一个资源应有清楚的名称、描述、媒体类型、可选大小和稳定地址，让主机能够预览与估算，而不是把整个目录当成无边界的文本桶。

资源列表只回答服务器愿意列举的已知资源；资源模板可以表达带参数的地址，但参数仍需验证。资源读取成功也不等于内容可信，客户文件可能过期、带提示注入或与当前项目无关。主机仍需标记来源、限制大小、处理媒体类型、去重，并决定是否送入模型。

沈棠没有暴露任意本地文件路径。她把真实目录映射成业务资源地址，服务器内部验证客户、文档标识符、批准状态和哈希值。这样，主机不会把本机路径当成业务主键，目录移动也不改变外部合同。

原语选错会让控制含糊。把完整客户档案做成无参数工具，主机可能把一次普通取上下文误呈现为模型行动；把实时台账查询做成静态资源，缓存和新鲜度又难表达；把权限规则放进提示词，则模型可能遵守也可能不遵守。选择标准不是哪种更“高级”，而是谁控制使用、是否执行计算、结果是否应寻址和缓存、是否需要用户主动选择。

工具是可执行函数：名称、参数结构和结果只是合同，副作用仍由实现决定

工具向主机描述名称、标题与说明、输入结构，以及可选的输出结构；模型或主机可以提出工具调用，服务器执行后返回内容、结构化结果或错误标记。结构约束能减少参数歧义，却不能证明函数没有副作用。叫“搜索”的工具也可能把数据写到外部，叫“草稿”的工具也可能真的发送，必须审查实现与下游接口。

工具描述要写明什么时候用、什么时候不用、缺失或冲突怎样返回，不能只写“智能查询”四个字。输入结构限制类型、枚举、长度和必需字段；服务器再做语义验证、身份与资源检查、速率限制和审计。输出结构固定关键字段，文本内容给人阅读，结构化结果供主机可靠处理。

案例明确不提供创建项目、更新状态、发送邮件或写入文件。MCP 让写入工具更容易被发现和调用，但是否暴露、是否批准、是否二次确认，全部是设计决定，不是协议默认替你禁止。

提示是可复用交互模板，不是凌驾于主机和用户之上的系统指令

服务器可以列出提示模板及其参数，主机或用户按需取得消息模板。本案例中的“准备启动包”需要项目编号、会议日期与受众，返回结构说明、检查顺序和两个短样例。它把团队已有方法做成可发现资产，但主机仍决定是否呈现、用户是否选择，以及返回消息怎样进入当前对话。

提示词不是必要能力：同样的工具可由主机自己的提示与工作流调用。若模板只服务一个主机且不需跨应用复用，留在主机配置可能更清楚；若它与服务器的数据模型、资源统一资源标识符和工具使用法紧密绑定，并希望多个兼容主机发现，才有放进服务器的价值。

来自服务器的指令、描述和提示都应视为外部输入。主机不能因为它们属于 MCP 字段，就给予高于本地策略的权力；安装不可信服务器时，恶意描述同样可能诱导模型调用危险工具或外传其他上下文。

根目录、抽样和需求引出由客户端侧提供，它们改变了服务器能向主机请求什么

MCP 不只让客户端向服务器取东西。支持根目录的客户端可以向服务器提供文件系统边界；支持抽样时，服务器可以请求主机调用模型；需求引出则让服务器请求结构化用户输入，或通过网页地址模板启动外部交互。2025-11-25 修订版还包含实验性的任务能力，用于持久请求、轮询和延迟结果，但必须先协商具体能力，不能看见字段就默认可用。

这些能力会反转调用方向，所以“服务器只是被动工具”也不总正确。主机必须对服务器发来的抽样或补充信息请求重新应用策略和用户控制，不能把一次连接同意扩张成无限模型预算、任意表单或跨服务器上下文共享。

沈棠禁用抽样，因为启动包不需要服务器内部再跑智能体；缺会议日期时由主机自己的表单补齐。减少能力比为用不到的能力增加复杂审批更可靠。

本地标准输入输出只省掉网络传输，不等于服务器被沙箱、代码可信或资料不会外发

标准输入输出通常由主机启动本地服务器进程，并通过进程输入输出交换 MCP 消息。它适合单机、单客户端连接，避免开放网络端口；但进程能访问哪些文件、环境变量、网络和系统权限，仍取决于启动环境。一个恶意或有漏洞的本地服务器，可能读取进程可访问的资料并主动联网，标准输入输出不会自动阻止。

官方安全指导建议提醒用户本地服务器以客户端相同权限运行，并使用最小默认权限与沙盒限制文件、网络和系统资源。对普通用户来说，“复制一段启动配置”实际是在授权运行代码；应像安装软件一样审查，而不是像添加书签一样轻率。

本案例把批准资料复制到只读快照，而不是直接给服务器整个客户盘。即使服务器解析器被恶意文件利用，影响面也比主页目录小；发现问题时可停进程、删除快照并从批准源重建。

远端可流式 HTTP 带来共享服务与独立认证，也带来网络和租户边界。 它使用 HTTP 请求承载客户端到服务器的消息，并可通过服务器事件支持反向流式通信。远端服务器可以集中维护、服务多个客户端，但必须处理传输安全、授权、会话、来源、重连、限流、租户隔离、日志和上游接口。不要把“一个地址即可连接”误写成零运维。

沈棠的两个账本工具都是只读或纯计算，所以重连风险较低；将来若增加写入，仍要业务幂等、审批和对账，不能只依赖 JSON-RPC 请求编号。远端服务器的隐私与保留也需检查：工具输入、结果、令牌元数据和追踪分别保存多久、由谁访问。

MCP 授权保护客户端到服务器，服务器访问下游是另一条信任关系

2025-11-25 授权规范为 HTTP 传输定义了可选授权框架：受保护的 MCP 服务器充当 OAuth 资源服务器，MCP 客户端充当 OAuth 客户端。规范要求令牌绑定预期资源并由服务器验证，也禁止把客户端交给 MCP 服务器的令牌原样透传给下游。服务器若调用项目台账接口，应使用另一份由台账授权方签发、专门面向台账的凭证。

沈棠 → 授权服务器 → 给 MCP 客户端签发“只用于项目账本 MCP”的令牌
MCP 客户端 → 项目账本 MCP 服务器（验证受众、主体与范围）
项目账本 MCP 服务器 → 台账接口（使用独立下游凭证，并再次检查项目权限）

标准输入输出不使用这套 HTTP 授权流程；规范建议从环境取得凭证，但环境变量本身仍需最小化和安全存储。OAuth 也不是服务器可信证明：一个合法获得令牌的服务器，仍可能提供过宽工具、存在错误实现或不当保留数据。

从任务合同反推服务器边界：先列业务事实，再决定资源、工具或留在主机

沈棠把启动包限定为 6 个部分：客户背景、批准范围、项目负责人、4 个里程碑、已知风险和缺失。每条事实都带来源位置；没有精确项目编号就停止，不按名称猜。主机生成本地草稿，人确认后自行发送。这个合同先于 MCP 设计，避免“服务器有什么就塞进上下文”。

若资料只有三份静态文件，直接拖入主机可能优于建立服务器；若台账已有主机原生的只读连接器，也无需为了技术新鲜感替换。MCP 只是候选接口形态，任务合同、数据边界与验收成本决定它是否值得。

设计服务器清单和参数结构时，要让人、主机和模型看到同一个真实合同

两台服务器各自记录负责人、版本、来源、传输、下游、数据分类、留存、资源、工具、客户端功能、所需范围和事件联系人。这不是 MCP 协议自动生成的万能清单，而是沈棠用于安装评审和变更控制的项目产物。每个声明都能链接到测试或配置证据。

工具名称保持稳定并带命名空间，描述写清边界，输入结构把客户编号、项目编号与自由文本分开。错误至少区分无效输入、未授权、资源被拒绝、未找到、冲突、速率限制、下游不可用和内部错误；模型可修正的业务错误放在工具结果中并标为错误，只有协议本身损坏才算协议错误。

新增工具时不是只更新描述。需要提升服务器版本、发列表已变更（若双方支持）、生成能力差异、补允许/拒绝测试并在主机重新批准。若主机不能可靠显示新增能力，就固定版本并手工复核后更新。

安装评审还要保存“最终生效状态”，不能只留服务器宣传页。沈棠导出主机实际看到的 3 类资源、1 个提示模板和 4 个工具，记录两条启动或端点配置、协商版本、进程权限、网络目的地、凭证编号与批准人。宣传页写“只读”，运行清单却出现写入类工具时，应以运行证据为准并停止安装。

卸载也有完成标准：主机删除连接与缓存目录，本地进程不能再启动，远端授予被撤销，刷新令牌失效，下游服务器凭证按需要轮换，保留的数据依规则删除，最后用旧配置做一次失败探测。只在主机界面关掉开关，不等于远端授权和已经同步的数据一并消失。

完整走一次调用：从初始化、发现到 4 个工具调用，不能只演示最后答案

执行 K-020 从项目编号 P-204、客户编号 A-17 开始。主机分别初始化两条会话；从保险库列出资源和提示模板，从账本列出工具；用户选择“准备启动包”；主机读取客户档案、已批准索引与检查清单；模型提出 2 次搜索或读取，以及 2 次账本调用；主机按策略允许后执行，最后合并证据并生成草稿。

本次共有 14 个 JSON-RPC 请求，回复和通知不混进请求数。生成的 8 条声明中，7 条直接带来源位置；第 8 条日期是计算器根据容量推导的结果，明确标注为假设，不伪装成台账事实。一个文件版本与索引哈希值不符，服务器返回冲突；主机没有换路径寻找旧文件，而是把它列入缺失。

这条追踪能定位问题所在的层级：工具列表缺能力属于发现；输入被拒属于结构或策略；下游 503 属于服务器执行；工具成功却选错资料属于编排；资料正确却写错结论属于模型或内容质量。只看最终简报，会把所有失败都笼统地叫成“MCP 不好用”。

40 项协议与边界测试要覆盖成功、拒绝、断线和变化，而不只跑成功路径

测试分三层：纯协议样本验证消息与输入结构；沙盒验证实际服务器、进程和 HTTP 行为；去标识业务样本验证资源与工具结果的业务含义。若只模拟服务器，很难发现标准输出日志破坏消息封装、凭证被继承、HTTP 会话混淆或下游字段扩张。

每个案例记录先决条件、双方版本与能力、消息、预期下游调用次数、预期错误层和审计事件。跨项目拒绝不仅看界面报错，还要验证账本接口调用数为 0；令牌透传测试确认下游看不到 MCP 受众令牌；服务器崩溃后，主机重新初始化，而不是复用旧能力缓存。

20 次历史重放把协议正确与内容正确分开：280 次请求全通，不代表 160 条事实全对

她选择 6 个客户的 20 份去标识历史启动会任务，每份按固定的 14 请求轨迹重放，共 280 个请求：初始化 40、发现 80、资源与提示检索 60、工具调用 100。协议层 280 项都收到预期回复或已定义的业务错误，没有未解释超时、跨客户返回、机密日志或写入调用。

前 10 份的 5 条问题中，3 条来自提示模板把“目标日期”写成事实，后来改为假设字段；2 条来自同名文件选择，后来改用文档编号与哈希值。后 10 份仍有 1 条把旧风险当成当前风险，于是加入更新时间与冲突规则。修复都发生在提示模板、输入结构或主机编排，没有更换传输，也没有扩大权限。

20 份样本和 0 次安全事件不能证明未来无风险；它们只代表当前测试样本与运行范围内的观察。沈棠继续保留 40 项回归、能力差异、逐次运行的来源审计和人工发送，不用“协议全通”代替业务验收。

用故障定位表决定修哪里：不要遇到问题就换服务器、换模型或重装全部

一次故障可以跨层，例如 HTTP 401 可能源于令牌受众配置，也可能是服务器错误转发了下游令牌。先保存最小追踪：版本、能力、请求编号、工具与资源名称、策略决策、服务器错误类别和下游关联编号；不要把令牌、全文资料或整个对话写进调试包。

运行手册规定：标准输入输出进程连续 2 次退出，就停用保险库并转为人工导入资料；账本遇到 503 只做 2 次有界重试，仍失败则在简报中列为缺失；输入结构或能力发生未登记变化，直接隔离新版本。可恢复不等于无限重试。

最后判断是否要用 MCP：复用与互操作收益必须大于新增信任和运维成本

沈棠最终保留两台服务器，因为她确实在 3 个兼容主机中复用同一套资源地址和工具结构，也愿意维护版本、测试与撤权。她没有接入邮件发送，也没有把普通文件导入强行改造成 MCP。收益来自减少重复适配器、统一追踪与边界，不来自“用了开放协议，所以更智能”。

她也写了退出条件：连续两次服务器更新出现未说明的能力扩张；主机无法让用户看见工具参数与结果；远端服务不能解释数据保留和下游处理；本地服务器要求主页目录或无关机密；兼容性维护超过三套直接适配器的实际成本。标准化是一项可撤销的架构选择，不是越投入越必须坚持的信仰。

本案例依据官方 MCP 架构与学习文档理解主机、客户端、服务器、数据层、传输层和原语；以 2025-11-25 稳定修订版的结构、授权、传输和任务文档核对字段与状态；再用官方安全最佳实践检查本地服务器、范围最小化和令牌边界。协议会继续演进，部署前应锁定明确修订版与开发工具包版本，并重新运行兼容和安全测试。

• MCP官方：Architecture overview
• MCP 2025-11-25：Schema reference
• MCP 2025-11-25：Authorization
• MCP 2025-11-25：Transports
• MCP官方：Security best practices
• MCP 2025-11-25：Tasks（experimental）
• MCP官方：Understanding MCP clients
• MCP官方GitHub：Specification releases

如果今天要评估一个 MCP 服务器，先不要从“怎么安装”开始。写下它服务的一个任务，列清主机、服务器、下游和数据边界；导出资源、工具与提示模板清单，标出写入和客户端能力；再做至少一项正常读取、一项越界拒绝、一项断线恢复和一次彻底撤权。能解释每条消息属于哪一层，才算真正理解了这条连接。