摘要

MCP 的根本押注，是让 AI 应用而非模型成为通用集成层。 David 和 Justin 将其称为“AI 应用的 USB-C 接口”：IDE、聊天产品和智能体可以通过这一通用协议接入工具、上下文和可复用提示词。这个区分具有战略意义，因为 MCP 可以跨越模型和应用，而不必绑定某一家模型厂商的函数调用接口。
这个项目源于自下而上的 M×N 集成难题，并非 Anthropic 的战略总盘算。 2024 年 7 月，David 被 Claude Desktop 的 artifacts 与能够操作本地文件的 IDE 之间反复复制内容折磨，于是凭借开发者工具经验，在众多应用与众多集成之间插入一层协议。David 和 Justin 花了几个月处理那些“非常不讨喜的细节”，随后在一次内部黑客松展示了从跨对话记忆到 3D 打印机控制器等能力，并于 11 月 25 日发布 MCP。
MCP 与通用 API 规范的差异，在于面向应用的语义和控制权。 Tools 面向由模型发起的操作，resources 暴露可寻址的数据，供用户或应用选择和建立索引，prompts 则提供由用户发起的工作流或多步骤消息序列。OpenAPI 依然有用，转换器也可以将其接入 MCP，但它无法自然表达这一更高层的呈现模型，也无法表达 MCP 刻意设计的有状态、双向交互。
Tool calling 可能占据当前集成的“95%或以上”，这意味着 MCP 设计的大量能力尚未被商业化利用。 David 希望客户端把 resources 转化为完整的 RAG 索引，让服务器附带提示词来教用户使用工具，并支持 sampling，使服务器无需嵌入模型 SDK 或 API key 就能请求补全。他反复感到，协议已经兼容更丰富的工作流，但客户端支持始终没有跟上。
服务器创建的成本低到足以带来快速供给、严重重复，以及超越 API 封装器的新类别。 一个基础服务器大约半小时、100–200 行代码就能完成；拿到 SDK 或相关规格片段后，LLM 往往也能直接生成一个。嘉宾预计，市场既会出现传统连接器，也会出现增强模型能力的服务器，例如记忆、顺序思考、潜在的“三选一”推理，以及能够调用其他 MCP 服务器的递归服务器。
双向性让 MCP 有望成为智能体组合的底层，但其创造者拒绝宣称智能体必须属于协议内部。 服务器可以向客户端请求模型采样，也可以作为其他服务器的客户端，组成递归的 DAG 式系统；如果再加入内部模型与工具循环，这类组件就可能成为智能体。Justin 的克制很重要：一个试图包办一切的“上帝盒子”，也可能“什么都做不好”，因此是否支持智能体仍是开放的设计问题。
真正限制普及的不是基础服务器创建，而是远程部署、授权和信任。 拟议中的 streamable HTTP 传输层保留了有状态交互和服务器主动请求的能力，同时支持会话恢复与水平扩展；授权草案则为远程服务器采用 OAuth 2.1。与此同时，多个竞争实现预计会在使用中逐步收敛，但注册表无法消除供应链攻击：“下一次更新就可能攻陷一个受信任的软件包”，因此代码检查、信誉和治理仍将是生态系统的长期风险。

精读

1. MCP 扩展的是 AI 应用，而不是模型

Justin 给出的简洁定义是：Model Context Protocol 帮助 AI 应用“把自己扩展出去”，接入一个集成生态。MCP 使用客户端—服务器术语，但实际用途并不陌生：为承载模型的产品增加能力和外部连接。
David 划出的关键边界是，MCP 面向“AI 应用，而不是模型本身”。把它称为“AI 应用的 USB-C 接口”，正好概括了这一野心：在应用与广泛功能生态之间建立一个通用、双向的连接器。
双向性之所以重要，是因为 MCP 服务器不只是被动响应请求。它可以暴露工具和上下文，向应用发起请求，也可以要求控制模型交互的客户端执行一次补全。

2. 催生协议的是产品摩擦，而非公司战略

