Skip to main content
Glama
deenesjakoruzh
layermedya

Critic-MCP

by layermedya
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Critic-MCP — 冷酷无情的代码评审官

一个开源的模型上下文协议 (MCP) 服务器，用于以只读方式审查其他AI编程助手（Cursor、OpenCode、Cline等）生成的代码。

Critic-MCP 是“第二双眼睛”：它从不修复你的代码，只冷酷无情地给出批评。它只暴露一个工具（review_code），并且完全没有写入文件的能力。

它的作用是什么？

review_code 工具将你提交的代码与原始需求（意图）进行对比，并通过LLM生成一份包含以下部分的审查报告：

  • 裁决： APPROVED | MODIFICATION_REQUIRED | REJECTED

  • 缺失需求 — 意图与代码之间的差距

  • 安全问题 — SQL注入、XSS、权限提升、硬编码密钥

  • 边界情况问题 — 空/null输入、边界值、差一错误、竞态条件

  • 性能问题 — N+1查询、内存泄漏、冗余计算

  • 其他问题 + 必须修复项（按优先级排序）

Related MCP server: codereview-mcp

安装 — 两步

要求：Node.js >= 20

步骤 1：身份验证（一次性）

运行交互式设置，其工作方式与 aws configure 或 gh auth login 类似：

npx -y critic-mcp auth

它会询问你使用哪个提供商（gemini / openai / deepseek），提示你输入API密钥，然后将两者保存到你主目录下的 ~/.critic-mcp.json 文件中（Unix系统上权限为 0600）。

步骤 2：将其添加到你的IDE

仅将以下内容添加到你的IDE的MCP设置中：

{ "command": "npx", "args": ["-y", "critic-mcp"] }

请参阅 AI助手集成 部分以获取客户端特定详情。就是这样 — 你的密钥现在统一存放在一个位置，位于所有IDE配置之外。

密钥永远不会写入IDE配置。当服务器启动时，它首先检查 process.env，然后检查 ~/.critic-mcp.json；如果两个地方都找不到密钥，它会引导你运行 npx critic-mcp auth。

本地开发（从源码安装）

git clone https://github.com/layermedya/Critic-MCP.git
cd Critic-MCP
npm ci
npm run build
node dist/index.js auth   # authenticate against your own build

命令

npm run build       # TypeScript compilation
npm run typecheck   # Type checking
npm test            # Vitest unit tests
npm run test:watch  # Tests in watch mode
npm start           # Start the server on stdio
npm run inspect     # Manual testing in the browser via MCP Inspector

环境变量（可选）

以下所有变量都是可选的；获取API密钥的正常途径是 npx critic-mcp auth。环境变量始终优先于配置文件（适用于CI/服务器环境）。

变量

描述

CRITIC_PROVIDER

gemini、openai 或 deepseek（回退到 ~/.critic-mcp.json 中的选择，然后再回退到 gemini）

GEMINI_API_KEY

Gemini 密钥（设置后将覆盖文件中的值）

OPENAI_API_KEY

OpenAI/DeepSeek 密钥（设置后将覆盖文件中的值）

GEMINI_MODEL

Gemini 模型名称（默认：gemini-3.6-flash）

OPENAI_MODEL

模型名称（默认：gpt-4o-mini， deepseek 使用 deepseek-chat）

OPENAI_BASE_URL

DeepSeek 等的基础URL（deepseek 默认为 https://api.deepseek.com）

CRITIC_TIMEOUT_MS

LLM请求超时（默认：120000）

CHUNK_SIZE

分块限制（默认：30000 个字符）

CRITIC_CONCURRENCY

分块审查期间的并行请求数（默认：3）

CRITIC_CONFIG_PATH

覆盖配置文件位置（默认：~/.critic-mcp.json）

AI助手集成

以下所有配置均不包含任何密钥；你通过上面的 auth 命令（步骤1）进行一次身份验证即可。npx 要求包已发布到npm；对于本地克隆，你可以改用 "command": "node", "args": ["ABSOLUTE_PATH/dist/index.js"]。

Cursor

在项目级别的 .cursor/mcp.json（或全局的 ~/.cursor/mcp.json）中：

{
  "mcpServers": {
    "critic": {
      "command": "npx",
      "args": ["-y", "critic-mcp"]
    }
  }
}

或者：设置 → MCP → 添加新的MCP服务器，然后粘贴JSON。

OpenCode

在项目级别的 .opencode/opencode.json 或全局的 ~/.config/opencode/opencode.json 中：

{
  "mcp": {
    "critic": {
      "type": "local",
      "command": ["npx", "-y", "critic-mcp"],
      "enabled": true
    }
  }
}

OpenCode 使用 mcp 键（而非 mcpServers）和 environment 字段（而非 env）；command 必须是一个数组。你不再需要将密钥写入 environment 块。

Cline（VS Code扩展）

打开Cline面板 → MCP 服务器 标签页 → 编辑全局MCP 或 编辑项目MCP，然后编辑JSON：

{
  "mcpServers": {
    "critic": {
      "command": "npx",
      "args": ["-y", "critic-mcp"],
      "disabled": false,
      "autoApprove": ["review_code"]
    }
  }
}

