MCP 全称 Model Context Protocol，是 Anthropic 开源的一套开放协议，解决的是一个很实际的问题：每个 Agent 都要接数据库、接内部系统、接各种 SaaS，如果每家都按自己的方式对接，生态永远碎片化。MCP 想做的就是 Agent 世界的 USB-C：统一接口，Host、Client、Server 三方各干各的。

架构上分三层。Host 是装载 Agent 的应用，比如 Claude、Cursor 这类客户端；Client 是 Host 里负责维护连接的会话；Server 是真正提供能力的服务进程，通过 stdio 或 SSE/HTTP 和 Client 通信。一个 Server 可以暴露三类东西：Tools（可执行的工具）、Resources（可读取的数据）、Prompts（提示词模板）。Agent 想查库存，调的是 Server 的 tool；想读文档，读的是 resource。

实战落地一般分四步。第一步，盘点 Agent 到底需要哪些能力，列个清单，先区分只读和写入操作。第二步，找现成的 Server 接入，社区已经有文件系统、数据库、浏览器、Git 等常用实现，能白嫖就别自己写。第三步，没有合适的再自己写，核心工作其实是把 tool 的名称、描述和参数 schema 定义清楚，逻辑本身往往不复杂。第四步，灰度上线，先给测试 Agent 用，观察调用成功率再放开。

避坑经验有几条，都是真金白银换来的。第一，tool 的描述写得越清楚，模型调用准确率越高，这是性价比最高的优化手段，值得逐字打磨。第二，敏感操作比如删数据、发邮件，必须加人工确认环节，别把 Server 的执行权限放得太宽。第三，Server 进程的稳定性和超时处理要做好，Agent 卡死十有八九是 Server 没响应，加个心跳和超时熔断。第四，权限按最小化原则开，MCP 天然适合把企业内网能力安全地暴露给 Agent，但前提是你真的去做了鉴权和审计。

建议的起步姿势：先从只读型 Server 开始，比如内部知识库检索、工单查询，这类场景风险低、见效快。跑顺了、团队对 Agent 的行为边界有体感了，再扩展到写入操作。MCP 的生态还在快速演进，接口细节可能变，但"统一工具接口"这个方向基本不会错，早点按这个思路搭，迁移成本最低。