Model Context Protocol （MCP） – MCP Protocol 博客

掌握MCP工具开发：让AI智能体发挥最大潜力

Thu, 12 Sep 2024 00:00:00 +0000

在AI智能体快速发展的今天，工具的质量直接决定了智能体的能力边界。一个精心设计的工具可以让智能体事半功倍，而糟糕的工具设计则可能让最强大的AI模型也束手无策。

那么，如何为AI智能体编写真正有效的工具呢？基于Anthropic团队在大规模MCP工具开发中的实践经验，我们总结出了一套系统化的方法论。

重新思考工具设计理念

传统软件开发中，我们习惯于为确定性系统编写代码 —— 相同输入必然产生相同输出。但AI智能体是非确定性的，它们面对同样的问题可能选择不同的解决路径。

这种本质差异要求我们从根本上重新思考工具设计：

传统API设计：为开发者优化，注重功能完整性
智能体工具设计：为AI优化，注重认知友好性

例如，一个返回所有联系人的list_contacts工具对程序来说很正常，但对智能体而言却是灾难 —— 它需要逐token处理每个联系人，浪费宝贵的上下文空间。更好的选择是search_contacts工具，让智能体能直接定位到相关信息。

系统化的工具开发流程

1. 快速原型验证

不要试图一步到位设计完美工具。从简单原型开始：

# 快速原型示例
@mcp_tool
def schedule_meeting(attendee_email: str, duration_minutes: int = 30):
 """为智能体设计的会议安排工具"""
 # 整合多个步骤：查找可用时间 + 创建会议 + 发送邀请
 available_slots = find_availability(attendee_email)
 meeting = create_meeting(available_slots[0], duration_minutes)
 send_invitation(meeting, attendee_email)
 return f"已安排与{attendee_email}的{duration_minutes}分钟会议"

2. 构建评估体系

这是决定工具质量的关键步骤。创建基于真实场景的评估任务：

优秀的评估任务示例：

“客户ID 9182报告重复扣费，请查找相关日志并确定是否有其他客户受影响”
“为Sarah Chen准备留存方案，分析她的离开原因和最佳挽留策略”

避免的简单任务：

“查询客户ID 9182的信息”
“搜索支付日志”

3. 智能体协作优化

利用AI来优化AI工具 —— 这听起来很meta，但非常有效：

让Claude分析工具使用记录
识别常见的失败模式
自动优化工具描述和参数
验证改进效果

五个核心设计原则

原则1：选择正确的抽象层次

# ❌ 过于底层
def list_users() -> List[User]: pass
def list_events() -> List[Event]: pass
def create_event(user_ids, time): pass

# ✅ 合适的抽象
def schedule_event(participants: str, topic: str) -> str:
 """找到参与者共同空闲时间并创建会议"""
 pass

原则2：智能命名空间

使用前缀清晰区分不同服务和资源：

asana_search_projects vs jira_search_issues
slack_send_message vs email_send_message

原则3：返回有意义的上下文

# ❌ 技术细节过多
{
 "user_uuid": "a1b2c3d4-e5f6-7890",
 "avatar_256px_url": "https://...",
 "mime_type": "image/jpeg"
}

# ✅ 智能体友好
{
 "name": "张三",
 "role": "产品经理",
 "avatar_url": "https://...",
 "status": "在线"
}

原则4：Token效率优化

支持分页和过滤
提供简洁/详细两种响应模式
智能截断长内容
清晰的错误提示

原则5：精确的工具描述

工具描述是智能体理解工具用途的唯一途径，必须：

明确说明工具的作用和适用场景
详细描述参数含义和格式要求
提供使用示例和注意事项
避免歧义和技术术语

实战建议

开发工作流

原型测试 → 2. 评估设计 → 3. 性能测试 → 4. 智能体分析 → 5. 迭代优化

常见陷阱

为每个API端点创建对应工具（过度细分）
返回过多技术细节（认知负担）
工具功能重叠（选择困难）
忽视工具描述质量（理解偏差）

性能指标

除了准确率，还要关注：

工具调用次数和效率
Token消耗量
任务完成时间
错误率和类型

未来展望

随着AI模型能力的快速提升，工具开发也必须与时俱进。通过系统化的评估驱动开发方法，我们能确保工具质量跟上AI能力的发展步伐。

记住：有效的工具不是技术的简单包装，而是为智能体认知特性专门设计的接口。

想深入了解MCP工具开发？查看我们的完整教程，获取更多实践指导和代码示例。

加入MCP中文社区
关注 mcpcn.com 获取最新的MCP开发资讯和最佳实践分享。

MCP协议下一版本发布计划更新

Fri, 26 Sep 2025 10:00:00 -0800

发布时间表

Model Context Protocol规范的下一版本将于 2025年11月25日 正式发布，候选版本(RC)将于 2025年11月11日 推出。

我们设置了14天的RC验证窗口期，以便客户端实现者和SDK维护者充分测试协议变更。这种方法既给我们提供了完成关键改进所需的专注时间，也让我们在实践中应用新的治理模型。

今年夏天的进展

我们上一个规范版本于2025年6月18日发布，重点关注结构化工具输出、基于OAuth的授权机制、服务器发起的用户交互激发(elicitation)，以及改进的安全最佳实践。

此后，我们专注于为MCP生态系统建立更多基础：

正式治理结构

我们建立了MCP正式治理模型，包括定义的角色和决策机制。还开发了规范增强提案(SEP)流程，为贡献规范变更提供明确指导。

我们的目标是透明化——让决策程序对所有人清晰可见。像任何服务于快速发展社区的新系统一样，我们的治理模型仍在完善中。随着协议和社区的持续发展，我们正在积极优化它。

工作组

我们启动了工作组和兴趣组以促进社区协作。这些组织服务于多个目的：

为新贡献者提供清晰的切入点
赋能社区成员在其专业领域主导项目
在生态系统中分布所有权，而不是集中在核心维护者中

我们正在开发治理结构，赋予这些组织在决策和实施方面更大的自主权。这种分布式方法确保协议能够满足社区需求，同时在不同领域保持质量和一致性。

Registry开发

9月，我们发布了MCP Registry预览版——一个用于索引和发现MCP服务器的开放目录和API。Registry作为可用MCP服务器的单一真实来源，支持组织可根据特定需求定制的公共和私有子注册表。

构建MCP Registry是真正的社区努力成果。任何MCP客户端都可以通过原生API或第三方注册表聚合器使用registry内容，让用户更容易发现MCP服务器并将其集成到AI工作流中。

下一版本的优先领域

随着治理和基础设施基础的到位，我们专注于工作组确定的五个关键协议改进。

异步操作

目前，MCP主要基于同步操作构建——当你调用一个工具时，一切停下来等它完成。这对快速任务很好用，但需要几分钟或几小时的操作呢？

Agents工作组正在添加异步支持，允许服务器启动长时间运行的任务，客户端可以稍后回来查看结果。你可以在SEP-1391跟进进度。

无状态和可扩展性

随着组织在企业规模部署MCP服务器，新的需求不断涌现。当前实现通常需要在请求之间记住信息，这使得在多个服务器实例间横向扩展变得困难。

虽然可流式HTTP传输提供了一些无状态支持，但服务器启动和会话处理方面仍存在痛点。Transport工作组正在解决这些粗糙边缘，让MCP服务器更容易在生产环境中运行，同时为想要更复杂有状态功能的团队保持简单的升级路径。

服务器身份标识

目前，如果你想知道MCP服务器能做什么，必须先连接到它。这让客户端难以浏览可用服务器，或让我们的registry等系统自动编目功能。

我们通过让服务器通过.well-known URL发布自己来解决这个问题——这是提供元数据的既定标准。可以把它想象成服务器的名片，任何人无需先敲门就能阅读。这将让每个MCP消费者的发现体验更加直观。

官方扩展

随着MCP的发展，我们注意到针对特定行业和用例的模式不断涌现——有价值的实现不一定属于核心协议规范。

我们正在官方认可和记录最流行的协议扩展，而不是让每个人都重新发明轮子。这个经过验证的模式精选集将为构建医疗保健、金融或教育等专业领域的开发者提供坚实的起点，而不是从头构建每个自定义集成。

SDK支持标准化

今天选择MCP SDK可能具有挑战性——很难衡量你将获得的支持水平或规范合规性。一些SDK更新速度很快，而其他SDK在功能方面可能滞后。

我们正在为SDK引入清晰的分层系统。在承诺依赖之前，你将确切知道你正在签约什么，基于规范合规速度、维护响应能力和功能完整性等因素。

征集贡献者

MCP的强大只因其背后的社区。无论你是热衷于构建SDK的个人开发者，还是希望投资生态系统的公司，我们在几个关键领域需要你的帮助。

SDK维护

TypeScript SDK - 需要更多维护者进行功能开发和bug修复
Swift SDK - 需要关注以支持Apple生态系统
其他语言SDK欢迎持续贡献

工具开发

Inspector - 为MCP服务器开发者开发和维护调试工具
Registry - 后端API和CLI开发；特别欢迎Go专业知识

来自客户端开发者的反馈

我们经常谈论MCP服务器，但客户端同样重要——它们是连接用户与整个MCP生态系统的桥梁。如果你正在构建MCP客户端，你从独特角度看待协议，我们需要这种视角嵌入协议设计中。

你在实现挑战、性能瓶颈和用户需求方面的实战经验直接影响协议下一步应该走向何方。无论是对现有功能的反馈还是简化开发者体验的想法，我们都想听到你的声音。

加入官方MCP Discord的#client-implementors工作组频道。

展望未来

随着治理结构和工作组的到位，我们更有能力高效处理重大协议改进，同时确保每个人在流程中都有发言权。今年夏天完成的基础工作为我们提供了坚实的构建基础。

11月即将推出的改进——异步操作、更好的可扩展性、服务器发现和标准化扩展——将帮助MCP成为生产AI集成的更强大支柱。但我们无法独自完成。

MCP的力量一直在于它是由社区为社区构建的开放协议。我们很高兴继续一起构建它。

感谢你的持续支持，期待很快分享更多内容。

MCP Apps 正式发布 - 为 MCP 客户端带来 UI 交互能力

Mon, 26 Jan 2026 00:00:00 +0000

今天，我们正式宣布 MCP Apps 已作为官方 MCP 扩展正式上线。

工具现在可以返回交互式 UI 组件，直接在对话中渲染：仪表板、表单、数据可视化、多步骤工作流等。这是第一个官方 MCP 扩展，已准备好投入生产使用。

什么是 MCP Apps？

MCP Apps 让工具能够返回富交互式界面，而不仅仅是纯文本。当工具声明一个 UI 资源时，宿主（Host）会在沙盒化的 iframe 中渲染它，用户可以直接在对话中与之交互。

以下是一些 MCP Apps 大显身手的场景：

数据探索：销售分析工具返回一个交互式仪表板。用户可以按地区筛选，深入查看特定账户，导出报表，无需离开对话。
配置向导：部署工具呈现一个具有依赖字段的表单。选择"生产环境"会显示额外的安全选项；选择"预发布环境"则显示不同的默认值。
文档审查：合同分析工具内联显示 PDF，高亮显示条款。用户点击批准或标记章节，模型实时看到他们的决策。
实时监控：服务器健康工具显示实时指标，随系统变化而更新。无需重新运行工具即可查看当前状态。

这些交互如果是文本交流会很笨拙，而 MCP Apps 让它们变得自然——就像使用任何其他基于 Web 的 UI 应用一样。

工作原理

MCP Apps 的架构依赖于两个关键的 MCP 原语：

带有 UI 元数据的工具：工具包含 _meta.ui.resourceUri 字段，指向 UI 资源
UI 资源：通过 ui:// scheme 提供的服务器端资源，包含打包的 HTML/JavaScript

// 带有 UI 元数据的工具
{
 name: "visualize_data",
 description: "将数据可视化为交互式图表",
 inputSchema: { /* ... */ },
 _meta: {
 ui: {
 resourceUri: "ui://charts/interactive"
 }
 }
}

宿主获取资源，在沙盒化的 iframe 中渲染，并通过 postMessage 上的 JSON-RPC 启用双向通信。

为什么需要 MCP Apps？

MCP 非常适合将模型连接到数据并赋予它们采取行动的能力。但工具能做的事情和用户能看到的事情之间仍然存在上下文差距。

考虑一个查询数据库的工具。它返回数据行，可能有数百行。模型可以总结这些数据，但用户通常想要探索：按列排序、筛选到日期范围、点击查看特定记录。

使用文本响应，每次交互都需要另一个提示词。“只显示上周的。““按收入排序。““第 47 行的详情是什么？“这可以工作，但很慢。

MCP Apps 弥补了这一差距。模型保持在循环中，看到用户的操作并相应响应，但 UI 处理文本无法做到的事情：实时更新、原生媒体查看器、持久状态和直接操作。结合起来，它们在一个熟悉的界面中为模型和用户提供所需的所有上下文。

App API

要构建新的 MCP Apps，开发者可以使用 @modelcontextprotocol/ext-apps 包，它提供了用于 UI 与宿主通信的 App 类：