autoApprove 允许 Cline 无需确认即可运行 review_code；这是安全的，因为该工具从不写入文件。

Continue.dev

将MCP服务器添加到 ~/.continue/config.json 中（无论你的Continue版本如何，都支持stdio传输）：

{
  "experimental": {
    "modelContextProtocolServers": [
      {
        "transport": {
          "type": "stdio",
          "command": "npx",
          "args": ["-y", "critic-mcp"]
        }
      }
    ]
  }
}

手动测试场景

examples/bad_code.js 是一个Express示例，故意包含了SQL注入、XSS和N+1查询；examples/intent.txt 保存了原始需求。从任何客户端按如下方式调用它：

“使用 review_code 工具审查 examples/bad_code.js 中的代码。需求：examples/intent.txt”

期望审查官至少发现以下问题：

  • 严重： db.query("SELECT * FROM users WHERE email = '" ...) — SQL注入

  • 严重： res.send(comment.body) — 存储型XSS

  • 高： 每个用户一个单独的查询 — N+1问题

架构

src/index.ts   -> MCP server, zod validation, error handling + `auth` argv routing
src/cli.ts     -> Interactive authentication flow (`critic-mcp auth`)
src/config.ts  -> Global config (~/.critic-mcp.json) + credential resolution (env → file)
src/prompt.ts  -> Ruthless Critic system prompt + chunked-review prompts
src/llm.ts     -> Provider layer + timeout protection + map-reduce orchestration
src/chunker.ts -> Line-ending based chunking (for code above the limit)

分块审查（map-reduce）

当 code_snippet 超过 CHUNK_SIZE（默认 30,000 个字符）时，系统会自动切换到 map-reduce 流程：

  1. Map： 代码按行边界拆分；每个块同时发送给LLM（默认 3 个并行请求，可通过 CRITIC_CONCURRENCY 配置）。单个块的失败永远不会影响整个审查。

  2. Reduce： 所有返回的部分分析结果由“合成器”提示合并 — 它从不弱化发现结果，并且当有部分报告了严重问题时从不返回 APPROVED — 最终生成一份最终报告。

服务器仅返回字符串报告；它没有写入文件的能力，也绝不向外暴露网络客户端。

许可证

MIT

Available Tools

1 tool
review_codeA

Read-only code critic. Analyzes the provided code snippet against its stated intent and returns a detailed, ruthless review report: missing requirements, security vulnerabilities (SQLi, XSS, privilege escalation), edge cases and performance issues (N+1, memory leaks). Never writes files — returns the report as text only.

ParametersJSON Schema
NameRequiredDescriptionDefault
intentYes
code_snippetYes

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Since no annotations are provided, the description must fully disclose behavioral traits. It does so clearly: never writes files, returns only a text report, and performs a ruthless review. It also lists specific vulnerability categories checked (SQLi, XSS, privilege escalation) and performance issues (N+1, memory leaks).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loaded with the core purpose ('Read-only code critic'). Every phrase adds value — no filler. The first sentence establishes scope, the second disclaims side effects and clarifies output format.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has only 2 parameters, no output schema, and no annotations, the description fairly covers the inputs, behavior, and output. An agent should be able to invoke it correctly. A minor gap: the description doesn't mention the output format structure (e.g., bullet points vs. paragraphs), but this is acceptable for a complex, free-text report.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. The description explains the purpose of the two parameters implicitly: 'code snippet' and 'its stated intent' map directly to code_snippet and intent. It does not detail their types or constraints, but the schema already provides min/max lengths and types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a clear verb-resource pair ('Analyzes the provided code snippet') and immediately states it is read-only. It lists specific review categories (missing requirements, security vulnerabilities, edge cases, performance issues), leaving no ambiguity about what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states the tool is 'Read-only' and 'Never writes files', which guides when to use it (analysis without side effects). However, it does not mention when not to use it or provide alternatives, though sibling tools are absent, so there is no need for exclusion.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev1.0.0
    • First observedreview_code
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.3/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of confusion between tools. The single tool's purpose is clearly defined in great detail.

Naming Consistency5/5

Naming consistency is not applicable as a concept with a single tool. It cannot be penalized and defaults to the highest score.

Tool Count2/5

A single tool severely limits the server's functionality. While the tool is comprehensive, it would benefit from being broken down into more focused tools (e.g., review_security, review_performance).

Completeness2/5

The server covers only the 'review' aspect. For a code review tool, this is acceptable, but it lacks any supporting tools for follow-up actions like re-review, fetching additional context, or managing review sessions.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • code-review-mcp

    AlanNiew
    A
    license
    A
    quality
    D
    maintenance
    An MCP server that provides local code quality analysis for AI coding assistants, supporting file analysis, git diff review, and full project scanning with quality scoring.
    4
    3
    MIT

  • codereview-mcp

    lfylow
    A
    license
    A
    quality
    C
    maintenance
    An MCP server that lets AI agents review code using language models, supporting git diffs, files, and snippets with severity levels. Works with Ollama (local) and hosted providers like OpenAI, Anthropic, and OpenRouter.
    3
    MIT