David 说，MCP “并不属于什么宏大战略”。2024 年加入 Anthropic、负责内部开发者工具后，他希望员工更深入地使用这些模型，却发现每个应用都被困在自己的功能边界里。
具体摩擦推动了设计：Claude Desktop 有 artifacts，却无法扩展；IDE 能操作文件，却没有 artifacts。不断在两者之间复制内容，让他开始追问：“我们需要什么？”多个应用乘以多个集成，答案就是一套协议。
一个被放弃的内部 LSP 相关项目又提供了另一块拼图。让这些想法“先放几个星期”后，David 走进一个房间，告诉 Justin 他们应该做一套协议；Justin 立刻看到了潜力，并加入进来。
工作大约始于 2024 年 7 月，最终在 11 月 25 日公布。Justin 回忆说，团队先花了几个月“打地基”，随后一次内部黑客松注入了动力，其中包括一个能够控制 3D 打印机的 MCP 服务器。

3. LSP 让团队在无需创新之处保持朴素

Language Server Protocol 提供了核心类比：在 LSP 之前，每个编辑器都要为每种语言单独开发集成。统一协议把成熟的语言服务器实现与 IDE 工作拆开，让 M×N 市场的两端可以独立进化。
MCP 借用了 JSON-RPC、双向通信，以及 LSP 对功能如何在应用中呈现的重视。团队也研究了对 LSP 的批评，包括它对 JSON-RPC “非常独特的处理方式”，并有意没有复制所有设计选择。
David 的协议原则是，选择真正需要创新的地方，在“其他部分保持朴素”。线路上的字节不是突破口；真正有价值的设计工作，在于挑选 AI 原生的基本单元，并定义应用与集成之间如何互动。
实现工作依然不轻：发布时需要 TypeScript 和 Python SDK，需要为 Zed 提供 Rust 支持，还要完成客户端、服务器，以及通过标准输入输出进行可靠本地子进程通信的能力。Zed 的开源实现大约在发布前 1 个半月以另一个名字出现，提供了早期公开的“alpha”。

4. Tools、resources 和 prompts 编码了交互控制权

Justin 说，这些基本单元是从应用开发者视角设计的：一个 IDE、聊天产品或智能体可能从某个集成中接收哪些不同类型的东西？从这个角度看，工具调用“必要，但远远不够”。
Tools 把一项操作交给模型决定。Resources 代表数据或上下文，并始终由 URI 标识；应用可以通过附件菜单展示它们，让用户明确选择，也可以先由智能体检索，再把相关材料加入上下文窗口。
Prompts 则刻意设计成由用户发起的消息或宏，类似斜杠命令或自动补全。讨论还强调了多步骤提示，而不是一条静态提示；具体工作流如何呈现，完全由应用决定。
David 说，工具调用可能占据集成的“95%或以上”，尽管 Zed 的首个实现使用的是 prompts，而非 tools。一个有用的模式是先把 Sentry 回溯信息拉入上下文，再让模型运行；何时需要这段信息由用户决定，而不是交给自主工具循环。

5. Resources 可以支撑 RAG 和可复用的应用功能

David 举出的未实现资源案例是：服务器将文档集合或数据库暴露为可寻址资源，客户端围绕它建立完整的 RAG 索引。资源语料库可能远大于上下文窗口，因此由应用控制检索，比把所有内容塞进工具更合适。
对数据库而言，David 将不同环节清楚拆开：执行 SQL 查询可以是由模型调用的工具，而表结构天然适合作为资源。用户可以附加某个具体 schema，也可以让 Claude Code 这样的智能体应用自行找到合适的 schema。
Zed 提供了另一个具体实现：一个 MCP 服务器将共享的默认提示词填充进其内置提示词库。双方约定了 URI 和数据格式，但这个例子展示了现有应用功能如何拆分成可互操作的服务器。
David 更广泛的检验标准，是检查现有应用中哪些功能可以拆出来。IDE 的附件菜单本来就像一个资源浏览器；MCP 让外部提供商可以接入这一能力，同时保留应用在用户体验上的差异化空间。

6. 面向 LLM 的接口应该返回更多数据，而不是更少