import { App } from "@modelcontextprotocol/ext-apps";

const app = new App();
await app.connect();

// 从宿主接收工具结果
app.ontoolresult = (result) => {
 renderChart(result.data);
};

// 从 UI 调用服务器工具
const response = await app.callServerTool({
 name: "fetch_details",
 arguments: { id: "123" },
});

// 更新模型上下文
await app.updateModelContext({
 content: [{ type: "text", text: "用户选择了选项 B" }],
});

因为应用运行在客户端内部，它们可以做普通 iframe 做不到的事情。它们可以记录事件用于调试、在用户的浏览器中打开链接、发送后续消息来推动对话前进，或者悄悄地更新模型的上下文以供后续使用。所有这些都通过标准的 postMessage 进行，所以您不会被锁定在任何框架中。

安全模型

从 MCP 服务器运行 UI 意味着在 MCP 宿主中运行您没有编写的代码。MCP Apps 通过多层机制来处理这个问题：

Iframe 沙盒：所有 UI 内容都在具有受限权限的沙盒化 iframe 中运行
预声明模板：宿主可以在渲染前审查 HTML 内容
可审计消息：所有 UI 到宿主的通信都通过可记录的 JSON-RPC
用户同意：宿主可以要求对 UI 发起的工具调用进行明确批准

如果某些内容看起来可疑，宿主可以在它渲染之前阻止它。当然，用户在连接之前应该继续主动和彻底地审查 MCP 服务器。

Agentic UI 框架的未来

MCP-UI 和 OpenAI Apps SDK 开创了 MCP Apps 现在标准化的模式。这些项目证明 UI 资源可以且确实自然地适合 MCP 生态系统，各种规模的企业都在生产环境中采用 OpenAI 和 MCP-UI SDK。

MCP-UI 不会消失。SDK 支持 MCP Apps 模式，客户端 SDK 是寻求采用 MCP Apps 的宿主的推荐框架。社区继续为规范做出广泛贡献。如果您已经在使用 MCP-UI，请继续使用。当您准备好时，迁移到官方扩展很简单。

客户端支持

MCP Apps 目前已在以下客户端支持：

Claude - Web 和桌面版现已可用
Goose - 现已可用
Visual Studio Code - Visual Studio Code Insiders 中可用
ChatGPT - 本周开始支持

这是第一次，MCP 工具开发者可以发布一个交互式体验，在广泛采用的各种客户端上工作，而无需编写一行客户端特定代码。

行业声音

“我对 MCP Apps 开启的可能性感到兴奋。看到一瞥什么是可能的，我迫不及待想看到社区将构建什么。”

—— David Soria Parra，MCP 联合创造者，Anthropic 技术团队成员

“MCP Apps 在 MCP-UI 和 ChatGPT Apps SDK 的基础上构建，为人们提供丰富的视觉交互体验。我们很自豪能支持这个新的开放标准，期待看到开发者用它构建什么，因为我们增长 ChatGPT 中可用的应用选择。”

—— Nick Cooper，OpenAI 技术团队成员

“MCP Apps 以将人类置于中心的方式扩展了 Model Context Protocol。行业已将助手嵌入到单个应用中，创建了分散的、孤立的体验。MCP 通过使应用成为代理中的可插拔组件来颠覆这一点。MCP Apps 通过将用户界面带入代理体验本身进一步扩展了这一点。”

—— Andrew Harvard，Block 设计工程师，Agentic UX

快速开始

ext-apps 仓库包含 SDK 和可工作的示例：

threejs-server - 3D 可视化
map-server - 交互式地图
pdf-server - 文档查看
system-monitor-server - 实时仪表板
sheet-music-server - 乐谱
更多示例

选择一个接近您正在构建的示例，从那里开始！

资源

文档: MCP Apps 指南
快速开始: MCP Apps 入门
SDK: @modelcontextprotocol/ext-apps
示例: ext-apps 仓库

反馈

如果您正在为 Claude.ai 构建 MCP Apps 并遇到实现问题，请在 github.com/anthropics/claude-ai-mcp 报告。

如果您正在使用 ChatGPT Apps SDK 构建应用并遇到问题或有疑问，请在 OpenAI 社区论坛的 ChatGPT Apps 类别中发布。

致谢

MCP Apps 是跨多个团队和社区协作的结果。

Ido Salomon 和 Liad Yosef 创建了 MCP-UI 并主持 #ui-wg 频道，孕育了许多 MCP Apps 现在标准化的模式。

Nick Cooper 在 OpenAI 帮助交付了 OpenAI Apps SDK，使每个人都能够在与大语言模型的交互中超越文本。

Sean Strong、Olivier Chafik、Anton Pidkuiko 和 Jerome Swannack 从 Anthropic 帮助指导从提案到生产的计划。

UI 社区工作组 通过无数次讨论提供反馈、审查草案、测试早期实现，并推动灵活性和安全性之间的正确权衡。

感谢每个人的贡献。现在去构建一些很酷的东西吧！

一月 MCP 核心维护者更新

Fri, 23 Jan 2026 00:00:00 +0000

自我们首次发布 MCP 以来，发生了很多事情。我们在2025年以重大规范更新收官，势头并未放缓。没有社区，这一切都不会发生：每一个 PR、每一个提交的问题、每一个构建的服务器和客户端。正是这种能量推动着 MCP 不断前进。

为了保持这种势头，核心维护者团队也在不断发展。

离任的核心维护者

首先，有一些消息。Inna Harper 和 Basil Hosmer 将离开核心维护者团队，专注于其他项目。

Inna 和 Basil 从 MCP 的早期就一直参与。他们在一些关键时刻帮助塑造了协议，从关键设计决策到设计和交付我们的官方 SDK，以及帮助发布所有主要的规范版本。MCP 今天的方方面面都有他们的印记。

感谢你们两人的贡献和对项目的奉献。MCP 因为你们而变得更好。

欢迎新维护者

我们很高兴欢迎三位新的核心维护者加入团队。他们已经积极参与 MCP 讨论，审查规范增强提案 (SEP)，并帮助塑造协议的方向。

Peter Alexander

Peter Alexander 是 Anthropic 模型上下文协议团队的技术人员成员。

在加入 Anthropic 之前，Peter 是 Meta 的资深 Staff 软件工程师，在产品和基础设施的各个领域工作，包括虚拟现实、视频会议和大规模实时发布/订阅数据基础设施。他还在游戏行业的 Codemasters 工作过一段时间，负责主机和 PC 上的 Grid 和 DiRT 系列游戏，担任游戏玩法负责人。

Peter 撰写了多个 SEP，包括扩展框架和资源内容元数据，并且是我们 SDK、治理、路线图和规范变更提案的积极审查者和贡献者。

Caitie McCaffrey

Caitie McCaffrey 是 Microsoft 的软件工程师和技术负责人。Caitie 在多个领域构建了大规模分布式系统和服务，包括 AI 平台、游戏、社交媒体和物联网。

此前，Caitie 曾担任 Microsoft 首席执行官 Satya Nadella 和首席技术官 Kevin Scott 的技术顾问，推动 AI 转型、开发体验和安全方面的战略工作。在她职业生涯的早期，Caitie 是 Twitter 可观察性团队的技术负责人，并在 Microsoft Game Studios 和 343 Industries 的游戏行业工作，为 Halo 4、Halo 5 和 Gears of War 2 & 3 等游戏做出贡献。她拥有康奈尔大学的计算机科学学位。

Caitie 一直在审查并帮助我们制定治理和传输提案，将她的分布式系统专业知识带到协议设计讨论中。

Kurtis Van Gent

Kurtis Van Gent 是领导 Google Cloud 数据库 AI 生态系统的高级 Staff 软件工程师。他推动整个产品组合的生态系统和集成，领导 Data Cloud 的 MCP 和数据库的 MCP 工具箱等举措。

Kurtis 一直在推动传输工作组，该工作组撰写了已接受的请求负载解耦 SEP，并正在领导无状态协议提案。他对可扩展性和容错性的关注塑造了关于 MCP 如何发展的关键讨论。

欢迎加入团队，Peter、Caitie 和 Kurtis。

展望未来

如果我可以保证一件事，那就是 2026 年将是 MCP 忙碌的一年。目前有多个活跃的 SEP 正在流程中工作，包括用于身份验证的 DPoP 扩展、用于传输的多轮 SSE和用于发现的服务器卡。这只是我们目前正在迭代的许多改进的一个预览。生态系统不断扩大，每周都有更多的客户端、服务器和 SDK 版本发布。

MCP 作为协议也已经成熟。作为一个开源实验开始的东西，现在正在各种规模的公司生产环境中运行。这改变了我们需要关注的内容。有了这个团队，我们正在致力于对 MCP 增长下一阶段至关重要的难题：为企业场景强化规范、改进安全和身份验证模式、提供更好的 SDK 实施指导，并确保 MCP 能够扩展以满足在关键系统中部署它的组织的需求。同时，我们保持贡献者体验的热情，并确保协议响应开发者的实际需求。

如果你想成为其中的一员，请查看我们的治理文档或了解如何开始 MCP 贡献。来和我们一起构建吧。

探索 MCP 传输的未来

Fri, 19 Dec 2025 00:00:00 +0000

当 MCP 于 2024 年 11 月首次发布时，相当多的用户依赖本地环境，通过 STDIO 将客户端连接到服务器。随着 MCP 成为 LLM 集成的首选标准，社区需求不断演变，导致围绕远程服务器构建基础设施。现在对于可以大规模运行的分布式部署的需求日益增长。

可流式 HTTP 传输是向前迈出的重要一步，实现了远程 MCP 部署并解锁了新的用例。然而，随着企业部署扩展到每天数百万次请求，早期采用者遇到了实际挑战，使得难以利用现有的基础设施模式。有状态连接的摩擦已成为托管服务和负载均衡的瓶颈。

其中一些挑战包括：

基础设施复杂性：负载均衡器和 API 网关必须解析完整的 JSON-RPC 负载来路由流量，而不是使用标准的 HTTP 模式。
扩展摩擦：有状态连接强制"粘性"路由，将流量固定到特定服务器，阻碍有效的自动扩展。
简单工具的高门槛：构建简单、临时工具的开发人员通常需要管理复杂的后端存储以支持基本的多轮交互。
会话范围模糊：没有可预测的机制来定义对话上下文在分布式系统中的开始和结束位置。

路线图

在过去几个月中，传输工作组与社区和 MCP 核心维护者合作，开发了解决这些挑战的方案。

在这篇文章中，我们分享了可流式 HTTP 传输演进的路线图，并邀请社区反馈来帮助塑造 MCP 传输的未来。

无状态协议

MCP 最初被设计为一个有状态协议。客户端和服务器通过持久的双向通道保持相互感知，该通道以交换能力和协议版本信息的握手开始。由于此状态在整个连接中保持固定，扩展需要粘性会话或分布式会话存储等技术。

我们设想一个未来，其中代理应用程序是有状态的，但协议本身不需要是无状态的。无状态协议实现扩展，同时在需要时仍提供支持有状态应用程序会话的功能。

我们正在探索通过以下方式使 MCP 无状态：

替换 initialize 握手，并在每个请求和响应中发送共享信息。
提供 discovery 机制，让客户端查询服务器能力（如果它们需要尽早获取信息），例如 UI 水合场景。

这些更改启用了更动态的模型，其中客户端可以乐观地尝试操作，如果不支持某项功能，则会收到明确的错误消息。

注意：许多 SDK 在其服务器传输配置中已经提供了 stateless 选项，尽管行为在不同实现中有所变化。作为此路线图的一部分，我们将致力于在所有官方 SDK 中标准化"无状态"的含义，以确保一致的行为。

提升会话

目前，会话是传输连接的副作用。使用 STDIO，会话隐含在进程生命周期中；使用可流式 HTTP，会话在服务器初始化期间分配 Mcp-Session-Id 时创建。这可能导致传输层和应用层关注点之间的混淆。

我们正在考虑将会话移至 数据模型层，使它们显式而不是隐式。

这将允许 MCP 应用程序将会话作为其域逻辑的一部分来处理。我们正在探索几种方法，其中类似 cookie 的机制是一个潜在的候选者，用于将会话状态与传输层解耦。

这个方向反映了标准 HTTP，其中协议本身是无状态的，而应用程序使用 cookie、令牌和类似机制构建有状态语义。会话创建的确切方法仍在设计中，目标是消除远程 MCP 场景中会话含义的现有模糊性。

引导和采样

两个 MCP 功能是现代 AI 工作流程的核心：引导，请求人工输入，以及采样，启用代理 LLM 交互。

大规模支持这些功能需要重新思考它们依赖的双向通信模式。目前，当服务器需要更多信息来完成工具调用时，它会暂停执行并等待客户端响应，需要它跟踪所有未完成的请求。

为了解决这个问题，我们正在考虑设计服务器请求和响应，使其类似于聊天 API。服务器照常返回引导请求，客户端同时返回请求和响应。这允许服务器纯粹从返回的消息中重建必要的状态，避免节点之间的长时间状态管理，并可能完全消除对后端存储的需求。

更新通知和订阅

