MCP 协议入门：让大模型安全地连接你的业务系统

每个做大模型应用的团队都重复造过同一个轮子：让模型调用内部系统，就得为每个系统写一套自定义工具描述、鉴权逻辑与错误处理。工具一多，维护成本指数上升。MCP（Model Context Protocol）的出现，就是为了把这件事标准化。

MCP 解决什么问题

在 MCP 之前，模型与外部世界的连接是「多对多」的乱局：N 个 AI 应用 × M 个业务系统，需要 N×M 套集成代码。MCP 把它变成「多对一」：业务系统实现一次 MCP Server，所有兼容 MCP 的 AI 应用都能直接使用。

• 对工具开发者：写一个 Server，被所有主流 AI 应用（编辑器、Agent 框架、聊天客户端）识别。
• 对应用开发者：接入统一协议，不再为每个数据源写私有适配。
• 对企业：AI 能力访问公司系统有了标准化的审计与权限边界。

架构三要素

MCP 采用客户端-服务器架构，核心概念有三个：

1. Tools（工具）：模型可以调用的操作，如「创建工单」「查询库存」。每个工具带 JSON Schema 描述参数。
2. Resources（资源）：可供模型读取的数据，如文件、数据库记录，用 URI 标识。
3. Prompts（提示模板）：Server 侧预置的标准化任务模板，保证常用操作的一致性。

传输层支持本地 stdio（进程间通信）与远程 HTTP+SSE 两种模式——前者适合本地开发工具（如编辑器插件），后者适合企业集中部署。

给业务系统接入的路线图

第一步：梳理能力面。列出希望 AI 操作的动作清单，按读写风险分级：只读（查询、检索）、低风险写（创建草稿）、高风险写（审批、支付、删除）。只读部分直接暴露，高风险部分必须挂人工确认。

第二步：实现最小 Server。官方 SDK（TypeScript/Python/Java/Go）覆盖主流语言，一个只读查询 Server 通常 200 行以内。先做 3-5 个最高频的工具，不要贪多。

第三步：鉴权与审计。生产环境必须走 OAuth 2.1 授权流程，每个会话绑定用户身份，操作日志落库——「AI 替我操作」在审计上必须等价于「我本人操作」。

第四步：评测与灰度。构造 30-50 条真实任务评测集，验证工具描述让模型的调用准确率达标（建议 ≥90%）后再放量。

常见的坑

• 工具描述含糊：模型选错工具的根因九成在描述写得不清。用「什么时候用我/什么时候不用我」的句式写 description。
• 返回数据过大：一次查询返回 10 万字会撑爆上下文。Server 侧做分页与摘要，或提供「先看结构再看内容」的二级工具。
• 状态假设：HTTP 请求之间不要假设会话状态，把上下文全部放进参数——无状态设计在分布式部署下才不会翻车。

MCP 之于 AI 应用，接近 USB 之于外设：标准统一之后，创新的重心会从「连接」转向「能力」本身。现在把自己的核心系统 MCP 化，是在为下一波 Agent 生态提前占位。