ARC 已支持 MCP 2026-07-28 规范
ARC 对 MCP（Model Context Protocol）的支持不是新事。本地 daemon、arc mcp 桥接、以及把 AFS 工具面暴露给模型，这条路我们已经走了一段时间。
这次发布要说的是：我们已把 MCP 面升级到与 2026-07-28 规范一致的部署与认证模型。 跑在 ARC 上的 Blocklet 可以按新规范方式被第三方 Agent 发现和调用；Claude Code、Codex 等客户端已在本地、staging 与生产路径上实测直连通过。
MCP 是什么
MCP 是一套开放约定，让模型通过统一的工具与数据接口去碰外部系统，而不是为每个产品各写一套对接。Agent 会发现工具、发起调用，就能用同一套方式连不同的服务。
对我们而言，MCP 一直是 Agent 摸到 AFS / Blocklet 能力的协议面之一，不是临时加的演示接口。
2026-07-28 新规范改了什么
2026 年 7 月 28 日发布的 MCP 修订，把重点放到更容易在边缘和线上部署：
- 传输更偏无状态：减少对长生命周期 session / 握手状态的依赖，请求-响应形状更适合多实例与重启。
- 认证走标准 OAuth 方向：受保护资源可声明授权服务器，客户端按元数据自己完成发现与协商，而不是各家私有的粘贴 token 流程。
行业里多家运行时与网关也在按这条线更新自己的 MCP 面。旧实现「能连」不等于已经按新规范部署；差别在无状态与标准授权发现是否齐。
我们如何对齐新规范
在已有 MCP 能力之上，本次升级主要落地这些与 2026-07-28 一致的部分：
- 无状态 streamable HTTP：生产与本地路径统一为无状态
/mcp。服务端不依赖长生命周期 session 才能继续对话；进程重启对客户端不再表现为「未初始化」。 - 标准授权发现：写操作走受保护资源元数据（例如
/.well-known/oauth-protected-resource）与 Bearer 路径。客户端可以自己完成「发现 → 注册 → 用户点授权 → 拿凭证」，不必先手工粘贴密钥。公开读仍可匿名；写 / 删 / 执行需要授权。 - 机器可读发现面：每个已部署 Blocklet 提供
/.well-known/mcp.json一类描述，配合/mcp端点，方便 Agent 只拿一个主机名就开始协商。 - 直连优先：第三方 code agent 已实测可直连线上 Blocklet，不再依赖「必须先开 CLI SSE 桥」。本地只认 stdio 的客户端仍可用
arc mcp作兼容桥接。
验收侧：Claude Code 与 Codex CLI 在本地 / staging / 生产跑通；线上抽样 Blocklet 的 MCP 面可用。完整探针记录在内部工程跟踪中收口。
怎么用
发现某个站点的 MCP 入口：
https://<your-blocklet-host>/.well-known/mcp.json
https://<your-blocklet-host>/mcp示例（ARC 托管的站点实例）：
https://new.arcblock.io/.well-known/mcp.json
https://new.arcblock.io/mcp在支持 streamable HTTP 的客户端里，把上述 MCP URL 配成远程服务器即可。本地 daemon：
arc mcp已知限制
- 不是每一个 MCP 客户端行为都一样。 Claude Code / Codex 会先尝试匿名读，被拒再走授权；部分客户端看到支持 OAuth 会直接要求先授权，公开只读路径对它们可能表现为「连不上」。这类差异记在客户端策略侧，我们不会为迁就某一家而隐藏认证发现。
- Claude Desktop 图形界面里的一次确认点击仍要人在本机完成；命令行侧的连接路径已通。
- 个别内部调用路径（例如 provider 挂载时的 elicitation）仍按既有实现运行，会随官方 SDK 能力继续收束；这不影响上述无状态传输与标准授权发现的对外能力。
相关链接
- MCP 2026-07-28 修订说明：https://blog.modelcontextprotocol.io/posts/2026-07-28/
- Model Context Protocol：https://modelcontextprotocol.io/
- 示例发现面：https://new.arcblock.io/.well-known/mcp.json
- arc mcp 文档
- MCP 词条