critique-mcp

一个 MCP 服务器，它让智能体真正拥有审查 pull request 的能力——不只是概括 diff，而是把 diff 拆开、对变更的代码运行 lint、在测试没有被更新时标记出来，并把一份真实的 review 提交回 GitHub。

Python · Model Context Protocol · GitHub REST API

工具

每个工具都是一个精简、可独立测试的函数——run_linter 不知道 check_test_coverage 是怎么工作的，二者除了经由 GitHubClient 之外也都不与 GitHub 通信。由智能体决定如何组合它们；这个服务器只是给它一双手。

check_test_coverage 是一种 PR 级别的启发式检查，而不是逐文件的覆盖率插桩：它标记的是“这个 PR 改动源文件，但整个 PR 里连一个测试文件都没碰”，这和 Danger.js 等工具使用的粗粒度信号一致。一个改动了五个源文件、但顺带只动了一个无关测试的 PR 不会被标记被拦截——更精确的版本需要真实的覆盖率数据，而不是文件名。

Related MCP server: github-pr-review-mcp

为什么会有这个项目

我曾在别人的 PR 中手工找到并修复过这些工具正好能捕获的那类 bug——比如 chroma-core/chroma 中一个空洞通过的测试断言，weaviate-python-client 中一个只检查了列表里某一个元素的校验器，以及 qdrant-client 里的浮点精度问题。这个项目把这种 review 流程变成了智能体可以直接调用的工具，而不是每次都要靠人手工做同样的检查。

环境要求

需要 Python 3.11+、PATH 里的 ruff，以及一个带 repo 权限的 GitHub personal access token（只读就够用了，除非你想让 post_review 正常工作）。

cp .env.example .env      # then add your token to .env
python -m venv .venv && source .venv/bin/activate   # Windows: .venv\Scripts\activate
pip install -r requirements.txt

使用

把它添加到 Claude Desktop / Claude Code 的 MCP 配置中：

{
  "mcpServers": {
    "critique": {
      "command": "python",
      "args": ["-m", "critique_mcp.server"],
      "env": { "GITHUB_TOKEN": "ghp_..." }
    }
  }
}

然后让智能体这样使用它：“用 critique 审查 owner/repo 上的 PR #42，检查 lint 问题和缺失的测试，然后提交一个总结性 review。”

测试

pytest

测试中所有 GitHub API 调用都是 mock 的——除非你自己运行这个 server，否则这里的任何部分都不会发起真正的网络请求。