Skip to main content
Glama

Critic-MCP — Der gnadenlose Code-Kritiker

Ein Open-Source-Model Context Protocol (MCP)-Server, der den von anderen KI-Coding-Assistenten (Cursor, OpenCode, Cline, etc.) produzierten Code überprüft – schreibgeschützt.

Critic-MCP ist ein „zweites Augenpaar“: Es repariert niemals Ihren Code, es kritisiert ihn nur gnadenlos. Es stellt ein einziges Tool (review_code) zur Verfügung und hat absolut keine Dateischreibfähigkeit.

Was macht es?

Das review_code-Tool vergleicht den von Ihnen gesendeten Code mit der ursprünglichen Anforderung (Absicht) und erstellt über ein LLM einen Überprüfungsbericht mit den folgenden Abschnitten:

  • Urteil: APPROVED | MODIFICATION_REQUIRED | REJECTED

  • Fehlende Anforderungen — die Lücke zwischen Absicht und Code

  • Sicherheitsergebnisse — SQL-Injection, XSS, Privilegieneskalation, hartcodierte Geheimnisse

  • Grenzfall-Ergebnisse — null/leere Eingaben, Grenzwerte, Off-by-One, Race Conditions

  • Leistungsergebnisse — N+1-Abfragen, Speicherlecks, redundante Berechnungen

  • Weitere Ergebnisse + Muss-korrigiert-Elemente (in Prioritätsreihenfolge)

Related MCP server: codereview-mcp

Installation — Zwei Schritte

Voraussetzung: Node.js >= 20

Schritt 1: Authentifizieren (einmalig)

Führen Sie die interaktive Einrichtung aus, die genau wie aws configure oder gh auth login funktioniert:

npx -y critic-mcp auth

Es fragt, welchen Anbieter Sie verwenden (gemini / openai / deepseek), fordert Ihren API-Schlüssel an und speichert beide in ~/.critic-mcp.json in Ihrem Home-Verzeichnis (0600-Berechtigungen unter Unix).

Schritt 2: Fügen Sie es Ihrer IDE hinzu

Fügen Sie nur dies zu den MCP-Einstellungen Ihrer IDE hinzu:

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

Siehe Abschnitt KI-Assistent-Integration für client-spezifische Details. Das war's – Ihre Schlüssel befinden sich jetzt an einem Ort, außerhalb jeder IDE-Konfiguration.

Schlüssel werden niemals in IDE-Konfigurationen geschrieben. Wenn der Server startet, sucht er zuerst in process.env, dann in ~/.critic-mcp.json; wird in keinem ein Schlüssel gefunden, werden Sie zu npx critic-mcp auth weitergeleitet.

Lokale Entwicklung (Installation aus dem Quellcode)

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

Befehle

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

Umgebungsvariablen (optional)

Alle sind optional; der normale Weg für API-Schlüssel ist npx critic-mcp auth. Umgebungsvariablen haben immer Vorrang vor der Konfigurationsdatei (für CI/Server-Setups).

Variable

Beschreibung

CRITIC_PROVIDER

gemini, openai oder deepseek (fällt zurück auf die Auswahl in ~/.critic-mcp.json, dann auf gemini)

GEMINI_API_KEY

Gemini-Schlüssel (überschreibt die Datei, wenn gesetzt)

OPENAI_API_KEY

OpenAI/DeepSeek-Schlüssel (überschreibt die Datei, wenn gesetzt)

GEMINI_MODEL

Gemini-Modellname (Standard: gemini-3.6-flash)

OPENAI_MODEL

Modellname (Standard: gpt-4o-mini, deepseek-chat für deepseek)

OPENAI_BASE_URL

Basis-URL für DeepSeek usw. (deepseek standardmäßig https://api.deepseek.com)

CRITIC_TIMEOUT_MS

LLM-Anfrage-Timeout (Standard: 120000)

CHUNK_SIZE

Chunking-Grenze (Standard: 30000 Zeichen)

CRITIC_CONCURRENCY

Parallele Anfragen während der chunked-Überprüfung (Standard: 3)

CRITIC_CONFIG_PATH

Überschreibt den Speicherort der Konfigurationsdatei (Standard: ~/.critic-mcp.json)

KI-Assistent-Integration

Keine der untenstehenden Konfigurationen enthält Schlüssel; Sie authentifizieren sich einmalig über den auth-Befehl (Schritt 1 oben). npx erfordert, dass das Paket auf npm veröffentlicht ist; für einen lokalen Klon können Sie stattdessen "command": "node", "args": ["ABSOLUTE_PATH/dist/index.js"] verwenden.

Cursor

In der projektweiten .cursor/mcp.json (oder der globalen ~/.cursor/mcp.json):

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

Alternativ: Einstellungen → MCP → Neuen MCP-Server hinzufügen, dann das JSON einfügen.

OpenCode

In der projektweiten .opencode/opencode.json oder der globalen ~/.config/opencode/opencode.json:

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

OpenCode verwendet den mcp-Schlüssel (nicht mcpServers) und das environment-Feld (nicht env); command muss ein Array sein. Sie müssen keine Schlüssel mehr in einen environment-Block schreiben.

Cline (VS Code-Erweiterung)

Öffnen Sie das Cline-Panel → Registerkarte MCP Servers → Globales MCP bearbeiten oder Projekt-MCP bearbeiten, dann bearbeiten Sie das JSON:

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

autoApprove erlaubt Cline, review_code ohne Bestätigung auszuführen; das ist sicher, da das Tool niemals Dateien schreibt.

Continue.dev

Fügen Sie den MCP-Server zu ~/.continue/config.json hinzu (stdio-Transport wird unabhängig von Ihrer Continue-Version unterstützt):

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

Manuelles Testszenario

examples/bad_code.js ist ein Express-Beispiel, das absichtlich SQL-Injection, XSS und N+1-Abfragen enthält; examples/intent.txt enthält die ursprüngliche Anforderung. Rufen Sie es von einem beliebigen Client wie folgt auf:

"Überprüfen Sie den Code in examples/bad_code.js mit dem review_code-Tool. Anforderung: examples/intent.txt"

Erwarten Sie, dass der Kritiker mindestens Folgendes erkennt:

  • KRITISCH: db.query("SELECT * FROM users WHERE email = '" ...) — SQL-Injection

  • KRITISCH: res.send(comment.body) — gespeichertes XSS

  • HOCH: Eine separate Abfrage pro Benutzer — N+1-Problem

Architektur

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)

Chunked-Überprüfung (Map-Reduce)

Wenn code_snippet CHUNK_SIZE (Standard 30.000 Zeichen) überschreitet, wechselt das System automatisch zu einem Map-Reduce-Ablauf:

  1. Map: Der Code wird an Zeilengrenzen aufgeteilt; jeder Block wird gleichzeitig an das LLM gesendet (Standard 3 parallele Anfragen, konfigurierbar über CRITIC_CONCURRENCY). Ein einzelner Blockfehler stoppt niemals die gesamte Überprüfung.

  2. Reduce: Alle zurückgegebenen Teilanalysen werden durch den "Synthesizer"-Prompt zusammengeführt – der niemals Ergebnisse abschwächt und niemals APPROVED zurückgibt, wenn ein einzelner Teil KRITISCH meldet – zu einem endgültigen Bericht.

Der Server gibt nur einen String-Bericht zurück; er hat keine Dateischreibfähigkeit und setzt niemals einen Netzwerkclient nach außen frei.

Lizenz

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

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

Related MCP Connectors

Related MCP Servers

  • 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
  • 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