MCP 工具集成

MCP（Model Context Protocol）是 Qoder 与外部工具链的协议。通过 MCP，AI 可以操作 GitHub 仓库、查询数据库等。

---

使用篇 —— 从会用开始

1. 从使用开始

MCP 在 Qoder 中配置即用：打开 设置 → MCP 服务，界面中列出了所有已安装的 MCP 服务，每个服务有独立的开关控制启用/禁用。

当前常用配置（来自作者的实际环境）：

服务	用途	状态
GitHub MCP	搜索代码、获取文件内容、阅读开源项目源码	✅ 可用
Semi UI MCP	查询 Semi Design 组件的文档和使用方式	✅ 可用
Playwright MCP	打开本地开发页面进行端到端测试	✅ 可用

2. MCP 与 Skill 的快速对比

很多人容易把 MCP 和 Skill 搞混，一个简单的区分就能讲清楚：

维度	Skill	MCP
本质	指令集（告诉 AI 怎么做）	工具调用协议（让 AI 能做什么）
形态	.md 文件，存放在工作区	独立的服务端进程
复杂度	一个 markdown 文件即可	需要运行服务端进程，配置成本高
场景	写作规范、代码审查流程	操作 GitHub、查询数据库

Skill 告诉 AI 怎么做，MCP 给 AI 提供能做什么的能力。 Skill 负责流程编排，MCP 负责执行具体操作。

除了 MCP 协议对接外部工具，Growth AIOS 还支持创建自定义 Tool——用 Python 脚本定义工具逻辑，配置参数 Schema 后供 LLM Function Calling 调用：

3. 配置方式

MCP 服务的配置格式如下（通常由 Qoder 设置界面自动生成，不需要手写）：

{
  "servers": {
    "github": {
      "command": "node",
      "args": ["path/to/github-mcp-server"],
      "env": {
        "GITHUB_TOKEN": "xxx"
      }
    }
  }
}

配置完成后，AI 就可以在工作流程中按需调用这些工具。例如审查代码时自动通过 GitHub MCP 拉取 PR 的变更文件。

---

实践篇 —— 从会用到用对

4. GitHub MCP 实战

GitHub MCP 让 AI 可以直接搜索和读取 GitHub 上的代码，不需要你手动打开浏览器查源码。

常用工具：

工具	功能
search_code	搜索仓库中的代码
get_contents	获取文件或目录内容
list_commits	查看提交历史
get_pull_request_files	获取 PR 中的变更文件

真实场景：阅读 Spring Boot 事务管理器源码

想知道 Spring Boot 的事务管理器是怎么设计的？直接对 AI 说：

通过 GitHub MCP，阅读 spring-projects/spring-boot 仓库中事务管理器相关的代码，描述它的设计思路。

AI 会自动通过 search_code 找到 TransactionManager 相关的文件，用 get_contents 读取核心代码，然后给你一份设计分析——用了什么模式、核心接口怎么组织的、默认实现是什么。

整个过程你只需要说一句话，不用自己去 GitHub 上翻目录结构。

5. Semi UI MCP 实战

Semi Design 是字节跳动的 UI 组件库。Semi UI MCP 让 AI 可以直接查询组件文档，而不是凭训练数据中的记忆来生成代码。

真实场景：查看 Button 组件的用法

对 AI 说：

通过 Semi UI MCP，查一下 Semi Design 的 Button 组件有哪些 type、size，以及怎么使用图标按钮。

AI 会调用 get_semi_document 或 get_semi_code_block 获取最新的组件文档，返回准确的 API 说明和代码示例。这和 AI 凭记忆生成的代码不同——MCP 返回的是文档库中的最新内容，不会因为模型训练数据过时而给出已废弃的用法。

6. Playwright MCP 实战

Playwright MCP 让 AI 可以打开浏览器、点击、截图、填写表单——做端到端测试。

真实场景：对本地开发页面做端到端测试

你正在开发一个页面，想看看实际效果，对 AI 说：

通过 Playwright MCP 打开 http://localhost:8080，看看我现在正在开发的界面，截图给我看。

AI 会用 browser_navigate 打开页面，browser_take_screenshot 截图返回给你。你不需要自己打开浏览器、输入地址、截图——AI 一条指令全做完。

7. 最佳实践要点

• 优先 CLI 模式：MCP Server 通过 stdio 作为子进程运行，由 Qoder 管理生命周期，不需要手动启停
• 最小权限：给 MCP Server 配置的 Token 仅赋予所需的最小权限
• 失效处理：MCP Server 进程可能因网络超时等原因挂掉，AI 会自动尝试重连

---

知识篇 —— 从用对到理解

8. MCP 的工作原理

协议模型

MCP 的精髓是定义一套标准化的工具调用接口，让 AI 能够动态发现和调用外部能力。

