MCP 解释：AI 工具如何连接到真实系统

Source: Dev.to

引言

大多数 AI 工具最初都是孤立的聊天窗口。你在其中粘贴提示，复制答案出来，并希望模型拥有足够的上下文。那种模型的可扩展性很差。现代 AI 代理需要访问工具、文件、API 和结构化上下文。模型上下文协议（MCP）旨在解决这个问题。

什么是 MCP？

MCP 是一种将 AI 应用程序连接到外部工具和数据源的协议。它不要求每个 AI 应用自行发明插件系统，而是定义了一种共享的方式，让工具向模型公开功能。

核心理念

有趣的地方不仅仅是“模型可以调用 API”（这已经实现了一段时间）。有趣的地方在于 标准化。如果没有共享协议，每一次集成都必须单独搭建桥梁：

• AI 客户端 A → 自定义 GitHub 集成
• AI 客户端 B → 不同的 GitHub 集成
• AI 客户端 C → 再另一个 GitHub 集成

使用 MCP，结构会更简洁：

AI client → MCP server → tool or data source

MCP 的工作原理

MCP 服务器可以提供以下能力：

• 数据库查询
• 文件访问
• 议题跟踪器数据
• 浏览器自动化
• 内部文档搜索
• 定制业务工具

AI 客户端通过通用接口发现并调用这些工具。模型 不需要了解内部 API 的每个细节，只需知道：

• 有这样一个工具
• 该工具的功能是什么
• 它接受哪些参数
• 它返回何种结果

这种分离使得工具访问更易于审查、测试和限制。

使用场景

好的 MCP 使用场景通常是上下文密集型的：

• “汇总本次发布的未解决缺陷。”
• “查找与此 Jira 任务相关的 Pull Request。”
• “检查此 API 路径是否有文档。”
• “根据已合并的提交生成草稿更新日志。”
• “在回答前查阅我们的内部政策。”

在所有这些例子中，模型只有在能够获取正确上下文时才有用。

安全考虑

MCP 还会创建一个新的安全边界。工具服务器可能会暴露敏感数据或操作，因此团队需要把它当作基础设施来对待，而不是把它当作无害的提示助手。

最低安全检查清单

• 哪些工具被公开？
• 哪些操作是只读的？
• 哪些操作会改变状态？
• 凭证如何存储？
• 模型是否可以访问生产数据？
• 工具调用如何记录？

该协议让集成更容易，但它 不 使治理变得可选。

何时采用 MCP

不要仅因为流行就构建 MCP 集成。只有在同一个工具或数据源需要供多个 AI 客户端或工作流使用时才考虑采用。

采纳的良好信号

• 该集成会被复用。
• 数据源足够重要，需要进行控制。
• 工具行为应被记录或测试。
• 团队希望拥有一个维护好的集成，而不是多个临时脚本。

如果只是一次性实验，小脚本可能已经足够。

结论

MCP 有价值，因为它为 AI 工具提供了一种更稳健的方式来与团队已经使用的系统交互。最大的价值不在于新颖，而在于将上下文和工具访问明确化，以便于维护。

参考文献

• 本文基于 KIberblick 上的德文原文。