MCP 在设计上是动态的 - 工具、提示词和资源可以在操作期间更改。目前，服务器向客户端发送 ListChangedNotification 消息，作为使其缓存失效的提示。

我们正在探索用显式订阅流替换通用 GET 流。客户端将为其想要监视的特定项目打开专用流，支持多个并发订阅。如果流中断，客户端只需重新启动它，无需复杂的恢复逻辑。

为了使通知真正可选 - 作为优化而不是要求 - 我们正在考虑向数据添加生存时间（TTL）值和版本标识符（如 ETags）。这将允许客户端独立于通知流做出智能缓存决策，显著提高可靠性。

JSON-RPC 信封

MCP 对所有消息信封使用 JSON-RPC，包括方法名和参数。当我们为 HTTP 部署进行优化时，一个常见的问题是路由信息是否应该更容易访问底层 MCP 服务器基础设施。

虽然我们将 JSON-RPC 保留为消息格式，但我们正在探索通过标准 HTTP 路径或标头暴露路由关键信息（如 RPC 方法或工具名）的方法。这将允许负载均衡器和 API 网关在不解析 JSON 正文的情况下路由流量。

服务器卡

目前，客户端必须完成完整的初始化握手才能了解 MCP 服务器的基本信息，如其能力或可用工具。这给发现、集成和优化场景带来了摩擦。

我们正在探索引入 MCP 服务器卡的方向：结构化元数据文档，服务器通过标准化的 /.well-known/mcp.json 端点暴露。服务器卡使客户端能够在建立连接之前发现服务器能力、身份验证要求和可用的原语。这解锁了用例，如自动配置、自动发现、静态安全验证和减少 UI 水合的延迟——所有这些都不需要完整的初始化序列。

官方和自定义传输

为了确保整个生态系统的最低兼容性基线，MCP 将继续仅支持两种官方传输：用于本地部署的 STDIO 和用于远程部署的可流式 HTTP。这保持了核心生态系统的统一，其中每个 MCP 客户端和服务器都可以开箱即用地互操作。

我们也认识到传输和协议变更可能会造成破坏。向后兼容性是优先事项，我们只会在关键用例绝对必要时引入重大更改。

对于有特殊需求的团队，MCP 规范支持自定义传输，为开发人员提供了构建适合其需求的替代方案的灵活性。我们的重点是通过改进 SDK 集成使自定义传输更容易实现——以便社区可以自由实验，而不会分散标准。

总结

这些更改将 MCP 重新定位为无状态、独立的请求——而不牺牲使其强大的丰富功能。服务器开发人员获得更简单的水平扩展，无需粘性会话或分布式存储。客户端获得更可预测的架构。

对于大多数 SDK 用户，无论是客户端还是服务器端，影响都将是最小的——我们专注于将重大更改减少到绝对最小。我们概述的转换是架构性的：更简单的部署、高级 MCP 功能的无服务器可行性，以及与现代基础设施模式的更好对齐。

下一步

工作已经在进行中。我们的目标是在 2026 年第一季度最终确定所需的规范增强提案 (SEP)，以包含在下一个规范版本中，该版本暂定于 2026 年 6 月发布。通过这些更改，MCP 可以轻松扩展，同时保持使其成功的人机工程学。

我们需要您的意见。在 MCP 贡献者 Discord 服务器中加入我们，或直接在 Model Context Protocol 存储库中参与传输相关的 SEP。

此路线图由使用 MCP 构建的开发人员和公司的真实反馈塑造。我们很高兴与 MCP 社区合作，不断改进协议及其功能！

MCP 加入代理 AI 基金会

Tue, 09 Dec 2025 00:00:00 +0000

今天是模型上下文协议的一个重要里程碑。Anthropic 将 MCP 捐赠给代理 AI 基金会（Agentic AI Foundation），这是 Linux 基金会下的一个定向基金。MCP 将成为这个新创建的基金会的创始项目。

在一年时间里，MCP 已成为 AI 中增长最快、采用最广泛的开源项目之一：超过 9700 万的月度 SDK 下载量，10,000 个活跃服务器，以及在 ChatGPT、Claude、Cursor、Gemini、Microsoft Copilot、Visual Studio Code 等主要 AI 平台上的顶级客户端支持。

自成立以来，我们一直致力于确保 MCP 保持开放和社区驱动。这一举措正式确认了这一承诺——确保 MCP 的供应商中立性和长期独立性，在与支持 Kubernetes、PyTorch 和 Node.js 相同的中立管理下。Anthropic 对 MCP 的承诺保持不变：我们将继续投资其开发、维护核心基础设施，并积极参与社区。

代理 AI 基金会

MCP 将成为新创建的代理 AI 基金会（AAIF）的创始项目，这是 Linux 基金会下的一个定向基金，由 Anthropic、Block 和 OpenAI 联合创立，并得到 Google、Microsoft、AWS、Cloudflare 和 Bloomberg 的支持，以推进代理 AI 的开源创新。

MCP 与另外两个创始项目一起加入：Block 的 goose 和 OpenAI 的 AGENTS.md 作为创始项目。

AAIF 董事会将就战略投资、预算分配、成员招募和新项目批准做出决定，而各个项目（如 MCP）对其技术方向和日常运营保持完全自主权。

MCP 的维护者结构保持不变

对于 MCP 来说，变化不大。我们今年早些时候引入的治理模型继续按原样运行。决定协议的人员仍然是维护它的维护者，通过我们的 SEP 流程接受社区输入的指导。

Linux 基金会提供中立的家和基础设施，使维护者能够独立运营，不会规定 MCP 的技术方向。

感谢

感谢所有迄今为止采用和贡献 MCP 的人。没有你的贡献，这一切都不可能实现。从构建服务器到维护 SDK，从提交问题到改进文档，从欢迎新访客以及其间的一切，你们使 MCP 成为今天的样子。

祝愿 MCP 在 Linux 基金会的管理下开启新篇章。

MCP 一周年：2025年11月规范发布

Tue, 25 Nov 2025 00:00:00 +0000

今天，MCP 一岁了。如果你不相信我们，可以查看最初的公告博客文章。很难想象一个小的开源实验——一个为模型提供上下文的协议——在不到十二个月的时间内成为这种情况的事实标准。

但我们不仅在今天达到了第一个周年里程碑——我们还发布了一个全新的 MCP 规范版本。在我们详细了解新内容之前，让我们做一些回顾。

一年回顾

鉴于我们在过去一年中所做的所有更改，感觉十年已经过去了。协议自创建以来已经突飞猛进，并被大量开发人员和组织采用。我们从一个小的开源实验发展成为连接数据和应用程序与大语言模型（LLM）的事实标准。

但只要有实际的 MCP 服务器可以使用以及能够与之通信的客户端，采用才能增长。在同一时间范围内，我们看到活跃 MCP 服务器的数量从几个实验性服务器增长到 数千个。如果你想到一个场景，很可能就有一个 MCP 服务器。

以下只是你可以今天尝试的众多（非常多的）MCP 服务器中的几个：

Notion 构建了一个 MCP 服务器来帮助你管理笔记。
Stripe 有一个非常广泛的 MCP 服务器来管理各种支付工作流程。
GitHub 构建了自己的 MCP 服务器来帮助开发人员自动化他们的工程流程。
Hugging Face 创建了一个 MCP 服务器，使模型管理和数据集搜索变得轻而易举。
Postman 构建了他们的 MCP 服务器来帮助自动化 API 测试工作流程。

在 MCP 生态系统中还有更多可以发现！这就是为什么我们今年早些时候推出了 MCP 注册表。它是所有可用 MCP 服务器的中央索引，自 9 月宣布以来已有近 2000 个条目。这与我们在同一个月上线的首批服务器相比增长了 407%。

生态系统正在蓬勃发展，采用正在增长，但支撑这一切的是什么？

社区与治理

MCP 的增长从来不是一个公司的努力。学生、爱好者、初创公司工程师和企业架构师都塑造了协议——提交规范增强提案（SEP）、发布新语言的 SDK、并在生产环境中压力测试我们对 MCP 的一些早期假设。MCP 服务器成为许多产品的主要组成部分，官方和非官方的（甚至有一个 Blender MCP 服务器）。这种有机的采用不是你可以随便想出来的，无论你在开源项目上的抱负有多大。

从一开始，我们就相信一切都关乎 MCP 社区。我们的社区围绕协议聚集在一起，组织诸如 MCP 开发者峰会、MCP之夜、MCP 开发日等活动，并参加其他重要活动，如 AI工程师世界博览会，以分享他们所学和构建的内容。

我们还在 Discord和 GitHub上培养了庞大的贡献者社区，帮助我们调试问题、构建惊人的工具，如 MCP Inspector、提出变更，并协助彼此交付出色的 MCP 体验。这种日常合作使我们走得更远，比任何个人或公司都能做到的。

实际上，MCP 在过去一年的成功完全归功于围绕项目成长的广泛社区——从传输、安全、SDK、文档、示例、扩展到开发工具，所有这些都由社区并为社区显著演进。

为了保持这种步伐可持续，我们花时间思考并整理了治理结构。通过它，社区领导者和 Anthropic 维护者过去和现在继续合作，找出需要解决的问题以及如何将正确的变更纳入规范。我们的维护者团队不是要把守；他们帮助发现问题、对齐解决方案，并将粗略的想法转化为实际的协议更新。

我们的治理方法虽然仍在不断发展，但已被证明是非常有价值的。我们已经能够在不破坏现有实现的情况下更快地推进关键改进。潜在贡献者现在也知道如何通过正式的工作和兴趣组加入（SEP-1302为此奠定了基础）。

尽管这是一个重大改进，但我们知道我们还没有完成。我们还有工作要做，以使这个过程变得更好——提高透明度、决策时间表、更广泛的平台覆盖等等，以帮助生态系统。我们 非常感谢 每一个参与这段旅程并帮助我们在如此短的时间内应对如此多变化的人。

其他人的看法

正如我们在上面指出的，如果没有更广泛的采用者社区，MCP 的成功 是不可能 实现的。我们很高兴该协议在行业内实现了如此多的场景。以下是我们一些关键合作伙伴和支持者的一些想法。

“在短短一年时间里，MCP 已经从一项实验演变为广泛采用的行业标准，凸显了开放合作的影响——这在 GitHub 我们深信不疑。我们社区、客户和我们自己团队的开发人员正在使用我们的 GitHub MCP 服务器、注册表和企业控制（如 MCP 允许列表），在工作流程中释放代理开发的真正好处。我们很高兴继续与更广泛的社区合作，推动这一标准向前发展。”

✦ Mario Rodriguez，首席产品官，GitHub

“我们相信开放标准是代理网络的重要组成部分——帮助模型与工具和平台更无缝地协作。OpenAI 从一开始就为 MCP 生态系统做出贡献，它现在是我们在 OpenAI 构建方式的关键部分，集成在 ChatGPT 和我们的开发者平台中。我们很高兴继续与社区合作，在协议演进时加强它。”

✦ Srinivas Narayanan，B2B 应用首席技术官，OpenAI

“自推出一年以来，MCP 已成为行业内极具影响力的开放标准，” Block 首席技术官 Dhanji R. Prasanna 说。“它迅速转向从现有系统中释放大量价值，使应用 AI 变得像很少有人预料的那样真实。MCP 是构建 Square AI 和 Moneybot 等 AI 驱动解决方案的关键，为客户节省时间并提供强大的洞察力以及我们的内部 AI 系统。它处于 goose 等开源项目的核心，证明开放标准全面推动创新。我们很高兴看到协议和 AI 代理的演进，在企业中释放更高的生产力。”

✦ Dhanji Prasanna，首席技术官，Block

“拥有一个开放源代码协议来释放真正的互操作性，使代理真正有用。在一年时间里，Foundry 从一小部分工具发展到数千个，因为 MCP 让来自 GitHub、Azure 和 M365 的工具在代理运行的任何地方显示出来。它使一次编写到处集成成为现实，并赋予代理在任何系统和任何云上工作的能力，并拥有 Microsoft 的全部支持。”

✦ Asha Sharma，总裁，CoreAI，Microsoft

“MCP 已成为 AI 集成的自然语言——连接从模型发现到推理 API 到聊天应用程序的所有内容。社区使用 Gradio 和我们的 HF-MCP 服务器创建了数千个 MCP 应用程序。拥有一个开放源代码协议来释放这种无缝互操作性，在过去一年中已经改变了游戏规则。”

✦ Julien Chaumond，首席技术官，Hugging Face

“企业 AI 的承诺正在通过 MCP 在以前孤立的系统中统一数据、工具和工作流程的能力来实现。随着代理 AI 更快地被采用，我们很高兴看到身份和授权位于安全框架的核心。通过正式将跨应用访问作为 MCP 授权扩展，组织可以拥有必要的监督和访问控制，以构建安全和开放的 AI 生态系统。”

✦ Harish Peri，高级副总裁兼总经理，AI 安全，Okta

