MCP：让 AI 稳定连接外部工具

MCP 解决的不是“模型更聪明”的问题

大模型本身并不缺生成能力，真正限制它进入工作流的，往往是工具连接方式。

过去接一个外部系统，通常要为不同 AI 应用各写一套适配逻辑：读文件一套、查数据库一套、调内部 API 又是一套。随着工具数量增加，集成成本会迅速失控。

MCP（Model Context Protocol）要解决的是这一层问题：让 AI 应用和外部系统之间有一套统一的通信接口。

---

基本结构：Host、Client、Server

MCP 可以理解成一个客户端-服务器协议，但它不是让模型直接访问一切资源，而是通过明确的边界来组织能力。

AI 应用（Host）
  ↓
MCP Client
  ↓
MCP Server
  ↓
文件、数据库、API、业务系统

• Host：用户实际使用的 AI 应用，例如编辑器、桌面助手或 Agent 平台。
• Client：Host 内部负责连接 MCP Server 的组件。
• Server：把某个外部系统包装成标准能力，供 AI 调用。

一个 Host 可以连接多个 Server。比如同时连接文件系统、GitHub、数据库和内部搜索服务。

class MCPClient:
    def __init__(self):
        self.servers = []

    async def call_tool(self, server_name, tool_name, params):
        server = self.get_server(server_name)
        return await server.execute(tool_name, params)

---

三类核心能力

MCP Server 通常暴露三类东西：

能力	作用	例子
Resources	可读取的上下文数据	文件内容、数据库记录、文档页面
Tools	可执行操作	搜索、写入、发请求、创建任务
Prompts	可复用提示模板	代码审查模板、报告生成模板

这三类能力的边界很重要。Resource 更像“可读上下文”，Tool 则意味着“可能改变外部状态”。在真实项目里，权限、确认机制和日志记录通常应该优先围绕 Tool 设计。

---

一个最小开发示例

如果已有一个搜索 API，可以把它包装成 MCP Tool：

from mcp.server import Server

app = Server("my-api")

@app.tool()
async def search(query: str) -> str:
    return await my_api.search(query)

这段代码的重点不在“50 行接入一个服务”，而在于：AI 应用不需要理解 my_api 的内部实现，只需要知道这个 Server 提供了一个名为 search 的工具，以及它需要哪些参数、返回什么结果。

当多个工具都用同一套协议描述能力时，上层应用才能稳定地发现、调用和编排它们。

---

为什么它适合 Agent 工作流

Agent 不只是聊天，它需要持续读取上下文、调用工具、观察结果，再决定下一步。没有统一协议时，每个工具都像一个单独的插件；有了 MCP，工具更像一组可组合的能力。

典型场景包括：

• 读取项目文件，结合代码库上下文回答问题。
• 查询数据库，再把结果写入报告。
• 调用 GitHub、Slack、Notion 等系统完成跨平台流程。
• 把公司内部 API 包装成受控工具，让 AI 在权限范围内使用。

MCP 的价值不在于让模型“自动做所有事”，而是让工具调用变得可声明、可审计、可替换。

---

使用时要注意的边界

MCP 很适合做连接层，但不应该把所有复杂性都推给协议本身。

1. 权限要细分
   读文件、写文件、删除文件不是同一类权限。Tool 的设计越粗，风险越高。

2. 危险操作要确认
   发送邮件、改数据库、删除资源等操作，最好保留人工确认或明确的策略门槛。

3. 返回结果要可解释
   Tool 不应该只返回一段难以解析的文本。结构化结果更利于模型继续推理，也更方便记录日志。

4. 不要把 MCP 当业务系统
   MCP Server 是适配层，不是领域逻辑本身。复杂规则仍应留在稳定的后端服务里。

---

生态现状

MCP 生态已经覆盖不少常见场景：

• 数据库：PostgreSQL、MongoDB、Redis。
• 文件与代码：本地文件系统、GitHub、GitLab。
• 协作工具：Slack、Notion、Google Drive。
• API 集成：Stripe、浏览器自动化、内部搜索。

这些 Server 的质量差异很大。真正用于生产前，仍然需要检查权限模型、错误处理、日志记录和部署方式。

---

我的判断

MCP 的意义类似早期 API 标准化：它不直接决定应用体验，但会影响工具生态的连接成本。

对个人开发者，它能减少重复集成；对团队，它提供了一种把内部系统开放给 AI 使用的方式；对 Agent 平台，它则是工具发现和调用的基础设施。

不过，MCP 不是万能接口。它解决“怎么连接”，不解决“该不该执行”。后者仍然需要产品策略、权限设计和人工审核机制。