它的核心模型是「客户端-服务端」架构：

AI 应用（Qoder）
    │
    ├── MCP Client（内置于 Qoder）
    │       │
    │       │  JSON-RPC over stdio / HTTP
    │       │
    │       ├── GitHub MCP Server
    │       │       └── 暴露工具：search_code / list_commits / get_contents ...
    │       │
    │       └── 数据库 MCP Server
    │               └── 暴露工具：query / execute / list_tables ...

MCP 客户端（Qoder）启动时读取配置中的 MCP Server 列表，启动对应进程并建立通信通道。每个 Server 通过 JSON-RPC 协议声明自己提供了哪些工具（tools）。

与 HTTP 调用的区别

MCP 和 REST API 都是请求-响应模式，但设计思路不同：

	REST API	MCP
协议	HTTP（无状态）	JSON-RPC（有会话管理）
接口发现	读文档才知道有哪些接口	服务端主动声明工具列表
工具签名	看 Swagger 文档	服务端返回 JSON Schema 定义
传输方式	仅 HTTP	stdio 管道 + HTTP 双模式

MCP 最大的特点在于「动态发现」。REST API 需要提前知道接口地址和参数，MCP 的服务端会主动声明自己能做什么。AI 不需要提前知道，启动时一问便知。

两种传输方式

stdio 模式（CLI）：MCP Server 作为子进程启动，通过 stdin/stdout 通信。Qoder 启动时自动拉起，退出时自动关闭，不需要手动管理进程。

HTTP 模式（Server）：MCP Server 作为独立 HTTP 服务运行，适合远程部署或多客户端共享。

9. Agent 注册和发现机制

MCP 通过动态发现（Discovery） 让 AI 感知到外部工具。Qoder 启动时会自动完成：

1. 启动 MCP Server：根据配置启动子进程或连接 HTTP 端点
2. 获取工具列表：向每个 Server 发送 tools/list 请求
3. 获取工具签名：每个工具返回 JSON Schema 格式的参数定义
4. 注入上下文：Qoder 把工具列表注入到大模型的工具调用上下文
5. 按需调用：AI 根据任务判断是否调用 MCP 工具

这个过程是自动的。并且采用轻量注册策略——只在上下文中保留工具名和简短描述，完整签名在调用时才加载。这和 Skill 的渐进式加载是同一个设计思想。

10. 为什么 MCP 没有普及

MCP 的设计思路很清晰，但在实际使用中暴露了几个根本问题：

问题一：配置成本高

每个 MCP Server 都是一个独立的进程。以 GitHub MCP 为例，需要安装 Node 环境、下载 Server 包、配置 Token、确保进程能正常启动。对比之下，一个 Skill 只是在工作区放一个 .md 文件——配置成本不在一个量级。

问题二：维护负担重

MCP Server 进程可能因为网络超时、依赖升级、Token 过期等原因挂掉。每个 MCP Server 都有独立的版本管理和更新周期，维护多个 Server 的负担会不断累积。

问题三：浏览器场景被内置能力覆盖

Playwright MCP 曾经是 MCP 的重要用例——让 AI 操作浏览器做端到端测试。但 Qoder 已经内置了浏览器 Agent（设置中即可启用），覆盖了截图、点击、表单填写等场景，不再需要单独配置一个浏览器 MCP。

问题四：Skill 能做大部分 MCP 能做的事

当 AI 需要与外部系统交互时，除了通过 MCP 调用 API，还可以通过 Skill 告诉 AI「怎么用命令行完成这个操作」。比如操作 GitHub 可以用 gh CLI 命令，查询数据库可以用 sqlite3 命令——这些都被 Qoder 的 Bash 工具直接覆盖，不需要额外配置 MCP Server。

对比总结

方案	配置成本	维护负担	适用场景
MCP	高（独立进程 + Token + 依赖管理）	高（每个 Server 独立维护）	需要标准化协议对接的场景
Skill + Bash 工具	低（一个 .md 文件）	低（随项目版本管理）	大部分日常操作

建议：能用 Skill 配合 Bash 工具解决的场景，优先用 Skill。MCP 更适合需要标准化协议对接多个客户端的场景——但如果你只是一个人在用 Qoder，这个需求基本不存在。对于已经配置好的 GitHub MCP，可以继续使用；新场景优先考虑 Skill 方案。

---

写在最后

MCP 是一个标准化的工具调用协议，设计思路值得了解——动态发现、JSON-RPC 通信、渐进式加载——但这些原理在今天更多地被 Skill + 内置工具的组合所替代。技术的演进往往不是谁淘汰谁，而是更轻量的方案覆盖了大多数需求。

---

Growth AIOS 产品参考

以下为 Growth AIOS 产品中对应的自定义 Tool 管理界面截图：