“我们从已接受 MCP 作为将生成式 AI 代理与外部系统连接的标准的客户那里听到了好消息。开放源代码对我们的 AWS 使命非常重要，这就是为什么我们开始并继续为 MCP 做出贡献——在授权、人在环交互和异步执行方面进行改进。我们还将 MCP 构建到 Amazon Bedrock、Kiro、Strands、AgentCore 和 Amazon Quick Suite 等产品中。我们很高兴继续与这个社区合作，使代理互操作性对开发人员来说无缝衔接。”

✦ Swami Sivasubramanian，副总裁，代理 AI，AWS

“在短短一年时间里，模型上下文协议已被证明是连接模型与数据和应用程序的关键标准，解决了阻碍代理发展的碎片化问题。我们很自豪能在 Gemini 上支持 MCP，从我们的模型到 Gemini CLI 等代理软件开发工具，以及提供 Google Maps 和 Google Cloud 数据库的开源 MCP 服务器。这些正是我们自己团队使用的工具，我们很高兴通过继续构建这一基础来庆祝 MCP 的第一个生日。”_

✦ Anna Berenberg，工程研究员，Google Cloud

“MCP 为我们 Obot AI 改变了一切。一个标准的开放协议，用于将 AI 与应用程序、数据和系统连接，这是自 LLM 以来最大的转变。我们全力投入安全的 MCP 管理，因为我们相信它将成为每个组织的基础设施”

✦ Shannon Williams，总裁兼联合创始人，Obot AI；组织者，MCP 开发者峰会

当然，我们不得不提到协调 MCP 社区参与所需的巨大努力。我们向我们最多产的一些社区经理询问了 MCP 对他们意味着什么。这是他们的故事。

“作为社区版主和维护者，我不断回到 Donella Meadows 写的一段话：“系统无法被控制，但它们可以被设计和重新设计……我们可以倾听系统告诉我们的东西，并发现其属性和我们的价值观如何协同工作，带来比我们的意愿所能产生的更好的东西。”_

使这一年的增长成为可能的是拥抱混乱作为一种特性，并尽力解决从这种混乱中出现的实际问题，同时为系统和模型的进步和适应留出空间。这种宽松性创造了速度，我在大量的讨论、PR 和问题中看到了这种速度的展开。

作为跨 MCP 存储库合并数百个拉取请求的人，我仍然觉得我勉强跟上了这个速度。我是以最积极的方式这样说的。更好的模式和做法正从大量的贡献以及贡献者社区所代表的经验和专业知识的广度中出现。作为互联网上的一个陌生人，我很感激几乎任何人都可以做出贡献。这包括杰出的维护者，如 Cliff Hall，他提高了审查、测试和给予反馈的标准，以及 Jonathan Hefner，他对文档也做了同样的事情。

正如 Darren Shepard 最近所说：

‘人们认为 MCP 的价值在于协议。价值在于让人们同意并做某事。’_

MCP 给了人们协调和讨论同一件事的理由。帮助实现这种协调和讨论一直很有趣，这也是我一直回来的原因。”_

✦ Ola Hungerford，首席工程师，Nordstrom；MCP 维护者和社区负责人

“在过去一年里，看着 MCP 社区从小到大成长是一种乐趣。无论一个人是独立贡献者、小创业公司的成员，还是大企业的领导者：每个人都有并且继续有发言权和角色要扮演。”_

我认为这主要是因为 MCP 社区从一开始就非常务实和以用例为导向。重点是不过度设计规范，不超前于需求进行设计。当这种理念推动决策时，每个人的声音都很重要。在生产环境中工作的业余爱好者可能会提出实用的意见，大型科技工程师可以将其自信地部署到大量用户中。反之亦然：大型科技公司可以预见安全等关键问题，而业余爱好者可能在设计中忽略了这些问题。"_

这种理念也转化为社区治理。没有官僚主义层级：只是一个轻量级的、仍然分散的决策结构，让我们所有人都按照相同的鼓点行进。我们现在有 58 位维护者 支持 MCP 指导小组中的 9 位核心/首席维护者，Discord 上的 MCP 贡献者社区中有 2,900 多名贡献者，每周有 100 多名新贡献者 加入。我们成功地维护了注册表、Inspector 和一系列 SDK 等长期项目，拥有这个分散的领导者和贡献者群体——并在大约一个季度的时间内成功协作完成了 17（！）个 SEP。"_

这甚至还没有触及数千名 MCP 实施者或数百万 MCP 最终用户。看到经常竞争的 AI 社区围绕一个基础的基础设施聚集在一起，这是令人鼓舞的；我很感激这种合作的意愿，并期待看到我们的第二年将带我们走向何方。"_

✦ Tadas Antanavicius，联合创作者，PulseMCP；MCP 维护者和社区负责人

我们非常感谢我们的合作伙伴和社区帮助我们将协议发展到今天的位置。现在让我们跳进最新的重大发布——MCP 规范的 2025-11-25 版本。

2025年11月发布

MCP 规范的最新发布包含了许多高度预期的功能，这些功能直接来自将 MCP 用于生产场景的社区。人们告诉我们什么不起作用、什么缺失以及哪些小问题阻止他们使用 MCP。我们听取了意见，并与社区专家合作，提供了许多增强功能，使 MCP 更加可扩展和可靠。

支持基于任务的工作流程

SEP： 1686

任务为 MCP 提供了一个新的抽象，用于跟踪 MCP 服务器正在执行的工作。任何请求都可以通过任务进行增强，允许客户端在任务创建后的服务器定义期限内查询其状态并检索其结果。

任务支持多种状态，包括 working、input_required、completed、failed 和 cancelled，允许客户端有效地管理多步骤操作。

此功能启用的一些值得注意的能力：

主动轮询：客户端可以随时检查正在进行的工作的状态。
结果检索：已完成任务的结果在请求完成后可访问。
灵活的生命周期管理：支持 working、input_required、completed、failed 和 cancelled 状态。
任务隔离：具有基于会话的访问控制的适当安全边界。

从我们看到的众多 MCP 服务器来看，这对于以下场景特别有帮助：

处理数十万个数据点的医疗保健和生命科学数据分析
具有复杂多步骤工作流程的企业自动化平台
运行数分钟或数小时的代码迁移工具
需要从长时间运行的测试套件中流式传输日志的测试执行平台
在内部生成多个代理的深度研究工具
代理可以并发工作的多代理系统

任务正在作为一项实验性功能推出，这意味着它是核心协议的一部分，但尚未最终确定。基于任务的工作流程是一个难以大规模解决的问题，因此我们希望给规范一些时间在现实场景中进行实战测试。我们将与社区、SDK 开发人员以及客户端和服务器实施者密切合作，以确保正确性。

简化的授权流程

社区在授权方面的首要痛点之一是动态客户端注册（DCR）。需要此功能是因为在 MCP 世界中有无限数量的客户端和服务器，因此标准的客户端预注册并不总是可行的。你不能指望世界上每个 MCP 客户端也与每个授权服务器（AS）都有客户端注册，因此 DCR 被用作解决此问题的方案。你可以在我们的授权指南中了解更多关于当前方法的信息。

然而，要使用 DCR，MCP 服务器开发人员需要依赖一个 AS，该 AS 允许客户端通过公共 API 自行注册。如果 AS 不支持此功能，开发人员现在需要构建一个 OAuth 代理，该代理将手动注册到 AS，并支持动态客户端注册本身，将其自己颁发的令牌映射到下游 AS 颁发的令牌。这是一项复杂、耗时且容易出错的任务，并不能真正解决动态客户端注册的根本问题。

另一种选择是让每个客户或最终用户提供 他们自己的 客户端注册，但这只是用一个复杂任务交换另一个复杂任务。在该模型中，当用户连接到 MCP 服务器时，他们需要通过 IT 团队创建注册，为其分配正确的权限，然后配置 MCP 客户端以使用它。

SEP-991 为此问题引入了一个更优雅的解决方案——使用 OAuth 客户端 ID 元数据文档的基于 URL 的客户端注册（你可能已经看到我们今年早些时候关于此更改的博客文章）。客户端现在可以提供自己的客户端 ID，该 ID 是一个指向客户端管理的 JSON 文档的 URL，该文档描述了客户端的属性。

你可以在 MCP 授权规范的客户端 ID 元数据文档流程部分了解更多信息。

安全和企业功能

随着协议的成熟，我们也不能忽视众多的安全和身份验证/授权需求。MCP 不仅仅是一个业余爱好协议——我们看到它被一些最关键的工作负载采用。这意味着直接需要确保所有数据都受到保护，访问得到适当管理。

与来自整个社区的安全和身份验证专家合作，我们开发了此版本附带的许多增强功能：

SEP-1024：本地服务器安装的客户端安全要求
SEP-835：授权规范中的默认范围定义

我们还从行业清楚地听到，内部注册表的发现和管理是 MCP 故事的重要组成部分。在 MCP 注册表团队的帮助下，我们还建立了生态系统愿景，这将帮助企业采用 他们自己的 MCP 注册表，具有自我管理的治理控制和安全覆盖。

要了解有关其他即将到来的授权和安全改进的更多信息，你可以关注规范存储库中的 auth 和 security 标签。

扩展

随着 MCP 的不断发展，我们不断听到希望用特定功能扩展协议的开发人员的声音，无论是用于 UI 交互、自定义授权流程还是其他环境特定的逻辑。虽然这些添加可能很有价值，但直接将它们纳入核心规范并不总是从一开始就实用的，特别是当功能尚未达到广泛采用或证明其普遍适用性时。

为了解决这个问题，我们在协议中引入了扩展。扩展是在核心规范之外运行的组件和约定，提供了一种灵活的方式来构建遵循 MCP 约定的场景特定添加，而无需完全集成协议。这种方法允许进行实验和专业化用例，同时保持核心协议的专注和稳定。通过扩展，我们可以更快地移动，并使开发人员能够在功能成为规范的一部分之前测试协议功能。

扩展具有以下特点：

可选性。服务器和客户端实施者可以选择采用这些扩展。
添加性。扩展不会修改或破坏核心协议功能；它们添加新功能，同时保持核心协议行为。
可组合性。扩展是模块化的，设计为无冲突地协同工作，允许实施同时采用多个扩展。
独立版本控制。扩展遵循核心 MCP 版本控制周期，但可以根据需要采用独立版本控制。

你可能已经看到我们关于 MCP 应用扩展提案的公告。在此规范版本中，我们引入了其他几个应该进一步帮助开发人员的扩展。

授权扩展

为了使 MCP 更适合需要对授权流程进行特定级别控制的环境，我们正式引入了授权扩展的概念（建立在更广泛的 MCP 扩展之上）。与所有其他扩展一样，授权扩展建立在核心协议之上，定义了可由服务器和客户端开发人员实施的其他授权机制。

前两个授权扩展是在社区反馈之后推出的，涉及一些最常用的授权流程：

SEP-1046：用于机器对机器授权的 OAuth 客户端凭据支持
SEP-990：MCP OAuth 流程的企业 IdP 策略控制（跨应用访问）。这使用户能够在企业内登录 MCP 客户端一次，并立即获得对每个授权 MCP 服务器的访问，而无需额外的授权提示。

随着我们与社区更紧密地接触，我们预计授权扩展的数量也会增长——毕竟，系统获取和管理凭据的方法不止几种。

URL 模式引导：安全的带外交互

SEP： 1036

直接通过 MCP 客户端向用户询问他们的 API 密钥、令牌或任何其他凭据可能看起来相当可怕。当你需要将 MCP 服务器连接到其他 API 数组时，这尤其关键，因为传统的客户端到服务器授权流程并不完全适用。直到现在，没有一个好的替代方案——你要么必须信任客户端直接处理用户的凭据，要么实现一堆自定义授权逻辑从头开始使用。

URL 模式引导让你可以在用户的浏览器中将他们发送到适当的 OAuth 流程（或任何凭据获取流程），在那里他们可以安全地进行身份验证，而你的客户端永远不会看到输入的凭据。凭据然后直接由服务器管理，客户端只需要担心自己对服务器的授权流程。

我们很高兴除了我们已有的功能（如引导）之外还包括这个功能，因为它允许协议用于一些很难正确完成的场景，例如：

安全凭据收集：API 密钥和密码从不通过 MCP 客户端传输
外部 OAuth 流程：MCP 服务器有一条途径获得第三方授权，而无需令牌传递
支付处理：现在可以在客户端之外使用具有安全浏览器上下文的 PCI 合规金融交易

服务器所做的只是提供一个 URL，客户端将为该 URL 提供便利。当用户在浏览器中完成流程时，服务器将直接获得必要的令牌，避免与客户端共享凭据或其他手动步骤。简单！

使用工具的采样：代理服务器

SEP： 1577

此功能允许 MCP 服务器使用客户端的令牌运行自己的代理循环（当然仍在用户的控制下），并降低客户端实现的复杂性，上下文支持变得显式可选。这是由于采样不支持工具调用，尽管它是现代代理行为的基石。随着新的规范发布，这不再是一个差距！

既然可以使用工具进行采样，这也意味着以下所有场景都是可能的！

采样请求中的工具调用：服务器现在可以包含工具定义并指定工具选择行为
服务器端代理循环：服务器可以实现复杂的多步推理
并行工具调用：支持并发工具执行
更好的上下文控制：模糊的 includeContext 参数被软弃用，取而代之的是显式功能声明

