MCP 集成:外部能力即工具

MCP 集成:外部能力即工具

本节摘要:MCP(Model Context Protocol)是让 Grok Build 获得外部能力的最重要机制。它的核心思想是:把外部能力(数据库查询、API 调用、内部工具)封装成「MCP 服务器」,Grok Build 作为客户端连接它,服务器提供的工具就被自动纳入 Grok Build 的工具注册表——与内置工具同构。本节会讲清 MCP 在 Grok Build 里的角色、三种传输方式(stdio/http/sse)、grok mcp 子命令、MCP 工具的命名与生命周期,以及「MCP 工具即工具」这个统一设计。理解 MCP,你就掌握了让 Agent 能力无限扩展的关键。

一、MCP 是什么

Model Context Protocol(MCP) 是一个把「外部能力」标准化为「工具/资源/提示」的客户端-服务器协议。可以把它理解成「AI 工具的 USB 标准」——只要某个能力按 MCP 标准暴露成服务器,任何 MCP 客户端(包括 Grok Build)都能接入使用。

MCP 解决的问题

在没有 MCP 之前,要让一个 AI 工具接入外部能力(如查 Sentry 工单、操作 GitHub、查数据库),通常要:

• 在 AI 工具的代码里写专门的集成
• 每个外部能力一个集成,代码膨胀
• 不同 AI 工具各自集成,无法复用

MCP 把这件事标准化:外部能力实现成 MCP 服务器(用任何语言),AI 工具作为 MCP 客户端连接,能力自动可用。一次实现,处处可用。

MCP 的三类暴露

一个 MCP 服务器可以暴露三类东西:

• Tools(工具):可调用的函数,如「查工单」「创建 issue」——这是 Grok Build 主要消费的
• Resources(资源):可读取的数据,如一份文档、一个配置
• Prompts(提示):可复用的 prompt 模板

Grok Build 主要把 MCP 的 Tools 接入自己的工具系统。Resources 与 Prompts 的支持程度以实际版本为准。

二、Grok Build 如何集成 MCP

Grok Build 的 MCP 集成在 xai-grok-mcp crate。它做的事情可以概括为:

1. 读取 MCP 配置(用户配置了哪些 MCP server)
2. 按配置连接每个 server(用对应的传输方式)
3. 查询 server 提供哪些工具
4. 把这些工具包装成实现 ToolDyn 的对象
5. 注册到工具注册表,命名空间为 MCP
6. 模型可以像调用内置工具一样调用它们
​

关键的「统一」

回顾第 5 章,MCP 工具注册后,与内置工具完全同构:

• 都实现 ToolDyn
• 都在工具注册表里
• 都出现在每轮请求的工具列表里
• 都走同样的鉴权管线与执行流程
• 都产生 ToolStream(Progress + Terminal)

这种「MCP 工具即工具」的统一,是 Grok Build 工具系统设计的优雅之处——MCP 不是「特殊机制」,它只是「工具的另一种来源」。从模型的角度看,调用 GrokBuild:read_file 与调用 MCP:sentry__get_issue 没有区别。

关键概念:MCP 的价值在于「解耦能力提供者与能力消费者」。能力提供者(任何个人或厂商)按 MCP 标准实现服务器,能力消费者(Grok Build 及其他 AI 工具)只要支持 MCP 就能用。这种解耦让 AI 工具的能力可以无限扩展,无需自己写集成。

三、三种传输方式

MCP 服务器与客户端之间的通信,需要一种「传输方式」。Grok Build 支持三种:

stdio(标准输入输出)

最常用的传输。Grok Build 以子进程方式拉起 MCP 服务器,通过它的 stdin/stdout 收发 JSON-RPC 消息。

工作方式:

Grok Build 父进程
    │
    ├── 派生子进程:MCP 服务器(如 sentry-mcp)
    │
    ├── 写子进程 stdin:{"method": "tools/list", ...}
    │
    └── 读子进程 stdout:{"result": {"tools": [...]}}
​

特点:

• 简单:服务器是个可执行程序,配置里写命令行即可
• 本地:服务器与 Grok Build 在同一台机器
• 生命周期由 Grok Build 管:Grok Build 启动时拉起,退出时关闭
• 适合:本地工具、命令行工具、内部工具

典型配置(在 config 或 grok mcp add):

命令形式:grok mcp add sentry -- sentry-mcp --token <TOKEN>
配置形式:
    [mcp_servers.sentry]
    command = "sentry-mcp"
    args = ["--token", "<TOKEN>"]
    env = {}
​

http(streamable HTTP)

