MCP 协议实战：给 Agent 接上可扩展工具生态

在很多 Agent 项目里，真正复杂的并不是 Prompt，而是“如何让模型稳定地调用外部工具”。MCP（Model Context Protocol）提供了一套更标准的接口层，帮助我们把工具接入从一次性开发，升级为可维护的能力体系。

为什么 MCP 值得关注

传统工具接入常见问题：

• 每个 Agent 框架都有自己的 tool schema
• 工具描述、鉴权和权限边界难统一
• 升级模型或框架时，工具层要重复改造

MCP 的价值在于把“工具能力”抽象为标准化服务端接口，客户端（IDE、Agent、助手）通过统一协议发现并调用能力。

MCP 的核心对象

一个典型 MCP 服务端通常包含：

1. Tools：可调用动作（例如 search_docs、create_ticket）
2. Resources：可读取内容（例如配置、文档、上下文快照）
3. Prompts：可复用提示模板（可参数化）

对 Agent 来说，Tools 是执行动作，Resources 是上下文供给，Prompts 是高层任务模板。

服务端设计建议

1. 以业务能力建模，不以 API 端点建模

推荐：create_incident, query_order_status

不推荐：post_v1_incident, get_order_by_id_raw

这样更容易让模型理解工具语义，也方便后续替换底层实现。

2. 输入 schema 要“窄而明确”

• 参数尽量用枚举与约束
• 时间范围、分页大小设置默认值
• 返回结构稳定，避免随意字段漂移

3. 工具必须可观测

至少记录：

• 请求发起方
• 工具名
• 输入摘要（脱敏）
• 执行耗时
• 返回状态

如果配合 Langfuse 或 Phoenix，这部分能显著降低排障成本。

权限与安全边界

MCP 服务端千万不要默认“全权限”。建议采用三层控制：

• 能力白名单：客户端仅可见允许的 tools
• 参数级校验：敏感字段强制规则（如工单等级）
• 执行审计：关键动作可回放、可追责

对于写操作（删除、发布、转账），务必增加人工确认或二次授权环节。

在 Agent 架构中的位置

推荐把 MCP 放在 Agent 与业务系统之间：

• Agent 负责计划与决策
• MCP 服务端负责能力编排与边界控制
• 业务系统保持原有 API，不暴露给模型

这种分层可以把“模型不稳定性”隔离在可控范围内。

总结

MCP 并不是让 Agent 更“聪明”，而是让系统更“工程化”。

当你的项目进入多人协作、跨团队复用或合规审计阶段，MCP 往往是工具层演进的关键一步。

---

建议从一个高价值工具开始试点，例如“内部文档检索”或“工单创建”，跑通后再逐步扩展工具矩阵。