例如，研究服务器可以在内部生成多个代理，协调它们的工作，并使用标准的 MCP 原语交付一致的结果，而无需自定义脚手架或复杂的编排代码。

开发体验改进

MCP 的核心原则之一是 简单性——我们要使开发和集成体验尽可能直观和容易。为了帮助实现这一点，最新的规范版本还添加了一些小的更改，有助于使协议对开发人员来说更容易使用。

SEP-986：工具名称的标准化格式
SEP-1319：从 RPC 方法定义中解耦请求负载
SEP-1699：通过服务器端断开进行 SSE 轮询，以更好地管理连接
SEP-1309：改进 SDK 的规范版本管理

展望未来

此版本向后兼容。你现有的实现继续工作。当你需要新功能时，它们就在那里。

展望未来，我们对 MCP 的下一步感到兴奋。协议正在进入一个新阶段，不仅将 LLM 连接到数据，而且启用全新的 AI 驱动应用程序类别。

我们已经看到了这种转变的早期信号。开发人员正在构建跨数十个 MCP 服务器协调的多代理系统。企业团队正在大规模部署 MCP，具有复杂的安全和治理控制。初创公司正在推出以 MCP 为核心架构模式的产品。MCP 服务器甚至被转换为可执行代码，以创建沙盒化的代理工作流程。

前面的路线图包括在可靠性和可观察性方面的更深入工作，使调试和监控复杂的 MCP 部署变得更容易。我们正在探索更好的服务器组合模式，允许你通过组合更简单的构建块来构建复杂的功能。我们继续完善安全模型，以满足最苛刻的企业环境的需求。

最让我们兴奋的不是我们计划构建什么，而是 我们的社区 将构建什么。每周我们都会看到以新颖方式设计、开发和部署的 MCP 服务器。Discord 中的每一次对话都会揭示新的用例和模式。协议已成为 AI 创新的画布，我们无法独自填充它。

下一年的 MCP 将受到更多生产部署、更多真实世界反馈的影响，并由全球数千名开发人员的创造力放大。我们在这里支持这种增长，确保协议有思想地演进，并随着规模扩大保持 MCP 的稳定、安全和简单。

入门

要开始使用最新 MCP 规范发布中的所有新功能，请查看以下资源：

阅读更新日志：所有主要变更都在我们的关键变更文档中捕获
了解我们的文档：MCP 文档是协议所有内部运作的真实来源
加入讨论：如果你想做出贡献或与其他 MCP 维护者互动，请从我们的 GitHub 存储库和 Discord开始

采用 MCP Bundle 格式 (.mcpb) 实现便携式本地服务器

Fri, 21 Nov 2025 00:00:00 +0000

MCP Bundle 格式 (MCPB) 现已纳入 Model Context Protocol 项目。这种分发格式简化了开发者打包和共享本地 MCP 服务器的方式，使用户能够在任何兼容的客户端中安装，包括 Claude 桌面应用、Claude Code 和 MCP for Windows。

什么是 MCP Bundles？

MCP Bundles 是包含本地 MCP 服务器和 manifest.json 的 ZIP 归档文件，该文件描述了服务器及其功能。该格式类似于 Chrome 扩展 (.crx) 或 VS Code 扩展 (.vsix)，使最终用户能够一键安装本地 MCP 服务器。

基本的 Bundle 结构如下：

bundle.mcpb (ZIP file)
├── manifest.json # Required: Bundle metadata and configuration
├── server/ # Server implementation
│ └── index.js
├── node_modules/ # Bundled dependencies
└── icon.png # Optional: Bundle icon

该格式支持用 Node.js、Python 或编译二进制文件编写的服务器，为开发者提供了构建集成的灵活性，同时为用户保持了一致的分发机制。

为什么将 MCPB 迁移到 MCP 项目？

Anthropic 最初为 Claude 的桌面应用开发了 MCPB（以前称为 DXT）。然而，我们认为当可移植性扩展到任何单一客户端之外时，本地 MCP 服务器生态系统会受益。通过将 Bundle 规范、CLI 工具和参考实现移至 MCP 项目，我们实现了：

跨客户端兼容性

为一个 MCP 兼容应用创建的 Bundle 应该在任何其他实现规范的应用中工作。开发者可以分发一次他们的工作，并在整个生态系统中接触用户。

生态系统级工具

mcpb CLI 和相关库现在开放给社区扩展、改进和构建。客户端开发者可以采用标准化代码来加载和验证 Bundle。

用户友好的安装

无论用户喜欢哪种 AI 应用，最终用户都能从一致的安装体验中受益。配置变量、权限和更新可以统一处理。

共享社区

MCPB 贡献者现在可以在 MCP 社区的开放环境中与 MCP 社区的其他成员协作。

对开发者的影响

这种过渡主要是后勤变更，但也为实现者带来了一些好处。

服务器开发者

您可以使用 MCPB 为多个客户端打包和分发您的本地 MCP 服务器。mcpb CLI 帮助您创建 manifest.json 并将服务器打包成 .mcpb 文件。

客户端开发者

您可以使用开源工具链为您的应用添加 MCP Bundles 支持。该仓库包含 Claude 用于 macOS 和 Windows 的模式及关键函数，您可以将其调整用于自己的客户端。

快速开始

访问仓库开始使用：modelcontextprotocol/mcpb。我们欢迎反馈和贡献！

Bundle Manifest 示例

{
 "name": "my-mcp-server",
 "version": "1.0.0",
 "description": "我的 MCP 服务器",
 "author": "开发者名称",
 "license": "MIT",
 "mcp": {
 "version": "1.0.0",
 "capabilities": {
 "resources": {},
 "tools": {}
 }
 },
 "entrypoint": "server/index.js",
 "icon": "icon.png",
 "variables": [
 {
 "name": "API_KEY",
 "description": "API 密钥",
 "required": true,
 "secret": true
 }
 ]
}

使用 CLI 打包

# 安装 CLI
npm install -g @modelcontextprotocol/mcpb

# 创建新的 Bundle 项目
mcpb init my-server

# 构建 Bundle
mcpb build

# 验证 Bundle
mcpb validate my-server.mcpb

# 安装 Bundle（在支持 MCPB 的客户端中）
mcpb install my-server.mcpb

资源

MCPB 规范: MANIFEST.md
CLI 文档: CLI.md
示例: examples 目录
仓库: github.com/modelcontextprotocol/mcpb

致谢

感谢参与此事的 MCP 贡献者和维护者：

David Soria Parra (MCP 首席维护者)
Adam Jones (MCP 维护者)
Joan Xie (MCPB 维护者)
Felix Rieseberg (MCPB 维护者)
Alex Sklar (MCPB 维护者)

Server Instructions：为 LLM 提供服务器的使用手册

Mon, 03 Nov 2025 00:00:00 +0000

我们许多人仍在探索 MCP 的各个角落，学习如何最好地使用协议的构建块来增强智能体和应用程序。有些功能，如 Prompts，在 MCP 生态系统中经常被实现和使用。其他功能可能看起来有些晦涩，但对智能体与 MCP 服务器交互的能力有很大影响。Server instructions 属于后者。

问题背景

想象您是一个大语言模型（LLM），刚刚收到了来自数据库服务器、文件系统服务器和通知服务器的工具集合来完成一个任务。它们可能已经被仔细预选，或者可能更像车库工作台上的样子——一堆最近使用的工具。

现在假设数据库服务器的开发者对如何最好地使用他们的工具有先验知识或偏好，以及有关驱动它们的基础系统的更多背景信息。

一些示例包括：

“始终使用 validate_schema → create_backup → migrate_schema 进行安全的数据库迁移”
“使用 export_data 工具时，需要文件系统服务器的 write_file 工具来存储本地副本”
“数据库连接工具限制为每分钟 10 个请求”
“如果 create_backup 失败，在尝试发送警报之前检查通知服务器是否已连接”
“仅在支持启发式询问时使用 request_preferences 来询问用户设置。否则，回退到使用默认配置”

现在我们的问题变成了：分享这些上下文知识的最有效方式是什么？

解决方案

一种解决方案可能是在服务器提供的每个工具描述或提示中包含额外信息。然而，回到物理工具的类比：只有足够的空间来描述它们时，您才能依赖"标记"每个工具。模型的上下文窗口是有限的——您只能将那么多信息放入该空间。

或者，依赖提示来提供通用指令意味着：

提示总是需要由用户选择，并且
指令更容易在其他消息的混乱中丢失。

这就是 server instructions 的用武之地。Server instructions 为服务器提供了一种注入 LLM 应始终阅读的信息的方式，以了解如何使用服务器——独立于各个提示、工具或消息。

实现差异说明

因为服务器指令可能会被注入到系统提示中，所以应该谨慎和勤奋地编写它们。没有指令比糟糕的指令更好。

此外，MCP 宿主使用服务器指令的确切方式取决于实现者，因此不能保证它们总是被注入到系统提示中。

真实示例：优化 GitHub PR 审查

我使用官方 GitHub MCP 服务器测试了服务器指令，看看它们是否能改进模型处理复杂工作流的方式。

问题：详细的 Pull Request 审查

我认为指令可能有帮助的一个常见用例是要求 LLM “审查 pull request #123”。如果没有更多指导，模型可能会决定过度简化并使用 create_and_submit_pull_request_review 工具在单个注释中添加所有审查反馈。

解决方案：工作流感知指令

我在 GitHub MCP 服务器中测试的一个解决方案是基于启用的工具集添加指令：

func GenerateInstructions(enabledToolsets []string) string {
 var instructions []string

 // 通用上下文管理 - 始终存在
 baseInstruction := "GitHub API 响应可能会溢出上下文窗口。策略：1) 始终尽可能优先使用 'search_*' 工具而非 'list_*' 工具，2) 分批处理 5-10 项的大数据集，3) 对于摘要任务，首先获取最少数据，然后深入具体细节。"

 // 仅加载已启用工具集的指令
 if contains(enabledToolsets, "pull_requests") {
 instructions = append(instructions, "PR 审查工作流：对于具有特定行注释的复杂审查，始终使用 'create_pending_pull_request_review' → 'add_comment_to_pending_review' → 'submit_pending_pull_request_review'。")
 }

 return strings.Join(append([]string{baseInstruction}, instructions...), " ")
}

衡量有效性：定量结果

对于此会话样本，我得到以下结果：

模型	有指令	无指令	改善
GPT-5-Mini	8/10 (80%)	2/10 (20%)	+60%
Claude Sonnet-4	9/10 (90%)	10/10 (100%)	N/A
总体	17/20 (85%)	12/20 (60%)	+25%

这些结果表明，虽然有些模型自然地倾向于最佳模式，但其他模型从明确指导中受益匪浅。

实施服务器指令：给服务器开发者的一般建议

良好指令的一个关键是关注工具和资源没有传达的内容：

1. 捕获跨功能关系

{
 "instructions": "在任何 'fetch_*' 工具之前始终调用 'authenticate'。'cache_clear' 工具会使所有 'fetch_*' 结果无效。"
}

2. 记录操作模式

{
 "instructions": "为了获得最佳性能：1) 对多个项目使用 'batch_fetch'，2) 在批量操作之前检查 'rate_limit_status'，3) 结果缓存 5 分钟。"
}

3. 指定约束和限制

{
 "instructions": "文件操作限制在工作区目录。超过 10MB 的二进制文件将被拒绝。速率限制：所有工具每分钟 100 个请求。"
}

4. 编写模型无关的指令

保持指令的事实性和功能性，而不是假设特定的模型行为。

应避免的反模式

不要重复工具描述：

// 坏 - 重复了 tool.description 中的内容
"instructions": "搜索工具搜索文件。读取工具读取文件。"

// 好 - 添加关系上下文
"instructions": "在 'read' 之前使用 'search' 来验证文件路径。搜索结果在 10 分钟后过期。"

不要包含营销或优越性声明：

// 坏
"instructions": "这是满足您所有需求的最佳服务器！优于其他服务器！"

// 好
"instructions": "专用于 Python AST 分析。不适合二进制文件处理。"

不要写手册：

// 坏 - 太长和太详细
"instructions": "此服务器提供...的全面功能 [500 字]"

// 好 - 简洁和可操作
"instructions": "GitHub 集成服务器。工作流：1) 'auth_github'，2) 'list_repos'，3) 'clone_repo'。"

服务器指令不能做的事情

保证特定行为：与您给 LLM 的任何文本一样，您的指令不会总是以相同的方式被遵循
考虑次优工具设计：工具描述仍然会在 LLM 需要采取行动时决定它们如何使用您的服务器的成败
改变模型个性或行为：服务器指令用于解释您的工具，而不是用于修改模型通常如何响应或行为

给客户端实现者的说明

如果您正在构建支持服务器指令的 MCP 客户端，我们建议您向用户公开指令，并提供关于服务器向上下文注入内容的透明度。

当前支持的宿主应用程序

有关支持服务器指令的宿主应用程序的完整列表，请参阅 MCP 文档中的客户端页面。

