第31期 | AI会用工具之后,MCP到底接通了什么?

上一期讲到，一个TTS模型可以把文字变成声音。

但如果你对AI说：

“读取第30期正文，用已经授权的音色生成旁白，保存到项目目录，再交给视频工程。”

模型即使完全理解这句话，也未必能完成任务。

它可能看不到你的文件，不知道TTS工具怎样调用，也没有向磁盘写入音频的权限。模型负责理解和判断，文件系统、语音服务与视频工程却生活在各自的接口里。

这才是MCP要解决的问题：不是让模型突然变聪明，而是给AI应用与外部能力规定一套共同的沟通方式。

先用一句话说清MCP

MCP全称是模型上下文协议（Model Context Protocol）。这里的“协议”，可以理解成双方事先约定好的沟通规则：能力怎样说明、请求要带哪些参数、结果和错误怎样返回。

它不是模型，不是某个具体工具，也不是给AI增加权限的万能插件。

用开头的任务来说，模型负责判断“要先读正文，再生成旁白”；MCP负责让AI应用能用统一格式询问文件工具和TTS工具：“你能做什么”“这次需要哪些参数”“执行结果是什么”。真正读取文件和合成声音的，仍然是后面的文件系统与TTS程序。

所以，MCP接通的是AI应用与工具入口之间的通信，不是把所有工具塞进模型内部。

为什么需要这套沟通规则？

没有统一连接方式时，每接入一种能力，开发者都要单独处理它的API、参数、认证和返回格式。

读取本地文件是一套写法，调用云端日历是另一套写法，启动本地TTS又可能要运行命令行。假如有5种AI应用、20种工具，双方之间很容易形成大量专用适配。

它有点像统一插座：插座规定接口形状和供电规则，却不负责生产电，也不会把台灯变成空调。

同样，MCP统一的是连接方式，不是工具本身的能力。

MCP接在了哪里？先别急着记英文

先看完整关系：你把任务交给AI应用，AI应用通过内部连接器找到外部能力入口，入口再调用背后的真实程序。

MCP规范给这三个位置起了名字：

• Host：你正在操作的AI应用，例如AI桌面应用或IDE。它承载对话与模型，也负责安全策略、权限提示和用户确认。

• Client：Host内部的MCP连接器。它像联络员，按照MCP格式与某一个Server交换消息。模型可以建议调用什么，但实际请求由应用里的Client发出。

• Server：外部能力的标准入口。文件Server可以公开读取稿件的能力，TTS Server可以公开生成旁白的能力，视频Server可以公开渲染项目的能力。

最关键的关系是：Host里面有Client，Client使用MCP与Server通信，Server后面才是真正的文件系统、API、数据库或程序。MCP就是Client与Server共同遵守的“说话规则”。

这里最容易误解的一点是：MCP Server通常不是重新实现一套文件系统或语音模型。它更像一层适配器，把原本已有的程序、API或数据源包装成AI应用能够发现和调用的标准能力。

一个Host可以通过多个Client连接多个Server；每个Server只需要公开自己负责的那部分能力。

沿图从左往右看：用户面对的是Host，而不是直接面对Server；Client位于Host内部；MCP规范的是Client与Server之间的通信；Server再把请求交给真实工具。至于一次请求怎样实际走完，要继续看下面的执行链路。

一次真实调用，究竟经过了什么？

假设用户要求：“读取正文并生成旁白。”

AI应用需要先知道，已经连接的Server提供了哪些能力。文件Server也许公开了读取文件的资源或工具，TTS Server则公开了类似“生成语音”的工具，并说明需要文本、音色配置和输出位置等参数。

模型根据任务选择能力，但真正发出请求的是Host中的Client。对于会写文件、发送消息或产生费用的动作，可靠的Host还应先把关键参数展示给用户确认。

Server收到结构化请求后，调用背后的真实程序，再返回音频路径、执行结果或错误信息。Host不能只看到“调用成功”四个字就结束，还应检查音频是否真的生成、路径是否正确、文件能否打开。