通过 HTTP 与 MCP 服务器通信。服务器是一个 HTTP 端点,Grok Build 向它发请求,接收流式响应。

工作方式:

Grok Build
    │
    ├── POST https://mcp.example.com/mcp
    │   body: {"method": "tools/list", ...}
    │
    └── 接收流式响应(SSE 或 chunked)
​

特点:

• 可远程:服务器可以在任何能 HTTP 访问的地方
• 可共享:一个服务器可以被多个客户端使用
• 支持 OAuth:HTTP 传输可以配 OAuth 等认证
• 适合:托管服务、团队共享、SaaS 集成

注意:Grok Build 的「http」传输底层用的是 rmcp 的 StreamableHttpClientTransport,它在语义上已经覆盖了传统 SSE 的用途。

sse(Server-Sent Events)

通过 SSE 与服务器通信。在 Grok Build 的 CLI 层面,sse 是 http 的一个别名——实现上都落到 streamable HTTP 客户端。提供这个选项主要是为了与某些只支持 SSE 的旧版服务器兼容。

没有独立的 websocket 传输

需要说明:Grok Build 的 MCP 不提供独立的 websocket 传输。http/sse 已经覆盖了相关用途。如果有 websocket 形式的 MCP 服务器,通常通过 http 传输接入(取决于服务器实现)。

四、grok mcp 子命令

Grok Build 提供了 grok mcp 子命令管理 MCP 服务器配置(在 xai-grok-pager/src/mcp_cmd.rs):

grok mcp list                       # 列出已配置的 MCP server
grok mcp add <name> [-- <cmd>]      # 添加一个 server
grok mcp remove <name>              # 移除一个 server
grok mcp doctor                     # 诊断 MCP 连通性与凭证
​

add 的典型用法:

# stdio 服务器(命令形式)
grok mcp add xcode -- xcrun mcpbridge

# http 服务器
grok mcp add --transport http sentry https://mcp.sentry.dev/mcp

# 带环境变量
grok mcp add github -- gh mcp-server --token $GITHUB_TOKEN
​

作用域(scope)

add 时可以指定作用域:

• User:写到用户级配置(~/.grok/config.toml),所有项目可用
• Project:写到项目级配置(项目根的 .mcp.json 或类似),仅当前项目可用

这让你可以区分「全局工具」(如 GitHub,处处都用)与「项目工具」(如某个项目专属的内部 API)。

doctor 的价值

grok mcp doctor 是排错利器——它会检查每个配置的 server 能否连通、凭证是否有效、提供哪些工具。MCP 出问题时(模型说「我找不到这个工具」),第一步就是跑 doctor 看哪个 server 没连上。

五、MCP 工具的命名

MCP 工具的命名遵循 server__tool 的形式(双下划线分隔),整体在 MCP 命名空间下:

MCP:sentry__get_issue
     └─┬──┘ └──┬───┘
       │       └── server 里定义的工具名
       └── server 名(在 grok mcp add 时指定)
​

命名规则:

• server 名与 tool 名各自符合正则 ^[a-zA-Z_][a-zA-Z0-9_-]{0,63}$
• 用双下划线 __ 连接(MCP_TOOL_NAME_DELIMITER)
• 跨 server 唯一性靠 server 前缀保证

为什么用双下划线:因为 tool 名本身可能含单下划线(如 get_issue),用双下划线分隔避免歧义。

六、MCP 服务器的生命周期

一个 MCP 服务器在 Grok Build 里经历这些状态:

Empty → Pending → Initializing → Ready
                                    │
                                    │ (连接断开或会话结束)
                                    ▼
                                 (清理或重连)
​

Empty:配置存在但还未尝试连接
Pending:正在建立传输(如拉起子进程、建立 HTTP 连接)
Initializing:传输已建立,正在握手(协议初始化、查询能力)
Ready:握手完成,可以调用工具

关键细节:初始化的超时

MCP 服务器的初始化(尤其是 stdio 拉起子进程)可能慢——子进程启动、建立连接、协议握手都要时间。Grok Build 有一个 mcp_startup_timeout_secs 配置,控制愿意等多久。超时则该 server 标记为不可用,它的工具不进注册表。

回顾第 3 章,process_conversation_turn 的 prepare_tool_definitions 步骤会等 MCP 初始化(有超时)。这意味着:如果某个 MCP server 慢,会拖慢每轮的准备阶段。所以配置 MCP 时,要权衡「能力丰富」与「启动速度」。

七、MCP 工具的鉴权与执行

MCP 工具与内置工具一样,走完整的鉴权管线与执行流程:

