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

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

为什么 MCP 值得关注

传统工具接入常见问题：

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

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

MCP 的核心对象

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

Tools：可调用动作（例如 search_docs、create_ticket）
Resources：可读取内容（例如配置、文档、上下文快照）
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 往往是工具层演进的关键一步。

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

MCP 的本质：工具的"USB-C 接口"

MCP 的真正价值是统一工具发现与调用协议，类似硬件领域的 USB-C：

之前每个 Agent 框架（LangChain、CrewAI、AutoGen）都有自己的 tool schema
MCP 之后，工具开发者写一次，所有兼容 MCP 的客户端都能用
这种"一次开发、多端复用"对生态形成至关重要

但 MCP 不是银弹——它解决的是"工具接入层的标准化"，不解决"工具本身的设计质量"。

服务端实现的关键技术细节

构建 MCP 服务端时，几个容易踩的坑：

Tool 描述要语义化：description 字段是模型理解 tool 的核心。写 "search docs by query" 比 "POST /search?q=" 好 10 倍
输入参数要带约束：JSON Schema 用 enum 限值，给出默认值。page_size 默认 20 而不是让模型瞎传
错误码要标准化：工具失败用结构化错误（code + message + retryable），不要抛裸异常
副作用要声明：在 tool metadata 里标注是否幂等、是否有副作用，便于审计

客户端选型的真实差异

不同客户端对 MCP 的支持深度差异很大：

客户端	MCP 支持深度	适合场景
Claude Desktop	完整	个人/小团队
Cursor	部分	IDE 工作流
Cline	完整	VS Code 用户
OpenHands	完整	复杂 Agent
自研 Agent	取决于集成	生产业务

建议先确认目标客户端的 MCP 支持程度，再决定服务端实现深度。

安全审计：被严重低估的需求

生产 MCP 服务端的安全审计必须做，常见维度：

调用者身份：每次 tool 调用必须记录 user_id / session_id / agent_id
参数审计：敏感参数（如金额、删除对象 ID）单独记录，不只记摘要
执行时间：超时上限默认 30s，超过要告警
频率限制：每个 user/agent 的 QPS 上限
数据脱敏：返回结果里的 PII 必须过滤

不做审计的 MCP 服务端上线后 3 个月内必然出安全事件。

多服务端编排的陷阱

复杂业务往往需要多个 MCP 服务端协同：

服务发现：客户端怎么知道有哪些 server 可用？常见做法是配置文件 + 服务注册中心
认证打通：不同 server 的认证方式要统一（OAuth、API Key、mTLS）
错误隔离：一个 server 挂了不能拖垮整个 Agent
超时管理：跨 server 调用总耗时上限 + 单 server 占比

实际经验：超过 5 个 MCP server 的系统，可观测性投入会显著上升。

MCP 与 Function Calling 的关系

经常被混淆的两个概念：

Function Calling：模型输出结构化调用请求（厂商特定格式）
MCP：客户端-服务端的标准通信协议

关系：MCP 服务端可以理解为"标准化的 Function Calling 提供者"。模型调 Function Calling → 客户端转发到 MCP server → MCP server 执行 → 返回结构化结果。MCP 不替代 Function Calling，而是把工具层规范化。

与 LangChain Tools 的兼容性

很多团队已有 LangChain tool 库，迁移到 MCP 的两种策略：

渐进迁移：保留 LangChain 工具，用 langchain-mcp-adapters 包桥接
彻底迁移：重写为 MCP server，长期更可控

经验：先做渐进迁移，验证业务效果后再决定是否彻底迁移。完全重写 6-12 个月项目风险太大。

真实落地时间表

一个 MCP 工具集从零到生产的典型时间：

第 1-2 周：选 2-3 个核心工具，写 server，跑通 Claude Desktop 调用
第 3-4 周：加认证、限流、审计
第 5-6 周：扩展到 IDE 客户端（Cursor / Cline）
第 7-8 周：接入生产 Agent，加入可观测性
第 9-12 周：基于真实流量优化 prompt 和 tool 设计

不要试图一次性接入所有工具和所有客户端。MVP 思路永远更稳。