Un servidor MCP personalizado que realiza revisiones de código utilizando Repomix y LLM.
Aplanar bases de código usando Repomix
Analizar código con modelos de lenguaje grandes
Obtenga revisiones de código estructuradas con problemas y recomendaciones específicas
Compatibilidad con múltiples proveedores de LLM (OpenAI, Anthropic, Gemini)
Maneja la fragmentación para bases de código grandes
Related MCP server: Code Review MCP Server
# Clone the repository
git clone https://github.com/yourusername/code-review-server.git
cd code-review-server
# Install dependencies
npm install
# Build the server
npm run buildCree un archivo .env en el directorio raíz basado en la plantilla .env.example :
cp .env.example .envEdite el archivo .env para configurar su proveedor LLM preferido y su clave API:
# LLM Provider Configuration
LLM_PROVIDER=OPEN_AI
OPENAI_API_KEY=your_openai_api_key_hereEl servidor de revisión de código implementa el Protocolo de contexto de modelo (MCP) y se puede utilizar con cualquier cliente MCP:
# Start the server
node build/index.jsEl servidor expone dos herramientas principales:
analyze_repo : Aplana una base de código usando Repomix
code_review : Realiza una revisión de código utilizando un LLM
Este servidor proporciona dos herramientas distintas para diferentes necesidades de análisis de código:
Utilice esta herramienta cuando necesite:
Obtenga una descripción general de alto nivel de la estructura y la organización de una base de código
Aplanar un repositorio en una representación textual para el análisis inicial
Comprenda la estructura del directorio y el contenido de los archivos sin una revisión detallada
Prepárese para una revisión de código más profunda
Escanee rápidamente una base de código para identificar archivos relevantes para un análisis posterior
Situaciones de ejemplo:
Quiero comprender la estructura de este repositorio antes de revisarlo.
"Muéstrame qué archivos y directorios hay en este código base"
"Dame una vista aplanada del código para entender su organización"
Utilice esta herramienta cuando necesite:
Realizar una evaluación integral de la calidad del código
Identificar vulnerabilidades de seguridad específicas, cuellos de botella de rendimiento o problemas de calidad del código
Obtenga recomendaciones prácticas para mejorar el código
Realizar una revisión detallada con clasificaciones de gravedad de los problemas.
Evaluar una base de código frente a las mejores prácticas
Situaciones de ejemplo:
Revisar este código base para detectar vulnerabilidades de seguridad.
Analizar el rendimiento de estos archivos JavaScript específicos.
"Dame una evaluación detallada de la calidad del código de este repositorio"
"Revisa mi código y dime cómo mejorar su mantenibilidad"
Cuándo utilizar parámetros:
specificFiles : cuando solo desea revisar ciertos archivos, no todo el repositorio
fileTypes : cuando desea centrarse en extensiones de archivo específicas (por ejemplo, .js, .ts)
detailLevel : utilice «básico» para una descripción general rápida o «detallado» para un análisis en profundidad
focusAreas : Cuando quieres priorizar determinados aspectos (seguridad, rendimiento, etc.)
Para fines de prueba, puede utilizar la herramienta CLI incluida:
node build/cli.js <repo_path> [options]Opciones:
--files <file1,file2> : Archivos específicos para revisar
--types <.js,.ts> : Tipos de archivos a incluir en la revisión
--detail <basic|detailed> : Nivel de detalle (predeterminado: detallado)
--focus <areas> áreas> : Áreas en las que centrarse (seguridad, rendimiento, calidad, mantenibilidad)
Ejemplo:
node build/cli.js ./my-project --types .js,.ts --detail detailed --focus security,quality# Run tests
npm test
# Watch mode for development
npm run watch
# Run the MCP inspector tool
npm run inspectorEl servidor de revisión de código se integra directamente con múltiples API de proveedores LLM:
OpenAI (predeterminado: gpt-4o)
Antrópico (predeterminado: claude-3-opus-20240307)
Géminis (predeterminado: gemini-1.5-pro)
Configure su proveedor LLM preferido en el archivo .env :
# Set which provider to use
LLM_PROVIDER=OPEN_AI # Options: OPEN_AI, ANTHROPIC, or GEMINI
# Provider API Keys (add your key for the chosen provider)
OPENAI_API_KEY=your-openai-api-key
ANTHROPIC_API_KEY=your-anthropic-api-key
GEMINI_API_KEY=your-gemini-api-keyOpcionalmente, puede especificar qué modelo utilizar para cada proveedor:
# Optional: Override the default models
OPENAI_MODEL=gpt-4-turbo
ANTHROPIC_MODEL=claude-3-sonnet-20240229
GEMINI_MODEL=gemini-1.5-flash-previewLa herramienta code_review procesa el código utilizando Repomix para aplanar la estructura del repositorio
El código se formatea y se fragmenta, si es necesario, para ajustarse a los límites del contexto LLM.
Se genera un mensaje detallado en función de las áreas de enfoque y el nivel de detalle.
El mensaje y el código se envían directamente a la API LLM del proveedor elegido.
La respuesta LLM se analiza en un formato estructurado
La revisión se devuelve como un objeto JSON con problemas, fortalezas y recomendaciones.
La implementación incluye lógica de reintento para mayor resiliencia ante errores de API y formato adecuado para garantizar que se incluya el código más relevante en la revisión.
La revisión del código se devuelve en un formato JSON estructurado:
{
"summary": "Brief summary of the code and its purpose",
"issues": [
{
"type": "SECURITY|PERFORMANCE|QUALITY|MAINTAINABILITY",
"severity": "HIGH|MEDIUM|LOW",
"description": "Description of the issue",
"line_numbers": [12, 15],
"recommendation": "Recommended fix"
}
],
"strengths": ["List of code strengths"],
"recommendations": ["List of overall recommendations"]
}Instituto Tecnológico de Massachusetts (MIT)
Use this tool when you need to analyze a code repository structure without performing a detailed review. This tool flattens the repository into a textual representation and is ideal for getting a high-level overview of code organization, directory structure, and file contents. Use it before code_review when you need to understand the codebase structure first, or when a full code review is not needed.
| Name | Required | Description | Default |
|---|---|---|---|
| repoPath | Yes | Path to the repository to analyze | |
| specificFiles | No | Specific files to analyze | |
| fileTypes | No | File types to include in the analysis |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the tool's behavior ('flattens the repository into a textual representation') and output format ('high-level overview'), which is helpful. However, it doesn't mention potential limitations like file size constraints, processing time, error conditions, or authentication requirements that would be important for a tool analyzing code repositories.
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 efficiently structured with three sentences that each serve a distinct purpose: stating the tool's purpose, explaining its behavior, and providing usage guidelines. There's no redundant information, and the most important guidance (when to use the tool) is front-loaded. Every sentence earns its place by adding value.
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's moderate complexity (3 parameters, no output schema, no annotations), the description provides good contextual coverage. It explains the tool's purpose, behavior, and relationship to the sibling tool. However, without annotations or output schema, it could benefit from more detail about what the 'textual representation' output actually contains and any limitations or requirements for using the tool effectively.
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 100%, so the schema already documents all three parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. It mentions analyzing 'specific files' and 'file types' generally but provides no additional syntax, format, or usage guidance for these parameters. The baseline score of 3 is appropriate when the schema does the heavy lifting.
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 clearly states the tool's purpose: 'analyze a code repository structure without performing a detailed review' and 'flattens the repository into a textual representation'. It specifies the verb ('analyze'), resource ('code repository'), and scope ('high-level overview of code organization, directory structure, and file contents'), distinguishing it from the sibling tool 'code_review' which implies more detailed analysis.
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 provides explicit guidance on when to use this tool: 'Use this tool when you need to analyze a code repository structure without performing a detailed review' and 'Use it before code_review when you need to understand the codebase structure first, or when a full code review is not needed'. It clearly differentiates from the alternative sibling tool 'code_review' and specifies both appropriate and inappropriate contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this tool when you need a comprehensive code review with specific feedback on code quality, security issues, performance problems, and maintainability concerns. This tool performs in-depth analysis on a repository or specific files and returns structured results including issues found, their severity, recommendations for fixes, and overall strengths of the codebase. Use it when you need actionable insights to improve code quality or when evaluating a codebase for potential problems.
| Name | Required | Description | Default |
|---|---|---|---|
| repoPath | Yes | Path to the repository to analyze | |
| specificFiles | No | Specific files to review | |
| fileTypes | No | File types to include in the review | |
| detailLevel | No | Level of detail for the code review | |
| focusAreas | No | Areas to focus on during the code review |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the tool's behavior ('performs in-depth analysis', 'returns structured results including issues found, their severity, recommendations') but lacks details on permissions needed, rate limits, error handling, or whether it modifies the codebase. It adequately covers the core operation but misses some behavioral traits.
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 appropriately sized and front-loaded, with the first sentence clearly stating the purpose and key features. It uses two sentences efficiently, though the second sentence could be slightly more concise by combining some clauses without losing clarity.
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 complexity of a code review tool with 5 parameters, no annotations, and no output schema, the description is fairly complete. It covers purpose, usage, and output structure, but could benefit from more details on behavioral aspects like execution time or limitations to fully compensate for the lack of annotations and output schema.
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?
The schema description coverage is 100%, so the schema already documents all parameters. The description adds context by mentioning 'specific files' and 'focus areas' like security and performance, which align with parameters, but doesn't provide additional semantics beyond what the schema offers. Baseline 3 is appropriate as the schema does the heavy lifting.
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 clearly states the tool's purpose with specific verbs ('perform in-depth analysis', 'returns structured results') and resources ('repository or specific files'), distinguishing it from the sibling tool 'analyze_repo' by emphasizing comprehensive review with specific feedback areas like security, performance, and maintainability.
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 when to use the tool ('when you need a comprehensive code review', 'when you need actionable insights to improve code quality or when evaluating a codebase for potential problems'), providing clear context and distinguishing it from alternatives without being misleading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
analyze_repocode_reviewScored across 2 tools
The two tools have clearly distinct purposes: analyze_repo provides a high-level structural overview, while code_review offers detailed analysis with specific feedback. There is no overlap in functionality, and the descriptions explicitly differentiate when to use each tool.
Both tools follow a consistent verb_noun naming pattern (analyze_repo and code_review), using snake_case throughout. The naming is predictable and aligns well with their described functionalities.
With only 2 tools, the server feels thin for a 'Code Review MCP Server' domain. While the tools cover analysis and review, the scope suggests potential gaps in operations like managing reviews, tracking issues, or integrating with version control, making the set appear incomplete for the stated purpose.
The tool set is severely incomplete for code review workflows. It lacks essential operations such as creating, updating, or deleting reviews; commenting on code; or handling pull requests. Agents will face dead ends when trying to perform common code review tasks beyond basic analysis.
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
AI-powered codebase analysis — call graphs, security, dead code, complexity. 150+ tools.
Code review by AI models from different companies, usually two. Shows where they agree and disagree.
AI code review for GitHub PRs with an MCP autofix loop for Claude Code and Cursor
