Critic-MCP
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|REJECTEDFehlende 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 authEs 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 zunpx critic-mcp authweitergeleitet.
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 buildBefehle
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 InspectorUmgebungsvariablen (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 |
|
|
| Gemini-Schlüssel (überschreibt die Datei, wenn gesetzt) |
| OpenAI/DeepSeek-Schlüssel (überschreibt die Datei, wenn gesetzt) |
| Gemini-Modellname (Standard: |
| Modellname (Standard: |
| Basis-URL für DeepSeek usw. (deepseek standardmäßig |
| LLM-Anfrage-Timeout (Standard: |
| Chunking-Grenze (Standard: |
| Parallele Anfragen während der chunked-Überprüfung (Standard: |
| Überschreibt den Speicherort der Konfigurationsdatei (Standard: |
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 (nichtmcpServers) und dasenvironment-Feld (nichtenv);commandmuss ein Array sein. Sie müssen keine Schlüssel mehr in einenenvironment-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"]
}
}
}
autoApproveerlaubt Cline,review_codeohne 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-InjectionKRITISCH:
res.send(comment.body)— gespeichertes XSSHOCH: 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:
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.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 toolreview_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.
| Name | Required | Description | Default |
|---|---|---|---|
| intent | Yes | ||
| code_snippet | Yes |
TDQS
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.
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.
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.
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.
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.
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 tool update
v1.0.0- First observed
review_code
TDQS
Scored across 1 tool
With only one tool, there is no possibility of confusion between tools. The single tool's purpose is clearly defined in great detail.
Naming consistency is not applicable as a concept with a single tool. It cannot be penalized and defaults to the highest score.
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).
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
Related MCP Connectors
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
An MCP server that gives your AI access to the source code and docs of all public github repos
Scan any MCP server for tool-poisoning, security, auth & license. Trust score before install.
Scan any public GitHub MCP-server repo for security issues. 37 MCP-specific L1 rules, 8 languages.
Related MCP Servers
- AlicenseAqualityDmaintenanceAn 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.43MIT
- AlicenseAqualityCmaintenanceAn 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.3MIT
- AlicenseNot gradedqualityDmaintenanceMCP server for automated code review using AI agents. It analyzes code diffs or file paths for bugs, security issues, and style violations.MIT
- AlicenseAqualityDmaintenanceDeterministic code review MCP server that provides tools for file selection, rule matching, comment positioning, and reflection, ensuring stable review quality without LLM calls.513 npm1MIT