有关服务器指令的实际演示，您可以使用 Everything 参考服务器。

总结

清晰和可操作的服务器指令是 MCP 工具包中的关键工具，提供了一种简单而有效的方式来增强 LLM 与服务器交互的方式。我们鼓励您在我们的讨论中分享您的示例、见解和问题。

资源

MCP 文档: Server Instructions 规范
GitHub MCP 服务器: github.com/github/github-mcp-server
Everything 参考服务器: modelcontextprotocol/servers

致谢

这篇博客文章的部分内容来源于与 MCP 社区、贡献者和维护者的讨论。

Chrome DevTools MCP：让AI代码助手告别盲人摸象，实现可视化调试

Wed, 24 Sep 2025 00:00:00 +0000

2024年9月23日，Google Chrome团队发布了一个令开发者社区振奋的消息：Chrome DevTools MCP服务器正式发布公开预览版。这个基于Model Context Protocol的创新工具，让AI编程助手终于能够"看见"代码在浏览器中的真实表现，彻底改变了AI辅助开发的体验。

AI编程的"盲点"：看不见的执行效果

正如Chrome团队在官方博客中指出的：编程代理面临一个根本问题——它们无法看到生成的代码在浏览器中的实际效果，本质上是在蒙眼编程。无论是Claude、Copilot还是Cursor，都面临这个核心挑战。

传统AI编程的"盲区"现状

想象这样一个场景：你要求AI助手修复一个CSS布局问题。传统流程如下：

开发者: "修复这个按钮的对齐问题"
AI助手: "试试这个CSS代码..."
开发者: [复制粘贴 → 刷新浏览器 → 检查效果]
结果: 仍然有问题，需要多轮迭代

核心问题分析：

纯文本交互：AI只能基于代码本身进行分析和建议
无法验证效果：生成的样式、布局代码需要人工测试
性能盲区：无法分析页面加载速度、Core Web Vitals指标
调试困难：无法检查控制台错误、网络请求失败
用户体验脱节：无法模拟真实的用户交互流程

根据GitHub统计，开发者在AI生成代码后的验证和调试环节，通常要花费生成时间的3-5倍。这种"生成-测试-修改"的低效循环，严重制约了AI辅助开发的价值发挥。

Chrome DevTools MCP：AI的"眼睛"

Chrome DevTools MCP服务器的出现，为AI助手装上了一双"眼睛"。通过Model Context Protocol，AI能够：

🔍 实时验证代码效果

用户：修复这个按钮的样式问题
AI：已生成修复代码，正在浏览器中验证... ✅ 确认按钮样式已正确应用

📊 自动化性能分析

AI可以启动Chrome、打开网站、记录性能跟踪，然后分析结果并提出优化建议：

用户：这个页面加载很慢，帮我优化
AI：检测到LCP为3.2秒，主要问题是图片未压缩，建议使用WebP格式...

🐛 智能错误诊断

AI能够检查控制台日志、分析网络请求，快速定位问题根源：

用户：登录功能不工作
AI：检测到CORS错误，API请求被阻止，需要在服务器端添加跨域头...

核心功能解析

Chrome DevTools MCP提供了26个专业工具，覆盖Web开发的各个方面：

输入自动化（7个工具）

click - 点击元素
fill - 填写表单
drag - 拖拽操作
hover - 悬停交互
upload_file - 文件上传

导航控制（7个工具）

navigate_page - 页面导航
new_page - 新建标签页
wait_for - 等待元素加载

性能分析（3个工具）

performance_start_trace - 开始性能跟踪
performance_stop_trace - 停止性能跟踪
performance_analyze_insight - 分析性能数据

调试诊断（4个工具）

take_screenshot - 截图
evaluate_script - 执行JavaScript
list_console_messages - 查看控制台日志
list_network_requests - 检查网络请求

实战应用场景

Chrome官方团队提供了五大核心应用场景，每个都能显著提升开发效率：

场景1：实时代码验证

官方推荐提示词："Verify in the browser that your change works as expected."

传统流程的痛点：

1. AI生成CSS代码 → 2分钟
2. 开发者复制粘贴 → 30秒
3. 手动刷新浏览器 → 10秒
4. 检查效果，发现问题 → 1分钟
5. 重复1-4步 → 平均3-5轮
总耗时：15-25分钟

MCP增强后的流程：

// AI自动执行（总耗时：2-3分钟）
用户: "验证这个更改是否按预期工作"
AI执行:
1. 应用CSS修改 → take_screenshot() ✅
2. 检查DOM结构 → evaluate_script() ✅
3. 验证响应式效果 → resize_page() ✅
4. 最终确认："修改已成功应用，在所有断点下布局正确"

场景2：自动化性能审计

官方推荐提示词："Localhost:8080 is loading slowly. Make it load faster."

用户提示: "localhost:8080加载很慢，帮我提速"
AI自动执行完整性能分析:
1. performance_start_trace() - 开始性能跟踪
2. navigate_page("http://localhost:8080") - 访问页面
3. wait_for("networkidle") - 等待网络静止
4. performance_stop_trace() - 停止跟踪
5. performance_analyze_insight() - 深度分析
AI智能反馈:
"🔍 性能分析报告：
- LCP: 4.2秒 (目标: <2.5秒) ❌
- FID: 180ms (目标: <100ms) ❌
- CLS: 0.15 (目标: <0.1) ❌
🎯 关键问题：
- 未压缩图片占用3.2MB带宽
- 缺少关键资源预加载
- 第三方脚本阻塞渲染
💡 优化建议：
- 转换为WebP格式（减少76%大小）
- 添加 <link rel="preload"> 指令
- 使用 async/defer 加载脚本"

场景3：模拟用户行为测试

官方推荐提示词："Why does submitting the form fail after entering an email address?"

这是Chrome DevTools MCP最强大的功能之一——端到端用户流程自动化测试：

用户: "为什么提交表单后显示错误？"
AI执行完整用户流程测试:
1. navigate_page("http://localhost:8080/login") - 访问登录页
2. take_screenshot() - 记录初始状态
3. fill("input[type='email']", "test@example.com") - 填写邮箱
4. fill("input[type='password']", "password123") - 填写密码
5. click("button[type='submit']") - 点击提交
6. wait_for(2000) - 等待响应
7. list_console_messages() - 检查控制台错误
8. list_network_requests() - 分析网络请求
9. take_screenshot() - 记录结果状态
AI智能诊断:
"🔍 表单提交问题分析：
❌ 网络请求: POST /api/login → 400 Bad Request
❌ 控制台错误: 'CSRF token missing'
❌ 用户体验: 错误信息未显示
🎯 根本原因:
表单缺少CSRF防护令牌
💡 解决方案:
1. 添加隐藏字段: <input type='hidden' name='_token' value='{{ csrf_token() }}'>
2. 或使用meta标签: <meta name='csrf-token' content='{{ csrf_token() }}'>
3. AJAX请求头: 'X-CSRF-TOKEN': document.querySelector('meta[name=csrf-token]').content"

快速上手指南

1. 配置MCP客户端

在支持MCP的AI客户端中添加配置：

{
 "mcpServers": {
 "chrome-devtools": {
 "command": "npx",
 "args": ["chrome-devtools-mcp@latest"]
 }
 }
}

2. 支持的AI客户端

Chrome DevTools MCP已获得主流AI开发工具的官方支持：

Claude Desktop - Anthropic官方原生支持，配置最简单
Cursor - 提供一键安装按钮，开发者体验最佳
Cline - VS Code生态扩展，编辑器内集成
Codex - OpenAI官方工具，支持企业级部署
Copilot / VS Code - 微软官方支持，与GitHub深度集成
Gemini CLI - Google官方工具，多语言支持
Gemini Code Assist - Google云端代码助手

快速安装示例（Cursor）： 点击此按钮直接安装：

3. 首次测试

Chrome官方推荐的验证提示词：

测试提示: "Please check the LCP of web.dev."
中文版本: "请检查web.dev的LCP性能"
预期执行流程:
1. AI自动启动Chrome浏览器 🚀
2. 访问https://web.dev 🌐
3. 开始性能跟踪记录 📊
4. 分析LCP (Largest Contentful Paint) 指标 ⚡
5. 返回详细性能报告和优化建议 📝
示例输出:
"✅ web.dev 性能分析完成
- LCP: 1.2秒 (优秀，< 2.5秒)
- 主要内容: 图片hero-banner.webp
- 加载时间分布: 网络600ms + 渲染400ms + 绘制200ms
- 性能评级: 95/100"

小提示：首次运行时，MCP服务器会自动下载并启动Chrome，整个过程约需30-60秒。

技术优势分析

1. 基于成熟技术栈

Puppeteer - 提供可靠的浏览器自动化
Chrome DevTools Protocol - 直接访问浏览器调试能力
MCP标准 - 确保与各AI客户端的兼容性

2. 开放生态设计

// 可扩展的工具架构
interface MCPTool {
 name: string;
 description: string;
 inputSchema: JSONSchema;
}

// 支持自定义扩展
server.setRequestHandler("callTool", async (request) => {
 // 自定义工具逻辑
});

3. 安全隔离机制

独立的用户数据目录
可选的无头模式运行
沙箱环境支持

对开发生态的影响

1. 改变AI编程模式

从"生成-验证-修改"的循环模式，转向"生成-自动验证-智能优化"的流程。

2. 提升开发效率

减少手动测试时间
自动化性能分析
智能错误定位

3. 降低学习门槛

初学者可以通过AI助手的实时反馈，更快理解Web开发的各个环节。

总结

Chrome DevTools MCP的推出，彻底解决了AI编程助手长期存在的"视觉盲区"问题。通过赋予AI"看见"代码执行效果的能力，它将Web开发的AI辅助体验提升到了前所未有的高度。

核心价值总结：

效率革命：调试时间从小时级别降至分钟级别
质量提升：自动化性能分析和用户体验检测
门槛降低：初学者也能完成复杂的Web开发任务
生态繁荣：开放标准促进整个AI开发工具生态发展

对于开发者而言，这不仅意味着更高的开发效率，更代表着一种全新的编程范式——AI不再只是代码生成器，而是真正能够理解、验证、优化Web应用的智能伙伴。

如果你还在使用传统的AI编程助手，强烈建议试试Chrome DevTools MCP，体验一下让AI"睁开眼睛"编程的革命性感受。

🚀 立即开始

30秒快速配置：

选择支持MCP的AI客户端（推荐Cursor或Claude Desktop）
添加配置："chrome-devtools": {"command": "npx", "args": ["chrome-devtools-mcp@latest"]}
测试提示：“检查https://mcpcn.com的性能并提供优化建议”
观察AI如何自动化完成整个调试分析流程

获取更多资源：

Chrome DevTools MCP —— 让AI编程从"盲目"走向"智能"，开启Web开发新纪元。

介绍 MCP 注册表

Mon, 08 Sep 2025 00:00:00 +0000

今天，我们推出了模型上下文协议（MCP）注册表——一个用于公开可用的 MCP 服务器的开放目录和 API，以提高可发现性和实施性。通过标准化服务器的分发和发现方式，我们正在扩大它们的覆盖范围，同时使客户端更容易连接。

MCP 注册表现在以预览版提供。要开始使用：

添加你的服务器，按照我们的将服务器添加到 MCP 注册表指南（适用于服务器维护者）
访问服务器数据，按照我们的访问 MCP 注册表数据指南（适用于客户端维护者）

MCP 服务器的单一真实来源

2025年3月，我们分享了我们要为 MCP 生态系统构建中央注册表的愿望。今天我们宣布我们推出了 https://registry.modelcontextprotocol.io 作为官方 MCP 注册表。作为 MCP 项目的一部分，MCP 注册表以及父级 OpenAPI 规范都是开源的——允许每个人构建兼容的子注册表。

我们的目标是标准化服务器的分发和发现方式，提供一个子注册表可以构建的主要真实来源。反过来，这将扩大服务器的覆盖范围，并帮助客户端在 MCP 生态系统中更容易地找到服务器。

公共和私有子注册表

在构建中央注册表时，对我们来说重要的是不剥夺社区和公司已经构建的现有注册表。MCP 注册表作为公开可用的 MCP 服务器的主要真实来源，组织可以选择基于自定义条件创建子注册表。例如：

公共子注册表（如与每个 MCP 客户端相关的有观点的"MCP 市场"）可以自由增强和改进它们从上游 MCP 注册表摄取的数据。每个 MCP 最终用户角色都有不同的需求，MCP 客户端市场有责任以有观点的方式适当地为他们的最终用户服务。

私有子注册表将存在于具有严格隐私和安全要求的企业中，但 MCP 注册表为这些企业提供了可以构建的单一上游数据源。至少，我们的目标是与这些私有实施共享 API 模式，以便相关的 SDK 和工具可以在整个生态系统中共享。

在这两种情况下，MCP 注册表都是起点——它是 MCP 服务器维护者发布和维护其自我报告信息的集中位置，供这些下游消费者处理并交付给他们的最终用户。

社区驱动的审核机制