请严格沿箭头按编号阅读：1→2→3→4→5→6。这是同一个请求从用户提出，到模型选择能力、Host确认参数、Client发送、Server执行，再回到Host核对结果的顺序。MCP主要规范第4步与第5步之间怎样交换消息；整次执行是否成功，仍取决于权限、网络、程序和最终验证。

MCP使用JSON-RPC 2.0组织消息。当前规范支持本地常见的标准输入输出传输，也支持面向远程服务的Streamable HTTP。普通读者不需要记住这些名词，只需要理解：协议让双方更容易说同一种话，但网络超时、凭证失效和程序报错依然存在。

如果你看过较早的MCP教程，可能会见到连接开始时的initialize握手。截至2026年10月，当前2026-07-28版规范已改为无状态请求：协议版本和相关能力信息随每次请求携带。旧版实现仍可能存在，因此实际接入时必须先确认客户端、Server和教程对应的协议版本。

工具、资源和提示，不是三个名字而已

MCP Server主要可以向应用提供三类能力。

资源（Resources）更接近可供读取或引用的数据，例如一份项目文档、一条数据库记录或一段配置内容。它回答的是“这里有什么信息”。

工具（Tools）代表可以执行的操作，例如搜索、创建日程、生成语音、写入文件。它回答的是“这里能做什么”。

提示（Prompts）是Server提供的可复用消息或工作流程模板，帮助用户用较稳定的方式启动某类任务。

它们不能只按名字判断风险。“读取文件”可能读取到隐私资料，“保存草稿”也可能覆盖原文件。能力名称和描述只是说明，真正的权限仍来自操作系统、账号授权、服务端策略和Host的限制。

MCP没有替你解决这四件事

第一，它没有替代原来的API。

日历、数据库和TTS服务仍然需要自己的接口。MCP Server只是把这些接口转换成统一的对外表达。

第二，它没有给模型增加权限。

Server能访问哪个目录、使用哪个账号，取决于它实际拿到了什么权限。协议中写着“只读”，不等于操作系统真的阻止它写入。

第三，它没有保证模型一定选对工具。

模型仍可能选错能力、填错参数，或者把“查空档”误解成“直接创建会议”。这需要明确描述、参数校验、执行前确认和结果复核共同约束。

第四，它没有保证Server值得信任。

官方规范明确提醒，工具描述等信息应视为不可信内容，除非它来自可信Server。能接通，只说明通信成功；不代表代码安全、数据可靠或动作符合用户意图。

因此，评价一个MCP接入不能只看“连没连上”，还要分别检查真实权限、模型决策、Server来源和执行结果。

接入一个Server前，真正该看什么？

不要先问“它有多少工具”，先看它能碰到什么。

如果它只需要读取一个项目目录，就不要给整个硬盘；如果它只需要查询日历，就不要同时授予删除权限。写入、发送、支付、删除和公开发布等高影响操作，应在执行前显示目标、参数和影响范围。

还要保留最基本的验证链路：谁发起了调用，调用了哪个工具，传入什么关键参数，返回了什么结果，最终文件或记录是否真的存在。

因此，一个可靠的MCP接入至少包括：可信来源、最小权限、敏感操作确认、参数校验、结果复核和可追溯日志。协议提供连接骨架，安全边界仍要由应用和使用者建立。

MCP真正改变的，是组合能力的成本

回到开头的任务。

正文可以来自文件Server，旁白由TTS Server生成，成片由视频Server渲染。它们不必属于同一家厂商，AI应用也不必为每种组合重新发明一套交流方式。

这就是MCP的价值：它把“每个应用单独适配每个工具”，变成“应用和工具分别适配同一套协议”。连接数量增加时，这种差别才真正明显。

但工具接通以后，新的问题马上出现：AI刚才读过的项目要求，下次还记不记得？用户偏好应该保存多久？记错的信息由谁修改或删除？

下一期，我们继续进入AI应用内部：第32期 | AI长期记忆不等于保存全部聊天记录。

这里是「漫时序」｜slowlumen / 慢一点，和 AI 聊久一点。