我一开始以为 MCP 最大的问题是协议本身不够成熟，后来发现真正麻烦的不是“能不能连上”，而是权限、状态和失败边界到底归谁管。

这也是我现在不建议个人开发者把 MCP 当成“万能插件接口”的原因。它当然值得学，但更适合把它看成 Agent 世界里的工具接线层，而不是业务系统里的稳定扩展层。

我为什么会关注它

MCP 近一年的热度非常高，因为它确实在试图统一模型、客户端、工具之间的连接方式。tools、resources、prompts、transport 这些能力一旦开始标准化，接工具这件事就不必每个平台都重写一遍。

但规范能描述边界，不代表系统已经真正守住边界。比如 roots 更像“相关目录提示”，不是访问控制；而 sampling 这类能力又会把系统带向更复杂的 agent 行为。协议统一了，不等于责任统一了。

试下来第一个不舒服的地方

LLM -> MCP Client -> MCP Server -> 文件系统 / API / 数据库

这条链路里每一层都可能把责任往下推。客户端以为服务器会做鉴权，服务器以为客户端已经限制好了上下文，模型又会把“可调用”误解成“可安全调用”。最后系统能跑通，但你并不真的知道它什么时候会越界、重试、误写或者把错误状态带进下一轮对话。

对个人项目来说，这比 demo 失灵更麻烦。因为你往往没有完整的审计、审批、幂等和隔离体系，一个看起来很优雅的工具接口，很容易变成很难追责的动作黑箱。

真正有价值的是这部分

• 把多个外部能力统一暴露给不同模型或不同客户端；
• 把散落在 prompt 里的工具说明收敛成一个可维护接口层；
• 让工具接入具备一定可迁移性，而不是绑定单一厂商。

在这些场景里，MCP 的确有价值。它让“接工具”开始可复用、可替换、可协作，而不是永远停留在一堆 prompt 和私有 JSON schema 上。

被夸大的地方也很明显

• 它不是安全边界；
• 它不是工作流编排系统；
• 它也不是企业治理方案。

真正难的是失败补偿、审批流、速率限制、租户隔离、密钥轮换、审计日志。MCP 没有义务替你解决这些，它只是把接线方式统一了一点。

如果我是个人开发者，会怎么做

• 先挑一个最窄的只读场景验证，比如查文档、查工单、查数据库；
• 先做日志、超时、权限拦截，再谈多工具编排；
• 不要一上来给写权限，更不要直接连生产系统。

我的判断是：MCP 值得重度关注，但不值得被神化。它更像一层基础协议，而不是一张能自动解决 Agent 工程问题的万能卡。