使用 Repomix 和 LLM 执行代码审查的自定义 MCP 服务器。
使用 Repomix 扁平化代码库
使用大型语言模型分析代码
获取包含具体问题和建议的结构化代码审查
支持多个 LLM 提供商（OpenAI、Anthropic、Gemini）
处理大型代码库的分块
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 build基于.env.example模板在根目录下创建.env文件：
cp .env.example .env编辑.env文件以设置您首选的 LLM 提供程序和 API 密钥：
# LLM Provider Configuration
LLM_PROVIDER=OPEN_AI
OPENAI_API_KEY=your_openai_api_key_here代码审查服务器实现了模型上下文协议（MCP），可以与任何 MCP 客户端一起使用：
# Start the server
node build/index.js该服务器公开两个主要工具：
analyze_repo ：使用 Repomix 扁平化代码库
code_review ：使用 LLM 执行代码审查
该服务器针对不同的代码分析需求提供了两种不同的工具：
当您需要执行以下操作时，请使用此工具：
获取代码库结构和组织的高级概述
将存储库扁平化为文本表示形式，以便进行初步分析
无需详细审查即可了解目录结构和文件内容
准备进行更深入的代码审查
快速扫描代码库以识别相关文件以供进一步分析
示例情况：
“我想在审查之前先了解一下这个存储库的结构”
“告诉我这个代码库中有哪些文件和目录”
“给我一个代码的平面视图来了解它的组织”
当您需要执行以下操作时，请使用此工具：
执行全面的代码质量评估
识别特定的安全漏洞、性能瓶颈或代码质量问题
获得改进代码的可行建议
对问题进行详细审查，并进行严重程度评级
根据最佳实践评估代码库
示例情况：
“检查此代码库是否存在安全漏洞”
“分析这些特定 JavaScript 文件的性能”
“请给我一份关于这个存储库的详细代码质量评估”
“检查我的代码并告诉我如何提高其可维护性”
何时使用参数：
specificFiles ：当您只想查看某些文件而不是整个存储库时
fileTypes ：当你想关注特定的文件扩展名时（例如 .js、.ts）
detailLevel ：使用“basic”进行快速概览或使用“detailed”进行深入分析
focusAreas ：当你想优先考虑某些方面（安全性、性能等）时
为了测试目的，您可以使用附带的 CLI 工具：
node build/cli.js <repo_path> [options]选项：
--files <file1,file2> ：需要审查的特定文件
--types <.js,.ts> ：要包含在审核中的文件类型
--detail <basic|detailed> ：详细程度（默认值：详细）
--focus <areas> ：需要关注的领域（安全性、性能、质量、可维护性）
例子：
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 inspector代码审查服务器直接与多个 LLM 提供程序 API 集成：
OpenAI （默认值：gpt-4o）
人类学（默认值：claude-3-opus-20240307）
双子座（默认：gemini-1.5-pro）
在.env文件中配置您首选的 LLM 提供程序：
# 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-key您可以选择指定每个提供程序要使用的模型：
# Optional: Override the default models
OPENAI_MODEL=gpt-4-turbo
ANTHROPIC_MODEL=claude-3-sonnet-20240229
GEMINI_MODEL=gemini-1.5-flash-previewcode_review工具使用 Repomix 处理代码，以扁平化存储库结构
如果需要，代码将被格式化和分块以适应 LLM 上下文限制
根据重点领域和详细程度生成详细提示
提示和代码将直接发送到您选择的提供商的 LLM API
LLM 响应被解析为结构化格式
评论以 JSON 对象的形式返回，其中包含问题、优势和建议
该实现包括重试逻辑，用于抵御 API 错误和适当的格式，以确保在审查中包含最相关的代码。
代码审查以结构化的 JSON 格式返回：
{
"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"]
}麻省理工学院
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