MCP 注册表是由注册表工作组维护的官方 MCP 项目，并采用宽容的许可。社区成员可以提交问题来标记违反 MCP 审核指南的服务器——例如包含垃圾邮件、恶意代码或冒充合法服务的服务器。注册表维护者随后可以将这些条目列入黑名单，并追溯地从公共访问中删除它们。

入门

要开始使用：

添加你的服务器，按照我们的将服务器添加到 MCP 注册表指南（适用于服务器维护者）
访问服务器数据，按照我们的访问 MCP 注册表数据指南（适用于客户端维护者）

MCP 注册表的此预览版旨在帮助我们在普遍可用之前改善用户体验，不提供数据持久性保证或其他保证。我们建议 MCP 采用者密切关注开发，因为在注册表普遍可用之前可能会发生重大更改。

随着我们继续开发注册表，我们鼓励在 modelcontextprotocol/registry GitHub 存储库上提供反馈和贡献：讨论、问题和拉取请求都是受欢迎的。

感谢 MCP 社区

MCP 注册表从一开始就是一项协作努力，我们非常感谢更广泛开发者社区的热情和支持。

2025年2月，它作为一个草根项目开始，当时 MCP 创建者 David Soria Parra 和 Justin Spahr-Summers 请 PulseMCP 和 Goose 团队帮助构建集中的社区注册表。PulseMCP 的注册表维护者 Tadas Antanavicius 与 Block 的 Alex Hancock 合作领导了最初的努力。他们很快得到了 GitHub 的 MCP 负责人、注册表维护者 Toby Padilla 的加入，最近，Anthropic 的 Adam Jones 作为注册表维护者加入，推动项目今天的发布。MCP 注册表开发的最初公告列出了来自至少9家不同公司的16位贡献个人。

许多其他人为将这个项目带入生活做出了关键贡献：Stacklok 的 Radoslav Dimitrov、GitHub 的 Avinash Sridhar、VS Code 的 Connor Peet、NuGet 的 Joel Verhagen、Last9 的 Preeti Dewani、Microsoft 的 Avish Porwal、Jonathan Hefner，以及许多提供代码审查和开发支持的 Anthropic 和 GitHub 员工。我们也感谢注册表的贡献者日志上的每个人以及参与讨论和问题的人。

我们深深感谢每个人投资于这个基础的开源基础设施。在一起，我们正在帮助全球的开发人员和组织构建更可靠、具有上下文感知的 AI 应用程序。代表 MCP 社区，谢谢你们。

模型上下文协议（MCP）：AI应用与外部数据集成的新标准

Sat, 01 Mar 2025 00:00:00 +0000

Claude 在 2024 年末推出的**模型上下文协议（Model Context Protocol，简称 MCP）**迅速获得了开发者和社区的广泛关注与认可。作为一名曾在过去一年中参与过多个小型 AI 项目开发的开发者，我深刻体会到将 AI 模型集成到现有系统或第三方服务中的种种困难。

MCP 的出现恰逢其时，它不仅解决了这些痛点，还带来了一个开放、标准化的生态愿景。下面，我将从开发者视角出发，结合 MCP 的工作原理和优势，分析它为何能被广泛接受。

一、AI 集成开发的痛点：为什么需要 MCP？

在 AI 项目开发中，将模型与外部系统对接往往是一大挑战。以我个人的经验为例，无论是连接本地数据库还是调用第三方 API，整个过程都充满了复杂性和不确定性。市面上虽然有一些工具和框架试图解决这个问题，但效果却不尽如人意：

LangChain 和 LlamaIndex
这两个开源项目主打"几行代码实现 AI 功能"的理念，在展示 Demo 时确实方便。然而，一旦业务需求变得复杂，它们的短板就暴露无遗：
- 代码抽象过高：高层次封装虽然降低了入门门槛，但在实际开发中，这种设计导致代码难以调试和扩展，编程体验极差。
- 生态混乱：项目过于追求商业化，忽视了社区生态的长期建设，文档和更新常常跟不上实际需求。
Vercel AI SDK
相比之下，Vercel AI SDK 的代码抽象做得更优雅，尤其在前端 UI 集成和部分 AI 功能封装上表现不错。但它的局限也很明显：
- 绑定 Next.js：与 Next.js 框架深度耦合，对其他框架或语言的支持不足，限制了适用范围。

这些工具虽然各有亮点，但都无法提供一个统一的、灵活的解决方案。开发者仍然需要在不同项目中重复造轮子，浪费大量时间和精力。

二、MCP 的推出：恰逢其时，优势突出

Claude 推出 MCP 的时机可谓恰到好处，它抓住了开发者对标准化和开放性的迫切需求。以下是 MCP 受到欢迎的几个关键原因：

1. Claude 的品牌影响力

Claude Sonnet 3.5 作为一款性能卓越的语言模型，已在开发者群体中建立了良好口碑。这种信任为 MCP 的推广奠定了基础。开发者愿意尝试一个由 Anthropic（Claude 的开发公司）背书的协议，因为他们相信 Claude 团队能持续输出高质量的技术方案。

2. 开放标准的吸引力

MCP 是一个开放协议，不绑定任何特定模型或框架。这种开放性吸引了众多公司和社区的参与。相比之下，传统的 AI 集成方案往往受限于特定平台，而 MCP 提供了一个通用的桥梁，让服务商和开发者都能从中受益：

对服务商：可以基于 MCP 开放自己的 API 和功能，融入更大的生态。
对开发者：无需从头构建集成逻辑，直接利用现成的 MCP 服务即可增强 AI Agent 的能力。

3. 解决重复造轮子的问题

MCP 的标准化设计让开发者可以复用社区贡献的资源。例如，一个支持 GitHub 操作的 MCP 服务器一旦开发完成，其他开发者就能直接调用，而无需重复实现。这种"一次开发，多次使用"的模式极大提升了效率。

三、MCP 如何工作？——从架构到实例

要理解 MCP 为何受欢迎，我们需要看看它的工作原理。MCP 的设计并不复杂，但却非常实用。它通过一个清晰的架构，将 AI 模型与外部世界连接起来。

MCP 的核心架构

MCP 分为五个主要组件：

MCP Hosts：运行 AI 模型的应用程序，例如 Claude Desktop 或 Cursor。
MCP Clients：在 Hosts 内负责与服务器通信的模块。
MCP Servers：核心部分，通过标准化协议为 Clients 提供工具、数据和上下文。
Local Data Sources：本地文件、数据库等直接可访问的数据。
Remote Services：外部 API 或服务，例如 GitHub 或 Slack。

其中，MCP Server 是整个协议的灵魂。它就像一个"中介"，告诉 AI Agent 当前有哪些可用服务和数据，AI Agent 再通过函数调用（Function Calling）执行具体任务。

从 AI Chat 到 AI Agent 的进化

MCP 的价值还体现在它推动了 AI 的自动化进程：

AI Chat：仅提供建议，用户需手动操作（例如复制粘贴）。
AI Composer：能自动修改代码，但仍需人工确认，且功能有限。
AI Agent：完全自动化，能独立完成复杂任务，例如读取 Figma 设计稿、生成代码、调试并提交到 GitHub。

MCP Server 的作用是为 AI Agent 提供支持，让它知道"能做什么"和"怎么做"。

一个简单的例子：GitHub MCP Server

假设我们要让 AI Agent 自动完成以下任务：搜索 GitHub 仓库、查找 Issues、判断是否为已知 Bug 并决定是否提交新 Issue。我们可以创建一个 GitHub MCP Server，提供以下能力：

search_repositories：搜索仓库。
search_issues：搜索 Issues。
create_issue：创建新 Issue。

代码实现如下（简化版）：

const server = new Server({ name: "github-mcp-server" });

server.setRequestHandler("listTools", async () => ({
 tools: [
 { name: "search_repositories", description: "Search GitHub repositories" },
 { name: "search_issues", description: "Search issues in repositories" },
 { name: "create_issue", description: "Create a new issue" },
 ],
}));

server.setRequestHandler("callTool", async (request) => {
 switch (request.params.name) {
 case "search_repositories":
 return await searchRepositories(request.params.arguments.query);
 case "search_issues":
 return await searchIssues(request.params.arguments);
 case "create_issue":
 return await createIssue(request.params.arguments);
 }
});

async function searchRepositories(query) {
 const url = `https://api.github.com/search/repositories?q=${query}`;
 const response = await fetch(url);
 return await response.json();
}

这个服务器通过描述工具（description）和参数需求（inputSchema），让 AI Agent 明白如何与 GitHub 交互。最终，Agent 可以根据任务需求自主调用这些功能。

四、MCP 的生态价值：更强大的 AI Agent

MCP 的真正潜力在于它能支持更复杂的 AI Agent。以一个实际场景为例：用户输入"查询本地错误日志，将相关 Issues 发送到 Slack"。AI Agent 需要：

调用 Local Log Server 读取日志。
调用 GitHub Server 搜索相关 Issues。
调用 Slack Server 发送消息。

MCP 的标准化协议让这些服务器无缝协作，AI Agent 可以根据返回结果动态决定下一步操作。这种模块化设计不仅提升了灵活性，也降低了开发成本。

五、总结：MCP 为何赢得青睐？

Claude 推出 MCP 之所以被广泛接受，归根结底在于它抓住了开发者的核心需求：

解决了痛点：简化了 AI 与外部系统的集成过程。
开放生态：通过标准化吸引了社区和企业的参与。
实用性强：从简单工具到复杂 Agent，MCP 提供了清晰的实现路径。

对于开发者而言，MCP 不仅是一个技术协议，更是一个解放生产力的工具。未来，随着更多 MCP 服务器的开发和生态的完善，它有望成为 AI 集成领域的行业标准。如果你也对 AI 开发感兴趣，不妨试试 MCP，也许它会成为你下一个项目的秘密武器！

一文读懂MCP协议：大模型AI-Agent的USB-C接口

Tue, 19 Mar 2024 15:20:00 +0800

MCP协议分层架构示意图

在AI重构传媒行业价值链的时代，内容生产、分发与用户触达的效能，正从单点效率升级为算法驱动的全局智能协同。然而，海量数据孤岛、多平台接口的烟囱式开发等瓶颈，仍在制约技术资源的AI化融合。

本文深入拆解MCP协议，从技术架构到行业场景化实践，为您揭示如何用"一次连接，全局调用"的下一代接口标准，释放传媒数据资产的真正潜能——让技术资源不再成为创意与效率的枷锁，而是驱动增长的新引擎。

【本文由@bexzhang主笔， @osli修订，来源：腾讯云智慧传媒】

一、MCP起源

背景与痛点

AI应用进入深水区后，模型与外部数据/工具的集成呈现"烟囱式开发"（每个模型需单独对接不同数据源），导致开发成本高、安全性差、扩展困难。AI 模型和已有系统集成发展缓慢，一方面是企业级的数据很敏感，大多数企业都要很长的时间和流程来动；另一个方面是缺少一个开放的、通用的、有共识的协议标准。

市面上虽然有一些框架支持 Agent 开发，例如 LangChain Tools, LlamaIndex 或者是 Vercel AI SDK，需编写大量定制代码，难以规模化。

LangChain 和 LlamaIndex 整体发展混乱，代码的抽象层次过高，在实际开发中，只要业务一旦开始复杂，糟糕的代码设计带来了非常糟糕的编程体验。项目过于追求商业化了，忽略了整体生态的建设。

Vercel AI SDK 代码抽象的比较好，但是也只是对于前端 UI 结合和部分 AI 功能的封装还不错，最大的问题是和 Nextjs 绑定太深了，对其它的框架和语言支持度不够。

诞生与目标

提出者：Anthropic公司（Claude的开发者）于2024年11月底发布并开源。https://www.anthropic.com/news/model-context-protocol

核心目标：建立类似USB-C的标准化协议，统一AI模型与外部资源的交互接口，实现"一次集成，处处运行"。解决当前 AI 模型因数据孤岛限制而无法充分发挥潜力的难题，MCP 使得 AI 应用能够安全地访问和操作本地及远程数据，为 AI 应用提供了连接万物的接口。

MCP对比图

技术演进时间线：

时间	阶段	关键事件
2023年前	原始阶段	每个AI需独立开发Function Call接口
2023年	萌芽期	LangChain等框架尝试通用化工具调用
2024年11月	协议诞生	Anthropic开源MCP 1.0版本
2025年Q1	生态爆发	GitHub出现200+第三方MCP服务器实现

二、MCP的概念和优势

MCP定义

MCP是一种开放协议，通过标准化语言和接口，实现AI模型与外部数据源/工具的无缝交互，核心功能包括：

统一翻译器：将不同数据源的API转换为模型可理解的标准化请求。
安全连接层：支持本地与远程资源访问，数据无需上传至云端。

这个协议的发布最好机会应该是属于 OpenAI 的，如果 OpenAI 刚发布 GPT 时就推动协议，相信大家都不会拒绝，但是 OpenAI 变成了 CloseAI，只发布了一个封闭的 GPTs，这种需要主导和共识的标准协议一般很难社区自发形成，一般由行业巨头来主导。

通俗类比概念

“万能遥控器"比喻