模型调用 MCP:sentry__get_issue
    ↓
框架在注册表找到对应 ToolDyn(MCP 包装的)
    ↓
鉴权管线(第 05 节详谈):
    - PreToolUse hooks
    - 权限规则(可按 MCPTool(my-server__*) 匹配)
    - remembered / 内建放行 / 提示策略
    ↓
执行(ToolStream):
    - 框架调用 ToolDyn.execute_dyn
    - MCP 包装层把调用转成 JSON-RPC 发给 server
    - server 执行,返回结果
    - 结果包成 Terminal
    ↓
标准化 + 回填历史
​

权限规则匹配 MCP 工具

权限规则可以针对 MCP 工具,语法形如 MCPTool(my-server__*),匹配 my-server 提供的所有工具。这让管理员可以「信任某个 MCP server 的所有工具」或「禁用某个 server」。

执行的异步性

MCP 工具的执行涉及网络或 IPC 通信,是异步的。ToolStream 的 Progress 可用于反馈进展(如「正在联系 sentry 服务器...」),Terminal 给最终结果。

八、MCP 的几个实际场景

MCP 让 Grok Build 几乎能接入任何外部能力。几个典型场景:

场景一:接入 SaaS 工具

很多 SaaS(GitHub、Sentry、Slack、Notion 等)提供 MCP 服务器。配置后,Agent 能:

• 查 GitHub issue、创建 PR
• 查 Sentry 工单、分析错误
• 发 Slack 消息
• 读写 Notion 文档

这让 Agent 从「只会写代码」变成「能操作整个工作流」。

场景二:接入内部系统

企业可以为自己内部系统(CMDB、Jira、监控)实现 MCP 服务器,让 Agent 能:

• 查内部服务状态
• 创建内部工单
• 查监控指标

这是企业把 Grok Build 变成「内部 DevOps 助手」的关键。

场景三:接入数据源

数据库、知识库、文档系统都可以暴露成 MCP。Agent 能:

• 查数据库(写 SQL)
• 检索知识库
• 读文档

这让 Agent 的「感知范围」从代码扩展到整个信息生态。

九、MCP 的局限与注意

MCP 强大,但也有局限与注意点:

局限一:依赖 server 实现

MCP 的质量取决于 server 实现。一个写得差的 server(慢、易崩、工具描述不清)会拖累整个体验。

局限二:安全责任

MCP server 是外部代码(尤其 stdio 拉起的子进程),有安全责任:

• server 能访问什么、做什么,要审慎评估
• 来自不信任来源的 server,要沙箱化或限制
• server 的凭证管理(API token 等)要安全

局限三:性能开销

每次 MCP 工具调用涉及 IPC 或 HTTP 往返,比内置工具慢。高频调用时要注意。

局限四:版本兼容

MCP 协议本身在演进,server 与 client 的版本要兼容。遇到「协议不匹配」错误,通常要升级某一方。

十、与其他扩展的对比

把 MCP 与第 5 章的自定义工具、本节后面的 Skills 对比:

MCP 的优势在于「低成本接入丰富能力」——不必写 Rust,配一个 server 就行。这是它成为 Grok Build 最重要扩展机制的原因。

本节要点回顾

1. MCP 是 AI 工具的「USB 标准」:把外部能力标准化为工具/资源/提示,client-server 协议。
2. 解决集成膨胀:一次实现 server,任何 MCP client 都能用。
3. 三类暴露:Tools(Grok Build 主要消费)、Resources、Prompts。
4. Grok Build 的集成:读配置 → 连接 server → 查工具 → 包装成 ToolDyn → 注册进表。
5. 「MCP 工具即工具」:与内置工具同构,都走 ToolDyn/鉴权/执行/ToolStream。
6. 三种传输:stdio(本地子进程,最常用)、http(可远程,支持 OAuth)、sse(http 的兼容别名)。
7. grok mcp 子命令:list/add/remove/doctor,add 可指定 scope(User/Project)。
8. 工具命名:MCP:server__tool,双下划线分隔,跨 server 唯一。
9. 生命周期:Empty→Pending→Initializing→Ready,初始化有超时(mcp_startup_timeout_secs)。
10. 鉴权同内置:走完整管线,权限规则可用 MCPTool(server__*) 匹配。
11. 场景:SaaS 集成、内部系统、数据源——让 Agent 能力无限扩展。
12. 局限:依赖 server 实现、安全责任、性能开销、版本兼容。

下一节,我们看 Skills——另一种扩展维度,它扩展的不是「能力」,而是「知识」。