使用 MCP 和 Claude API 进行构建

本次讨论聚焦于模型上下文协议（MCP）及其与Claude API的集成应用。与会人员包括Anthropic的Claude关系负责人Alex、API团队工程师Michael以及模型上下文协议团队的John。在讨论开始前，Michael透露其日常工作中的状态更新等内容已完全由Claude生成，不再需要手动撰写。此次会议旨在深入探讨MCP的定义、起源、当前发展状态及其在实际开发和应用中的最佳实践。

模型上下文协议（MCP）被定义为一种向模型提供外部上下文的方法。通常情况下，模型只能访问对话历史作为其上下文，这适用于解决问题或文本生成等任务。然而，当Claude需要执行超出其内置能力范围的操作时，例如访问互联网或与旅行社交互以预订航班，MCP便发挥了关键作用，使模型能够代表用户在外部世界中采取行动。

MCP的一个恰当比喻是充当应用程序与模型之间的通用连接器。这意味着MCP提供了一种统一的方式，将Claude与所有其他可能需要的工具、数据源或服务进行连接。这种标准化接口的建立，确保了模型能够顺畅地接入外部资源，极大地扩展了其功能范围和实用性。

构建MCP的初衷在于应对工具使用能力不断增强的趋势。随着Claude能力的提升，团队注意到在不同的应用环境中，例如在编码编辑器中的助手和Claude.ai服务中，都需要实现相同或相似的外部工具能力，例如网络搜索功能。为了避免这种重复劳动，团队决定创建一种统一的协议，实现一次功能开发即可在所有地方配置使用。

与当时许多公司采取的集成路径不同，Anthropic选择了将MCP开源。这种做法的驱动力在于开放标准能够吸引更广泛的网络，允许工程师、公司和个人围绕该协议构建生态系统。如果只构建Claude专用的连接器，企业如Asana等需要在集成时分别实现Claude、OpenAI、Grok和Gemini的连接器，这将造成极大的管理负担。

模型能够访问外部上下文，对每个人都有益处，这就像是‘潮水上涨，所有船只都会上升’（a rising tide floats all boats）的情况。

MCP开源后迅速获得了极高的普及度，表明市场对这种标准化需求巨大。该协议经历了爆炸性的增长，被认为是历史上增长最快的开源协议之一。目前，工作重点已从Anthropic内部项目转向将其发展为一个行业定义的标准生态系统，并与所有其他提供商合作，确保MCP的长期持久性。

在MCP的发展历程中，远程MCP支持的发布是一个关键的“顿悟时刻”。早期的协议设计要求用户必须自行运行所有内容，这阻碍了像Asana这样的MCP服务器提供商托管自己的服务器供外部快速访问，使得初始设置过程非常笨拙。远程托管支持的引入，极大地简化了流程，使用户能够相对快速地入门。

在注册表或外部发现的一些独特MCP中，Context7受到了高度关注。大型语言模型的一个主要限制是其知识截止日期通常滞后数月，这使得软件开发者在处理最新软件包时面临困难。Context7解决了这个问题，它负责从Next.js网站或API网站等来源拉取文档，并保持实时更新，只需配置一次MCP连接，Claude就能获取最新信息。

对于软件开发者而言，Playwright作为一个MCP服务器非常实用，它允许Claude像真实用户一样与浏览器进行交互和点击。虽然Claude可以读取CSS和HTML，但无法实际查看网页。安装Playwright MCP服务器后，Claude可以加载网页，检查对齐问题或提出改进建议，这涉及实际加载浏览器并进行远程驱动操作。

开发者可以使用标准的MCP SDK安装并自行设置连接循环来处理与MCP服务器的连接。然而，Anthropic最近在API中直接发布了MCP连接器功能作为原生特性。此功能允许开发者仅指定远程MCP的位置（例如mcp.github.com）并提供授权信息，API将接管工具执行和结果反馈给模型的整个调用循环。