想象每个企业系统都是不同品牌的智能家电（电视、空调、音响），原本每个设备都需要专属遥控器（定制接口）。MCP就像一个预置了所有家电协议的万能遥控器：AI助手拿着这个遥控器，既能让"电视"播放监控视频（调用安防系统），也能让"空调"调节数据温度（调整服务器负载），还能让"音响"播报业务报告（触发语音合成）——所有操作都通过统一按键（标准化指令）完成，无需再为每个设备寻找专用遥控器。

“AI的USB-C接口"比喻

官方将MCP比作AI领域的USB-C接口。类比来看，不同的AI助手就像不同的电子设备，以前每个设备需要不同的数据线连不同的外设（比如老式手机数据线各不相同），而MCP提供了一个统一的细窄接口，让AI能够即插即用各种外设。例如，通过MCP，一个AI助手今天可以连U盘（数据库），明天插打印机（邮件系统），后天接显示器（报告生成）——接口都一样，只是功能不同。就像USB-C让我们少了无数转换头和线缆，MCP也让AI集成少了无数专有API和脚本。对于终端用户来说，这意味着AI助手将变得更加多才多艺且使用方便，因为背后复杂的连接都被这个看不见的"USB-C"标准屏蔽掉了。

AI的USB-C接口

MCP的优势

MCP（Model Context Protocol）是专为大语言模型（LLMs）应用设计的上下文协议，针对LLM应用中常见的数据孤岛与工具集成痛点，MCP提供以下关键能力：

生态-MCP 提供很多现成的插件， AI 可以直接使用。
统一性-不限制于特定的 AI 模型，任何支持 MCP 的模型都可以灵活切换。
数据安全-可以自行设计接口确定传输哪些数据。

MCP 与 Function Calling 的区别

MCP（Model Context Protocol），模型上下文协议	Function Calling，函数调用
这两种技术都旨在增强 AI 模型与外部数据的交互能力，但 MCP 不止可以增强 AI 模型，还可以是其他的应用系统。
MCP的"原语”（Prompts/Resources/Tools）设计支持更复杂的交互流程，而传统Function Calling仅为单向请求。
MCP并非"不限制于特定AI模型”，而是需模型支持MCP协议。Function Callling同样以来模型的特性支持。

MCP与Function Calling对比

三、MCP的核心原理和技术架构

核心架构

MCP采用客户端-服务器的分布式架构，它将 LLM 与资源之间的通信划分为三个主要部分：客户端、服务器和资源。客户端负责发送请求给 MCP 服务器，服务器则将这些请求转发给相应的资源。这种分层的设计使得 MCP 协议能够更好地控制访问权限，确保只有经过授权的用户才能访问特定的资源。官方架构图如下：

MCP核心架构

MCP Host（主机应用）：Hosts 是指 LLM 启动连接的应用程序，像Cursor、Claude、Desktop、Cline 这样的应用程序。
MCP Client（客户端）：客户端是用来在 Hosts 应用程序内维护与 Server 之间 1:1 连接。一个主机应用中可以运行多个MCP客户端，从而同时连接多个不同的服务器。
MCP Server（服务器）：独立运行的轻量程序，通过标准化的协议，为客户端提供上下文、工具和提示，是MCP服务的核心。
本地数据源：本地的文件、数据库和 API。
远程服务：外部的文件、数据库和 API。

这种架构下，AI主机通过MCP客户端同时连接多个MCP服务器，每个服务器各司其职，提供对一种数据源或应用的标准化接入。这样设计有几个好处：一是模块化，增加或移除某个数据源只需启用或停用对应的服务器，不影响AI主体或其他部分；二是解耦，AI模型与具体数据源实现隔离开，通过协议交互，不直接依赖数据源的内部细节；三是双向通信，不仅AI可以请求数据源，某些情况下数据源也能要求AI执行操作或生成内容，从而支持更复杂的交互流程。

工作流程

MCP工作流程

初始化连接：客户端向服务器发送连接请求，建立通信通道。
发送请求：客户端根据需求构建请求消息，并发送给服务器。
处理请求：服务器接收到请求后，解析请求内容，执行相应的操作（如查询数据库、读取文件等）。
返回结果：服务器将处理结果封装成响应消息，发送回客户端。
断开连接：任务完成后，客户端可以主动关闭连接或等待服务器超时关闭。

通信方式

MCP定义了一套基于JSON-RPC 2.0的消息通信协议。核心特点如下：

传输灵活：原生支持两种传输方式——进程管道的STDIO（本地场景）和SSE+HTTP POST（网络通信），同时允许开发者自定义其他传输通道。
消息透明：采用纯JSON格式封装三种消息类型——请求（带唯一ID）、响应（含结果/错误）和通知（无回复）。每条消息包含方法名和参数，类似函数调用，直观表达"执行操作/获取数据"等行为。
开发友好：相比二进制协议（如gRPC），JSON消息可人工阅读，配合结构化日志更易调试。协议层自动处理请求响应匹配、错误传递和并发管理，开发者只需关注业务逻辑。

关键机制 – “Primitives”（原语）概念：MCP将AI与外部系统交互的内容抽象为几类原语，以此规范客户端和服务器各自能提供的功能。

MCP服务器可以提供三种原语：

Prompts（提示）：预先编写的提示词或模板，相当于一段指导性文字片段，可以插入到模型的输入中去影响其行为。例如服务器可以提供一个"代码审查提示模板"，供模型在阅读代码时使用。
Resources（资源）：结构化的数据或文档内容，可供客户端读取并提供给模型作为上下文。例如从数据库查询到的一条记录、用户的笔记文档内容等，都是资源类型。资源类似于"只读文件"，模型可以请求某个资源，服务器会返回相应的数据内容。
Tools（工具）：可以被模型调用的可执行操作或函数。这是MCP最强大也最具互动性的部分，模型可以要求服务器执行某个工具函数来获取信息或改变外部状态，比如调用"发送邮件"工具发送一封邮件，调用"查询天气"工具获取天气数据等。由于工具调用可能带来副作用和安全风险，MCP规定模型调用工具必须经由用户批准后才执行。换言之，工具就像模型可用的"按键"，但每次按键需要真人确认，避免模型滥用外部操作权限。

MCP客户端提供两种原语能力用于辅助服务器完成复杂任务：

Roots（根）：这是一种由客户端提供的文件系统入口或句柄。服务器可以通过Root来访问客户端这侧的本地文件或目录内容。例如客户端可以授权服务器读取某个文件夹（作为Root），那么服务器就能代表模型浏览那个文件夹下的文件内容（通常仍以资源形式提供给模型）。Roots机制确保服务器只能访问经授权的本地数据范围，增强安全性。
Sampling（采样）：这一机制允许服务器向客户端发起请求，要求客户端这侧的LLM模型生成一段文本（即一次补全/推理）。简单说，服务器也可以"反过来"调用模型，让模型基于一些额外提示执行推理。Sampling可以用于构建多轮交互的智能Agent：服务器在执行某工具过程中，发现需要模型进一步推理决定下一步时，就可以用Sampling请求模型产出结果，再继续后续操作。不过Anthropic也强调应谨慎使用这一机制，始终保持人类在环监督，以避免AI代理失控循环调用模型。Sampling机制并非所有MCP服务器均支持，需依赖客户端实现。

通过上述原语分类，MCP清晰地定义了模型与外部交互的意图类型。例如，让模型获取一段参考资料应该作为Resource提供，而不是混同于调用Tool；又如要求模型执行某操作就用Tool明确表示。这样的设计使AI系统的上下文管理更结构化：模型知道某段信息是只读资料还是可执行操作，用户也能对不同类型请求进行针对性地审批或监控。这比起简单地给模型一个隐式"工具插件"要透明得多。Anthropic的开发者指出，他们最初也考虑过是否把所有交互都当作"工具调用"统一处理，但最终认为Prompt和Resource这两类原语有其独特意义，能表达不同用途的功能，因此保留了多元的原语概念。

四、MCP Server分类及应用

MCP Server是MCP服务的核心，主要从官方、第三方以及社区MCP Server三个角度对关注度较高的应用进行细分。

1.官方MCP Server

（由 Model Context Protocol 核心团队维护，具备标准化协议实现和最佳实践）

核心基础设施

modelcontextprotocol/server-filesystem（文件系统）：提供标准化文件访问接口，支持细粒度权限控制，基础能力标杆实现。https://github.com/modelcontextprotocol/servers/tree/main/src/filesystem

拓展工具

modelcontextprotocol/Google Drive（云端文件）：与 Google Drive 集成，允许列出、读取和搜索文件。https://github.com/modelcontextprotocol/servers/tree/main/src/gdrive

AI增强工具

modelcontextprotocol/aws-kb-retrieval-server（向量数据库）：官方向量检索方案，支持高维数据存储与相似性搜索。https://github.com/modelcontextprotocol/servers/tree/main/src/aws-kb-retrieval-server

2.第三方MCP Server

（由专业厂商/团队维护，具备行业领域深度集成能力）

数据库服务

Tinybird MCP Server（实时数据分析）：针对时序数据优化，提供低延迟 SQL 查询接口。https://github.com/tinybirdco/mcp-tinybir

云服务

Qdrant MCP Server（向量搜索云服务）：企业级向量检索云服务，支持混合搜索和分布式部署。https://github.com/qdrant/mcp-server-qdrant/

AI服务

LlamaCloud Server（大模型托管平台）：提供多模态模型调用接口，支持模型微调和推理监控。https://github.com/run-llama/mcp-server-llamacloud

开发工具服务

Neo4j（图数据库）：图数据库服务，支持Cypher查询与知识图谱构建。https://github.com/neo4j-contrib/mcp-neo4j/

拓展工具服务

Firecrawl （网页爬取）：支持抓取、爬取、搜索、提取、深入研究和批量抓取。https://github.com/mendableai/firecrawl-mcp-server?tab=readme-ov-file#firecrawl-mcp-server

3.社区MCP Server

（由开发者社区贡献，覆盖长尾需求和实验性场景）

本地工具集成

punkpeye/mcp-obsidian（知识管理工具）：支持双向同步 Obsidian 笔记库，Markdown 内容解析优化。https://github.com/punkpeye/mcp-obsidian

自动化工具

appcypher/mcp-playwright（浏览器自动化）：基于 Playwright 的网页操作自动化，支持动态 JS 执行。https://github.com/appcypher/awesome-mcp-servers#browser-automation

垂直领域工具

r-huijts/mcp-aoai-web（艺术数据访问）：可通过自然语言交互访问荷兰国立博物馆的藏品，提供艺术品元数据检索。https://github.com/r-huijts/rijksmuseum-mcp

开发者工具

sammcj/mcp-package-version（开发依赖管理）：实时查询 npm/pypi 包版本，防止幻觉版本建议。https://github.com/sammcj/mcp-package-version

隐私增强工具

hannesrudolph/mcp-ragdocs（本地文档检索）：基于本地向量库的隐私安全文档检索方案。https://github.com/hannesrudolph/mcp-ragdocs

4.分类对比

维度	官方 Servers	第三方 Servers	社区 Servers
维护周期	长期维护，版本迭代规律	依赖厂商支持周期	依赖个人开发者活跃度
协议兼容性	100% 符合最新 MCP 规范	通常支持核心规范	可能存在实验性扩展
安全审计	经过官方安全认证	部分厂商提供商业级审计	无强制审计机制
部署复杂度	提供标准化安装包和文档	需要配置厂商专用凭证	常需手动调试依赖项
典型场景	基础能力/关键业务场景	行业垂直领域深度需求	个性化/实验性需求

补充说明：远程 MCP 连接的支持

官方文档中关于传输方式的描述可能会让部分开发者误解，认为 Remote MCP Connections（远程 MCP 连接）已经实现。实际上，当前的客户端和服务端都是在本地运行的。（当前如果需要连接远程服务器，需要在客户端-服务端连接后，由本地服务端再次向远程服务器发起连接）

这一点在官方的 2025 年路线图中有所提及https://modelcontextprotocol.io/development/roadmap ：

实现 Remote MCP Connections是当前MCP项目组的最高优先级，允许客户端通过互联网安全地连接到 MCP 服务端。关键举措包括：

认证与授权 (Authentication & Authorization)：增加标准化的认证能力，特别是专注于 OAuth 2.0 支持。
服务发现 (Service Discovery)：定义客户端如何发现并连接到远程 MCP 服务器。
无状态操作 (Stateless Operations)：探讨 MCP 是否可以支持无服务器环境（serverless environments），在这种环境中，操作需要尽可能无状态。

参考文章：

[1]https://www.anthropic.com/news/model-context-protocol
[2]https://modelcontextprotocol.io/development/roadmap
[3]https://github.com/modelcontextprotocol
[4]https://mcp.so/servers
[5]https://github.com/punkpeye/awesome-mcp-servers
[6]https://github.com/appcypher/awesome-mcp-servers
[7]https://github.com/modelcontextprotocol/python-sdk
[8]https://github.com/punkpeye/awesome-mcp-servers?tab=readme-ov-file#frameworks
[9]‍https://mp.weixin.qq.com/s/Toj2TudFNXx6_Z11zSRb2g