一位主持人质疑 Google Maps 参考服务器为何要筛选哪些 API 属性可以传给模型，因为这会重演熟悉的 SDK 问题：缺失的参数或后来新增的参数变得不可访问。David 接受了这一批评，并表示欢迎提交 pull request。
MCP 的工具结果不必遵循僵硬的结构化 schema；它们可以是文本、图像，或直接发送给模型的消息。David 更倾向于返回“一整片数据丛林”，相信 LLM 能自行找出重点，甚至几乎原样透传底层 API 结果。
David 认为，开发者仍在用传统 API 的直觉设计 LLM 接口，需要重新学习抽象何时真正有帮助。随着模型快速进化，“把数据直接扔给那个特别擅长处理数据的东西”可能胜过预先格式化地址等字段，但服务器仍应统一那些尴尬的数据编码。

7. MCP 通过 AI 专属语义和状态补充 OpenAPI

对于“MCP 与 OpenAPI 的区别”，David 的回答是：OpenAPI 依然非常适合描述 API，但对于丰富的模型交互来说粒度太细。REST 规范不会告诉你，某个对象应该作为用户选择的资源、模型控制的工具，还是可复用的提示词出现。
David 还把有状态性视为另一条分界线。随着文本扩展到音频、视频和其他模态，团队预计 AI 交互会变得更有状态；今天对无状态 API 的偏好，可能只是“某个时间点上的暂时状态”，而非永久架构。
两位嘉宾都没有把这两套协议视为互斥关系。社区成员很快就构建了转换器，让 OpenAPI 规范通过 MCP 暴露出来；反向转换也完全可以设想：传统服务描述使用 OpenAPI，而应用需要更丰富的 AI 原生行为时使用 MCP。

8. 服务器供给从半小时原型开始

David 建议的起点刻意保持简单：选定语言和 SDK，做一个自己真正有用的工具，写一段基础描述，通过标准输入输出连接起来，然后观察模型行动。开发者“差不多半小时”就能看到结果，之后再投入评测或打磨提示词。
Justin 估计，一个初始服务器通常只需 100–200 行代码。他最推荐的加速方式，是把 SDK 代码放进 LLM 上下文，要求它构建服务器；结果可能还需要完善，但它可以“一次生成一个基本能做你想做事情的东西”。
即便没有 SDK，David 也建议提供相关规格片段，再附上另一种语言的 SDK。生成生产级 SDK 是另一回事，但让 Haskell 或其他尚未支持的语言跑通模型工具调用，往往并不难。
嘉宾预计，市场既会有自动生成的 API 适配器，也会出现真正原生于 MCP 的新体验。Memory 可以跨对话持久化信息；sequential thinking 提供显式的推理过程；还有一种假设中的服务器，可以对答案尝试 3次并选出最佳结果。

9. Sampling 和递归服务器为智能体打开一条路径

Sampling 允许服务器向客户端请求一次补全，而客户端本来就拥有模型循环。因此，一个摘要服务器既不需要模型 SDK，也不需要 API key，其行为仍与模型无关：它使用用户在 Cursor 或其他客户端中选定的模型。
David 描述了一个更丰富的组件：它同时是 MCP 服务器和 MCP 客户端。它可以服务于应用，同时自行消费其他服务器，保留递归属性，让开发者能够组装 MCP 组件链或 DAG 式图结构。
这种模式可以支撑一个晨间工作流，读取并总结选定的 subreddit。当前限制在于鸡生蛋问题：服务器作者在更多客户端实现 sampling 等基本能力前，不愿围绕它们开发；而客户端在没有有吸引力的服务器之前，也看不到足够需求。
对于这种递归组件是否属于智能体，David 区分了简单代理与运行自身模型—工具循环的组件。Justin 则继续维持开放边界：MCP 可能用来表示智能体、连接智能体，也可能继续专注于 AI 应用本身。

10. 工具规模更取决于语义重叠，而非数量

