MCP 进入「写一次、处处跑」阶段：流式工具结果 + 结构化发现成标配

MCP 的装机量今年跨过了 9700 万次，试验期算是结束了——它已经是 Agent 工具层的基础设施。更关键的是能力收敛：Claude Code、Cursor、Codex 现在都成了 MCP-native，你为其中一个写的工具，另外两家直接能用。

几个今年落地的能力值得一人公司注意：

流式工具结果。 长任务（搜索、跑测试、查库）可以把进度一条条推回来，而不是干等最后一颗「完成」的炸弹。做代码执行、批量检索这类活时，体验差很多。
结构化工具发现。 客户端能在运行时向 MCP server 要完整工具清单（描述、输入 schema、能力标签），不用再把工具列表硬写进提示词。
传输无关 + OAuth 委托。 HTTP / stdio / WebSocket 同一套代码通吃；OAuth 2.0 进了规范，server 自己能发起授权，调用方不用关心你的鉴权提供方。

对你最直接的杠杆是：把一个 MCP server 当成 npm 包来想——小、可组合、有版本。你给自家业务封的几个动作（查订单、发通知、读数据库），写成一个 capability server，Claude Code 里能用、Cursor 里能用、你自己的脚本里也能用，一次投入三处复用。

要泼的冷水：

生态里包的质量参差，registry（mcp.run）上不是每个都靠谱，引入前先读源码、限权限。
别把 MCP server 写成「现有 API 的薄壳」。正确姿势是写 capability server——理解你业务域、暴露高层动作，而不是把 create_issue / update_issue / close_issue 平铺出去。让工具自己决定调哪个底层 API，模型的职责是「说意图」，不是「编排 API 舞步」。
「处处跑」不等于「该处处跑」。工具只有一两个且不变时，直接写个函数让 Agent 调更省事，上 MCP 是给自己加一层。

我的建议：如果你已经或准备让 Agent 接手一部分业务操作，现在就把这些操作沉淀成 MCP server，而不是散落的脚本。复利不在某一次快，在于以后每个客户端、每个 Agent 都能直接复用。