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サーバーは 2 つの主要なツールを公開します。
analyze_repo : Repomix を使用してコードベースをフラット化する
code_review : LLMを使用してコードレビューを実行します
このサーバーは、異なるコード分析ニーズに対応する 2 つの異なるツールを提供します。
次の場合にこのツールを使用します。
コードベースの構造と構成の概要を把握する
初期分析のためにリポジトリをテキスト表現にフラット化する
詳細な確認なしでディレクトリ構造とファイルの内容を理解する
より詳細なコードレビューの準備
コードベースを素早くスキャンして、さらに分析する必要がある関連ファイルを特定します。
例:
「レビューする前にこのリポジトリの構造を理解したい」
「このコードベースに含まれるファイルとディレクトリを表示してください」
「コードの構成を理解するために、コードを平面的に表示してください」
次の場合にこのツールを使用します。
包括的なコード品質評価を実行する
特定のセキュリティ脆弱性、パフォーマンスのボトルネック、コード品質の問題を特定する
コードを改善するための実用的な推奨事項を入手する
問題の重大度評価を含む詳細なレビューを実施する
ベストプラクティスに照らしてコードベースを評価する
例:
「このコードベースのセキュリティ上の脆弱性を確認してください」
「これらの特定の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> : 詳細レベル（デフォルト: details）
--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 (デフォルト: 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