一位主持人回忆起 2024 年 4 月一个声称支持 250 个工具的例子，并询问 MCP 应该偏向一套扁平、宽泛的工具集，还是嵌套服务器。David 说，对 Claude 而言，“几百个”仍是相对安全的估计，但不存在适用于所有场景的上限。
工具描述、名称和模型能力共同决定上限。用途不同的独立服务器可以舒适共存，但 GitHub 和 GitLab 工具的操作与措辞高度重叠，容易让模型混淆。
应用可以筛选工具，让更小的模型挑出相关子集，或在其他服务器前面放置筛选代理。IDE 也可以让用户针对不同任务启用不同功能集，而不是始终打开所有集成。
Justin 保留了 MCP 的控制层级：“由模型控制”意味着由模型调用工具，并不意味着应用放弃权力。客户端和用户仍拥有完整控制权，可以筛选、转换或丰富描述；David 也在单独考虑，让服务器声明跨 tools、prompts 和 resources 的逻辑分组。

11. 参考服务器展示了模型未来可能吸收的能力

Memory 和 sequential-thinking 服务器部分源于 Anthropic 的发布前黑客松。它们并非简单封装：MCP 让同事无需成为端到端专家，也不必访问专有代码，就能快速原型化新的能力。
Filesystem 服务器尤其贴近个人需求。它直接解决了最初的摩擦，让 Claude 能够与本地项目文件交互并编辑；Justin 在开发游戏时使用了这一能力，David 称其为协议的“精神起点”。
Sequential thinking 与 Anthropic 后来的 “think tool” 没有已知的共同谱系。David 将两者都视为更广泛推理辅助设计空间中的方案；Justin 则观察到，MCP 服务器可以在几天内填补能力缺口，而类似行为未来可能被模型原生吸收。

12. 远程运行迫使状态、安全与开放性之间做出取舍

最初的 SSE 传输层假设连接会长期保持，能够保留状态，却给规模化运营带来负担。经过几个月有争议的讨论——并非因为某条病毒式传播的推文——团队提出了 streamable HTTP：服务器可以先使用普通的请求—响应 HTTP，再增加流式传输和服务器主动请求。
会话恢复是连接有状态性与基础设施实用性的桥梁。如果双方都支持断开后继续，服务器就能保留丰富的交互，同时进行水平扩展，并容忍不稳定的网络连接。
下一版协议的授权草案，重点是通过 OAuth 2.1 实现用户对服务器的访问。David 说，理想情况下，用户不应被迫把 API key 粘贴进命令；服务器甚至可以在 OAuth 授权页面内收集 API key，同时保留一套可互操作的客户端流程。
治理也遵循同一条保守原则：协议设计中“增加容易，删除困难”。Anthropic 希望实现真正的多公司共同维护，又避免“被委员会拖死”；Microsoft、JetBrains、Spring AI、Pydantic、Block、Shopify 等已经在贡献实现或规格工作，维护者则优先看重能运行的原型，而不是临时发表的意见。
David 预计，市场会出现一大批彼此竞争的 GitHub 服务器，也很可能出现大量 Postgres 服务器，而不是一套强制统一的标准库，最终由实际使用筛选赢家。厂商构建的服务器，例如 Cloudflare Workers 的专用服务器，可能成为事实上的标准实现，但协议本身应继续保持开放。
信任问题仍未解决，因为下载量、评论或此前的审查，都无法保证后续版本安全。讨论警告说，“下一次更新就可能攻陷一个受信任的软件包”；swyx 建议人们使用 MCP Inspector 检查实际流量，而任何注册表都无法摆脱 npm 和 PyPI 所熟悉的供应链问题。
嘉宾最后列出的愿望清单，暴露出产品仍未完成的部分：David 希望有支持 sampling 的客户端，以及一个与模型无关的摘要，告诉他喜欢的 Reddit 帖子发生了什么，或过去一周 EVE Online 里发生了什么；Justin 希望客户端实现完整规格，并与 Godot 引擎集成，让 Claude 可以处理 shader 代码、运行游戏或进行试玩测试。

每日交易：CoreWeave IPO与Scale估值250亿美元特朗普关税倾销