许多开发者反馈称，由于现在无需处理来回传递，他们能够删除大量的代码。

向开发者提供的核心建议是，MCP服务器和工具从根本上来说就是提示。因此，在编写AI驱动的应用程序时，必须对定义MCP服务器时使用的语言保持精确和谨慎。这包括恰当地定义工具名称、提供清晰的描述，并赋予参数适当的名称，因为所有这些都会影响模型与MCP服务器交互时的行为。

以图像生成服务器为例，如果工具描述仅包含“Description: cute puppy”，模型会生成相对基础的提示。但如果描述中明确指出“This tool calls the XXX diffusion model, version Y, and should be prompted in this style for best results”，Claude会利用其关于如何与此类系统交互的信息，生成更详细的扩散模型提示，从而获得显著更优的结果。这种细微的语言调整与日常知识工作中优化提示的效果相同。

上下文管理是LLM面临的巨大挑战之一，一个常见的反模式是向MCP服务器或API请求中塞入过多的工具或MCP服务器。这不仅因为每次添加都会生成额外的Token而变得昂贵，还会使模型感到困惑。例如，如果同时连接Linear和Asana的任务管理MCP服务器，两者都可能有“获取项目状态”工具，模型无法隐式判断应使用哪一个。

工具数量并非没有限制，它受限于模型的上下文窗口大小，因为每个服务器都会消耗一定的函数定义Token。虽然连接大量服务器可能在技术上可行，但如果无法为Claude提供与当前任务相关的工具子集，决策质量就会下降。因此，设计时应尽量保持工具的区分度，并确保它们符合人体工程学，使用起来感觉自然。

Michael发现MCP一个主要的个人用例是利用Anthropic作为信息高速公路，整合来自Slack、文档和代码库的碎片化信息。他习惯于在Claude AR或Claude Code中设置MCP服务器连接到这些位置，然后要求Claude根据过去一周的信息，并使用过去撰写的状态更新格式，生成新的项目状态报告，其成功率远超预期。

John则在家庭硬件方面进行了探索性应用。他在家庭网络上运行MCP服务器来控制家庭设备。这使得他可以在与Claude的对话中询问诸如“今天早上我出门时门锁上了吗？”之类的问题。Claude可以查询状态并提供锁定操作的建议，这种能力让人感觉像是对未来世界的预览。

MCP服务器的加入带来了一种“魔力感”，因为它们会产生添加它们时可能未曾预料到的“涌现”特性。一个早期的例子是构建了一个知识图谱服务器，该服务器仅包含“创建记忆”和“连接记忆到其他记忆”两个工具，接口极其简单。

当这个知识图谱服务器连接到Claude后，模型会进入一种“调查记者模式”。例如，当用户提到会弹钢琴，并喜欢拉赫玛尼诺夫时，Claude会记录下“用户具有复杂的古典音乐品味”并标记其精通乐器。这种深度关联的形成仅仅是由于提供了微小的结构化输入，这展示了协议的强大之处。

当这些东西都连接在一起时，存在一种模糊的中间地带，再加上Claude的通用智能，有趣的事情就会发生。

从协议的角度来看，MCP的最终成功标志着它应该在幕后运行，用户在使用任何应用程序时都不应察觉到它的存在。MCP应该只是将所有内容粘合在一起，模型只需获得所需的“手臂和腿”即可。然而，围绕MCP本身产生的热度一直非常引人注目。

目前，许多人已经认识到MCP的价值并开始构建服务器，但在将MCP服务器视为提示方面，仍处于非常早期的阶段。未来令人兴奋的一点是，MCP服务器的质量将开始成为评估供应商的一个衡量标准。例如，如果一个日志分析供应商设计了一个出色的MCP服务器，为Claude提供了与其服务交互所需的工具，这将成为一个巨大的卖点，因为工程师可以依赖该功能而无需自行构建。