15.8 内嵌 MCP 服务

模型: claude-opus-4-6 (anthropic/claude-opus-4-6) 生成日期: 2026-02-17

---

oh-my-opencode 内嵌了 3 个 MCP 服务，为 Agent 提供开箱即用的外部信息获取能力。这些 MCP 服务以 Remote MCP（远程 MCP）模式运行——oh-my-opencode 不在本地启动 MCP Server 进程，而是直接连接到云端的 MCP 服务端点。

15.8.1 Context7 集成

Context7 是一个提供开源库官方文档和代码示例的 MCP 服务。当 Librarian Agent 需要查找某个库的 API 文档时，它会通过 Context7 获取最新的、结构化的文档信息。

// oh-my-opencode/src/mcp/context7.ts
export const context7 = {
  type: "remote" as const,
  url: "https://mcp.context7.com/mcp",
  enabled: true,
  headers: process.env.CONTEXT7_API_KEY
    ? { Authorization: `Bearer ${process.env.CONTEXT7_API_KEY}` }
    : undefined,
  oauth: false as const,  // 使用 API Key，不使用 OAuth
}

配置极其简洁——只需指定远程 URL。如果用户设置了 CONTEXT7_API_KEY 环境变量，会通过 Authorization Header 传递认证信息；否则使用匿名访问。

Context7 提供的典型工具：

• resolve-library-id：将库名解析为 Context7 兼容的 ID

• query-docs：查询库的文档和代码示例

15.8.2 Grep.app 集成

Grep.app 是一个搜索 GitHub 公开代码库的服务。它让 Agent 能够搜索真实世界的代码模式——例如"其他项目是如何处理 JWT 认证的？"

// oh-my-opencode/src/mcp/grep-app.ts
export const grep_app = {
  type: "remote" as const,
  url: "https://grep.app.context7.com/mcp",
  enabled: true,
  oauth: false as const,
}

Grep.app 的搜索不同于 GitHub 的代码搜索——它是字面量代码模式搜索（类似 grep），支持正则表达式，并且可以按编程语言、仓库和文件路径过滤。

典型使用场景：

• searchGitHub("useState(", language=["TypeScript"])：搜索 React useState 的使用模式

• searchGitHub("async function $NAME($$$)", useRegexp=true)：搜索异步函数模式

15.8.3 Web Search 集成

Web Search 是通用的网络搜索服务，默认使用 Exa 作为 Provider，也支持 Tavily。

// oh-my-opencode/src/mcp/websearch.ts
export function createWebsearchConfig(config?: WebsearchConfig): RemoteMcpConfig {
  const provider = config?.provider || "exa"

  if (provider === "tavily") {
    const tavilyKey = process.env.TAVILY_API_KEY
    if (!tavilyKey) {
      throw new Error("TAVILY_API_KEY environment variable is required")
    }
    return {
      type: "remote",
      url: "https://mcp.tavily.com/mcp/",
      enabled: true,
      headers: { Authorization: `Bearer ${tavilyKey}` },
      oauth: false,
    }
  }

  // 默认使用 Exa
  return {
    type: "remote",
    url: process.env.EXA_API_KEY
      ? `https://mcp.exa.ai/mcp?tools=web_search_exa&exaApiKey=${encodeURIComponent(process.env.EXA_API_KEY)}`
      : "https://mcp.exa.ai/mcp?tools=web_search_exa",
    enabled: true,
    ...(process.env.EXA_API_KEY ? { headers: { "x-api-key": process.env.EXA_API_KEY } } : {}),
    oauth: false,
  }
}

Web Search 支持的配置：

{
  "websearch": {
    "provider": "exa"     // 或 "tavily"
  }
}

MCP 注册入口

三个 MCP 服务通过统一入口注册：

// oh-my-opencode/src/mcp/index.ts
export function createBuiltinMcps(disabledMcps: string[] = [], config?) {
  const mcps: Record<string, RemoteMcpConfig> = {}

  if (!disabledMcps.includes("websearch")) {
    mcps.websearch = createWebsearchConfig(config?.websearch)
  }

  if (!disabledMcps.includes("context7")) {
    mcps.context7 = context7
  }

  if (!disabledMcps.includes("grep_app")) {
    mcps.grep_app = grep_app
  }

  return mcps
}

用户可以通过配置禁用任何一个内嵌 MCP：

{
  "disabled_mcps": ["websearch"]  // 禁用 Web Search
}

设计决策：为什么使用 Remote MCP？

oh-my-opencode 选择了 Remote MCP 模式而非 Stdio MCP 模式，这是一个有意的设计决策：

1. 零配置安装：Remote MCP 不需要在本地安装任何二进制文件或 Node.js 模块。只需一个 URL 就能连接服务。

2. 无进程管理：Stdio MCP 需要启动和管理子进程的生命周期，包括启动、健康检查、崩溃重启等。Remote MCP 将这些复杂性交给了服务提供方。

3. 始终最新：服务端更新不需要客户端做任何操作。当 Context7 添加了对新库的支持，所有用户立即受益。

4. 代价：需要网络连接，且受到服务提供方的可用性和 API 限制约束。

衍生解释：Remote MCP 与 Stdio MCP 的区别

MCP（Model Context Protocol）支持两种传输方式：

Stdio MCP：MCP Server 作为一个本地进程运行，通过标准输入/输出（stdin/stdout）与客户端通信。客户端负责启动进程、发送 JSON-RPC 消息到 stdin、从 stdout 读取响应。

Client ——stdin/stdout——→ Local MCP Server Process

Remote MCP（SSE）：MCP Server 运行在远程服务器上，通过 HTTP/SSE（Server-Sent Events）与客户端通信。客户端发送 HTTP POST 请求，服务器通过 SSE 流式返回响应。

Client ——HTTP/SSE——→ Remote MCP Server (cloud)

Stdio MCP 适合需要访问本地资源（文件系统、数据库）的场景；Remote MCP 适合纯信息查询类的场景（文档搜索、代码搜索、网络搜索）。oh-my-opencode 的三个内嵌 MCP 都属于后者，因此 Remote MCP 是自然的选择。

本节小结

oh-my-opencode 内嵌的 3 个 MCP 服务为 Agent 提供了三种外部信息获取能力：

1. Context7：开源库的官方文档和代码示例

2. Grep.app：GitHub 公开仓库的代码模式搜索

3. Web Search（Exa/Tavily）：通用网络搜索

三者均使用 Remote MCP 模式，实现了零配置、零安装的开箱即用体验。通过 disabled_mcps 配置，用户可以精确控制启用哪些服务。

---

第 15 章总结

本章完整剖析了 oh-my-opencode 的内部架构。作为 OpenCode 生态中最复杂的第三方 Plugin，它展示了 Plugin 系统的全部能力边界：

• 11 个角色化 Agent，通过动态 Prompt 构建器实现元数据驱动的智能委托

• 15 个自定义工具，从 AST 搜索到行号哈希编辑，大幅扩展了 Agent 的操作能力

• 53 个行为 Hook，构成了一张密集的防护网，覆盖上下文管理、错误恢复、任务续接等方方面面

• 20 个 Feature 模块，封装了后台并发、tmux 可视化、状态持久化等独立功能域

• 9 个 Plugin 接口实现，将内部能力适配到 OpenCode 的接口规范

• 3 个内嵌 MCP 服务，提供开箱即用的外部信息获取

oh-my-opencode 的设计哲学可以概括为：Agent 人格化、行为防御化、知识可组合化、体验开箱化。它不仅是一个强大的工具集，更是 AI Agent 工程化的一次成功实践。