Repomix와 LLM을 사용하여 코드 검토를 수행하는 맞춤형 MCP 서버입니다.
Repomix를 사용하여 코드베이스를 평면화합니다.
대규모 언어 모델을 사용하여 코드 분석
특정 문제 및 권장 사항을 포함한 구조화된 코드 검토를 받으세요
여러 LLM 공급자(OpenAI, Anthropic, Gemini) 지원
대규모 코드베이스에 대한 청킹을 처리합니다.
Related MCP server: Code Review MCP Server
지엑스피1
.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(Model Context Protocol)를 구현하며 모든 MCP 클라이언트와 함께 사용할 수 있습니다.
# Start the server
node build/index.js서버는 두 가지 주요 도구를 제공합니다.
analyze_repo : Repomix를 사용하여 코드베이스를 평면화합니다.
code_review : LLM을 사용하여 코드 검토를 수행합니다.
이 서버는 다양한 코드 분석 요구 사항에 맞춰 두 가지 도구를 제공합니다.
다음과 같은 경우 이 도구를 사용하세요.
코드베이스의 구조와 구성에 대한 개략적인 개요를 얻으세요
초기 분석을 위해 저장소를 텍스트 표현으로 평면화합니다.
자세한 검토 없이 디렉토리 구조와 파일 내용을 이해합니다.
보다 심층적인 코드 검토를 준비하세요
추가 분석을 위해 관련 파일을 식별하기 위해 코드베이스를 빠르게 스캔합니다.
예시 상황:
"이 저장소를 검토하기 전에 구조를 이해하고 싶습니다."
"이 코드베이스에 어떤 파일과 디렉토리가 있는지 보여주세요"
"코드의 구성을 이해하려면 코드를 평면적으로 보여주세요."
다음과 같은 경우 이 도구를 사용하세요.
포괄적인 코드 품질 평가 수행
특정 보안 취약점, 성능 병목 현상 또는 코드 품질 문제를 식별합니다.
코드 개선을 위한 실행 가능한 권장 사항을 얻으세요
문제에 대한 심각도 등급을 포함한 자세한 검토를 수행합니다.
모범 사례에 맞춰 코드베이스 평가
예시 상황:
"이 코드베이스의 보안 취약점을 검토하세요"
"이러한 특정 JavaScript 파일의 성능을 분석합니다"
"이 저장소에 대한 자세한 코드 품질 평가를 해주세요"
"내 코드를 검토하고 유지 관리성을 개선하는 방법을 알려주세요"
매개변수를 사용하는 경우:
specificFiles : 전체 저장소가 아닌 특정 파일만 검토하려는 경우
fileTypes : 특정 파일 확장자(예: .js, .ts)에 초점을 맞추고 싶을 때
detailLevel : 빠른 개요를 원하시면 '기본'을, 심층 분석을 원하시면 '상세'를 사용하세요.
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"]
}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
