MCP 真正开始难用的地方，不是接协议，而是授权、状态和界面

去年很多人讨论 MCP，还停留在“终于有统一协议了”这个阶段。到了现在，我对它的感受已经变了：协议本身当然重要，但真正开始决定项目能不能落地的，已经不是 JSON-RPC 长什么样，而是授权怎么做、状态怎么保存、界面怎么呈现、服务器怎么治理。

这也是我为什么觉得 MCP 现在值得写深一点。因为它已经从“开发者社区里一个挺酷的协议”开始进入更现实的工程阶段。2025 年末的官方规范已经把 HTTP 传输上的 authorization 单独拉出来定义，2026 年 MCP 路线图又继续强调 transport scalability、governance、agent communication 和 enterprise readiness，甚至连 MCP Apps 这种 UI 扩展都出来了。协议还在长，但真正的难点已经不再是“怎么接上”，而是“接上以后，系统会不会越来越难维护”。

我为什么会重新看 MCP

我原本以为 MCP 最大的价值是“给工具接入做了个 USB-C”。这个说法没错，但太乐观了。USB-C 的前提是电压、协议、设备权限和用户体验已经被消费电子行业打磨了很多年。MCP 现在还远没有到这个成熟度。

你今天把两个 MCP server 接进一个 agent，最先感受到的往往不是标准化带来的轻松，而是新的复杂度：谁来发 token、工具结果怎么缓存、断线后怎么恢复、哪个返回结果该给 UI 展示、哪个只该给模型、哪个服务器值得长期挂载、哪个只是临时调试用。

第一个坑：授权不是配个 API Key 就结束了

MCP 2025-11-25 规范已经把 HTTP transport authorization 独立成一套说明，这本身就说明问题了：一旦 MCP 从本地 stdio 扩展到远程 server，授权不再是“让模型能调用工具”这么简单，而是“让客户端代表资源拥有者安全地访问受限服务器”。这和你在本地跑一个 demo server 完全不是一个难度级别。

{
  "server": "https://mcp.example.com",
  "transport": "http",
  "auth": {
    "type": "oauth2",
    "resource": "billing-api",
    "scopes": ["invoices.read", "customers.read"]
  }
}

上面这类配置看起来没什么，但一旦进入真实业务，问题会立刻冒出来：token 在哪里刷新？权限是按用户还是按 agent 进程授予？同一个 agent 连 5 个 server 时，失败重试会不会把授权状态搞乱？这些都不是协议能自动替你解决的。

第二个坑：上下文和状态会慢慢失控

MCP 最容易被忽略的一点，是它不只是“工具目录”，它还会改变 agent 的上下文结构。工具一多，server 一多，中间结果一多，模型上下文很容易被工具 schema、调用日志和返回结果吞掉。Anthropic 在 2025 年写过 context engineering，也专门写过 code execution with MCP，本质都在回答一个问题：工具接得越多，怎么避免上下文窗口被工具本身吃掉。

所以很多团队后面会发现，真正需要设计的不是“要接哪些 MCP server”，而是：

哪些工具定义需要提前加载，哪些按需加载；
哪些结果要保存在会话状态里，哪些只留外部引用；
哪些调用应该被压缩成摘要，哪些必须保留原文；
失败重试时，状态是否可恢复。

这一步如果不做，MCP 越接越多，agent 往往不是更强，而是更慢、更贵、更容易乱。

第三个坑：光有工具不够，界面也要标准化

很多人一提 MCP，脑子里还是“模型调工具返回文本”。但 MCP Apps 已经把另一个现实摆到了台面上：很多工具调用的结果，文本根本不够。表单、图表、设计画布、视频播放器、审批面板，这些都更适合用 UI 而不是纯文字承载。

这意味着 MCP 正在从“工具接入协议”延伸到“交互承载协议”。一旦走到这一步，问题就更现实了：UI 生命周期由谁管理？组件能不能跨宿主复用？安全沙箱怎么做？模型返回 UI 时，宿主是否信任这个界面？这又是一层新的工程账。

被夸大的地方也很明显

这几年标准协议很容易被讲成银弹，好像“统一标准出现了，生态自然就繁荣了”。我不太认同。MCP 当然重要，但它解决的主要是接口层标准化，不会自动解决下面这些问题：

工具质量参差不齐；
权限模型不一致；
返回结果不稳定；
多 server 之间的冲突；
团队内部到底谁来维护这些 server。

对小团队来说，最危险的不是没有标准，而是太早把一堆质量一般的 server 接进主流程，最后把系统复杂度堆到一个谁都不想接手的程度。

个人开发者现在该怎么用

如果我是个人开发者，我不会一上来就追求“接满工具生态”。我会先把 MCP 当成一个受控扩展层，只接两到三个真正高频的能力，比如本地文件、一个数据库、一个代码执行环境。先验证两个问题：

它有没有比原本直接写脚本更省维护；
它有没有让 agent 的上下文和权限更可控，而不是更不可控。

半天时间内最值得做的验证，不是把 server 数量拉满，而是故意制造一次失败：断 token、让一个 server 超时、给一个工具返回超大结果，看看你的宿主和 agent 会不会立刻乱套。能扛住这个，才说明工程上有一点基础。

我的判断

MCP 现在值得重度关注，但关注重点应该从“它是不是下一个标准接口”转向“它能不能支撑真实系统复杂度”。协议已经有价值了，真正决定上限的是授权、状态管理、工具治理和 UI 承载。对个人开发者和小团队来说，现在最好的策略不是全面押注，而是小范围接入、强约束验证、优先挑高频能力。别把“接上了”误以为“可用了”，更别把“可演示”误以为“可维护”。

参考来源类型：MCP 官方规范与路线图（specification、authorization、2026 roadmap、MCP Apps），Anthropic 工程文章（effective context engineering、code execution with MCP、writing tools for agents）。