Skip to main content
Glama
ziiyue-eee

RepoPilot MCP Server

by ziiyue-eee
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

RepoPilot

RepoPilot is a verifiable code agent for Python repositories. It turns an issue into an evidence-backed plan, optionally asks an OpenAI-compatible model for a unified diff, and runs the reviewed patch in an isolated workspace. Every retrieval, tool call, patch, and test result is retained as a compact audit trace.

Python FastAPI MCP Tests

Why this is not another chat-with-your-code demo

  • AST-aware indexing: extracts classes, functions, methods, signatures, imports, and call edges instead of splitting source into arbitrary chunks.

  • Hybrid retrieval: combines issue-token relevance with symbol names, file paths, and call-graph evidence.

  • Bounded workflow: retrieval, planning, human review, patch validation, isolated execution, and test verification have explicit states.

  • Standard tools: repository map, symbol search, file reads, and reference lookup are exposed through the official MCP Python SDK.

  • Guarded execution: patch size, paths, file types, and number of changed files are validated before a copy of the repository is modified.

  • Objective evaluation: a JSONL benchmark runner reports Recall@K and mean reciprocal rank for related-file retrieval.

Related MCP server: code-intelligence-mcp

Architecture

flowchart LR
    UI[Web console] --> API[FastAPI]
    API --> IDX[Python AST indexer]
    IDX --> STORE[Persistent JSON indexes]
    API --> RET[Hybrid retriever]
    RET --> PLAN[Bounded planner]
    PLAN --> LLM[OpenAI-compatible LLM]
    PLAN --> MCP[MCP code tools]
    LLM --> REVIEW[Human patch review]
    REVIEW --> POLICY[Patch policy]
    POLICY --> WS[Isolated workspace]
    WS --> TEST[Fixed pytest runner]
    TEST --> TRACE[Auditable task trace]

The implementation deliberately separates read-only code tools from patch execution. An MCP client can inspect code without receiving a general-purpose shell tool.

Quick start

cd D:\ai-projects\repopilot
python -m venv .venv
.\.venv\Scripts\python.exe -m pip install -e ".[dev]"
Copy-Item .env.example .env
.\.venv\Scripts\python.exe -m repopilot

Open http://127.0.0.1:8765.

The repository includes a deliberately broken demo at examples/buggy_calculator. Index that directory, then use this issue:

divide should raise a clear ValueError when right is zero

If no model is running, create the plan and paste this reviewed patch into the execution panel:

diff --git a/calculator.py b/calculator.py
--- a/calculator.py
+++ b/calculator.py
@@ -1,2 +1,4 @@
 def divide(left: float, right: float) -> float:
+    if right == 0:
+        raise ValueError("right must not be zero")
     return left / right

The patch is applied only to workspaces/<task-id>; the indexed source repository is not modified.

Model configuration

RepoPilot uses the OpenAI-compatible /chat/completions API. The defaults target an Ollama installation:

REPOPILOT_LLM_BASE_URL=http://127.0.0.1:11434/v1
REPOPILOT_LLM_MODEL=qwen2.5-coder:7b
REPOPILOT_LLM_API_KEY=ollama

Planning has a deterministic fallback when the model is offline. Patch generation requires a configured model because silently inventing a patch would make the demo impossible to trust.

MCP server

Start the stdio MCP server:

.\.venv\Scripts\repopilot-mcp.exe

Tools:

  • repository_map

  • search_symbol

  • read_file

  • find_references

Each tool requires the ID of a previously indexed repository.

Evaluation

After indexing the demo repository, copy its ID from the UI or GET /api/repositories and run:

.\.venv\Scripts\repopilot-eval.exe <repository-id> examples\benchmark.jsonl --k 5

Benchmark cases use one JSON object per line:

{"id":"case-1","issue":"describe the failure","expected_files":["module.py"]}

The report includes per-case retrieved files, Recall@K, reciprocal rank, mean Recall@K, and MRR. This makes retrieval changes measurable and suitable for ablation experiments.

API overview

Method

Endpoint

Purpose

GET

/api/health

Service health

POST

/api/repositories

Index a local Python repository

GET

/api/repositories

List indexed repositories

POST

/api/repositories/{id}/search

Search symbols

POST

/api/repositories/{id}/tasks

Analyze an issue and create a plan

POST

/api/tasks/{id}/generate-patch

Generate a policy-checked diff

POST

/api/tasks/{id}/execute

Execute a reviewed patch and tests

GET

/api/tasks/{id}

Read the plan, trace, diff, and test result

Interactive API documentation is available at http://127.0.0.1:8765/docs.

Safety model

The local executor is intentionally constrained:

  • source repositories are copied before modification;

  • patch paths must remain inside the workspace;

  • at most five text/source files and 100 KB may be changed;

  • test execution is fixed to python -m pytest -q;

  • subprocesses have a timeout and capped captured output;

  • network proxy variables and unrelated environment variables are not passed;

  • task events store concise action summaries, not private chain-of-thought.

The local executor is a development safety boundary, not a hostile-code sandbox. Run untrusted repositories only inside a disposable VM or container. See SECURITY.md.

Development

.\.venv\Scripts\python.exe -m pytest --cov=repopilot --cov-report=term-missing

The Git history is organized as reviewable implementation milestones:

  1. service scaffold;

  2. AST indexing and retrieval;

  3. bounded planning and MCP tools;

  4. guarded patch execution;

  5. evaluation, UI, deployment, and documentation.

Available Tools

4 tools
find_referencesC

Find indexed call sites for a symbol.

ParametersJSON Schema
NameRequiredDescriptionDefault
symbol_nameYes
repository_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It does not disclose whether the tool is read-only, safe, or requires specific permissions. The term 'indexed' implies a safe operation, but this is not explicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, making it concise. However, it omits important behavioral and usage details, so it is not appropriately sized for the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return value details are not required. However, the description lacks guidance on when to use the tool and what the output represents (e.g., file locations or code snippets). Adequate but not comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%. The description adds no information about the two required parameters (repository_id, symbol_name) beyond their names, which are self-explanatory but still lacking context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Find indexed call sites for a symbol' clearly states the verb (find) and the specific resource (indexed call sites). It differentiates from sibling tools like repository_map, search_symbol, and read_file by focusing on call site retrieval.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. For example, it does not explain when to prefer find_references over search_symbol or how it differs from repository_map.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_fileC

Read a bounded line range from a repository file.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYes
end_lineNo
start_lineNo
repository_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

C2.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits. It only mentions 'bounded line range', but omits critical details such as error handling, performance implications, file size limits, or what happens if line range exceeds file length. This is insufficient for safe and effective tool usage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with no unnecessary words. It is front-loaded with the key action. However, its brevity sacrifices important details, making it borderline under-specified for a tool with multiple parameters.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given four parameters, no annotations, and an output schema, the description is too sparse. It does not explain the return value (despite an output schema), default behaviors, or edge cases. The agent lacks sufficient context to invoke the tool reliably.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the tool description adds no meaning to the four parameters (path, start_line, end_line, repository_id). It only hints at line range semantics but does not explain repository_id or path, leaving the agent reliant on parameter names alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Read') and resource ('repository file'), and specifies it reads a bounded line range, which conveys a specific scope. However, it does not explicitly distinguish from sibling tools like repository_map or search_symbol, missing the chance to clarify when to use this tool over alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus its siblings (repository_map, search_symbol, find_references). The description does not mention prerequisites, context, or exclusions, leaving the agent to infer usage without clear direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

repository_mapB

Return files and symbols from an indexed repository.

ParametersJSON Schema
NameRequiredDescriptionDefault
repository_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It suggests a read operation by using 'return', but does not explicitly state read-only behavior, permissions, or potential side effects. Minimal disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is concise and directly states the tool's purpose. Every word is necessary, and it is front-loaded with the key action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has a single parameter and an output schema, the description is somewhat complete but lacks details like what 'files and symbols' specifically means and whether the repository must be indexed. The output schema may cover return format, but the description could be more informative for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must add meaning but it does not. The only parameter 'repository_id' is not explained beyond its type. No additional context about the parameter's role or constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns files and symbols from an indexed repository, which distinguishes it from siblings like search_symbol (search for symbols) and read_file (read a file). The verb 'return' and resource 'files and symbols from an indexed repository' are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like search_symbol or find_references. The description lacks any context about use cases or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_symbolC

Search symbols with lexical and code-structure ranking.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
queryYes
repository_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose key behaviors. It only mentions ranking without explaining what that entails (e.g., algorithmic details, side effects, or result structure). The behavior is opaque.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise, but it lacks structure and does not front-load critical information. Every word earns its place, but the overall information density is low.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has three parameters and no annotations, the description is insufficient. It does not explain the output (despite an output schema existing) or the ranking mechanism, leaving significant gaps for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, yet the description adds no information about the parameters (repository_id, query, limit). The agent cannot infer what values are expected or how they affect the search.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Search' and the resource 'symbols', adding a qualifier about lexical and code-structure ranking. This distinguishes it from sibling tools like read_file and find_references, though it does not explicitly contrast them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions, leaving the agent without decision support.

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. Dates show when Glama detected each change.

  1. 4 tool updatesv0.1.0
    • First observedfind_references
    • First observedread_file
    • First observedrepository_map
    • First observedsearch_symbol
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.2/5.0
Disambiguation5/5

Each tool targets a distinct operation: repository_map provides an overview of files and symbols, search_symbol finds specific symbols, read_file reads file content, and find_references tracks symbol usage. There is no ambiguity or overlap among them.

Naming Consistency4/5

Three tools follow a consistent verb_noun pattern (search_symbol, read_file, find_references), but repository_map deviates slightly as noun_noun. However, all names use snake_case and are clear.

Tool Count5/5

With only 4 tools, the server is well-scoped for code navigation tasks. Each tool serves a necessary function without redundancy or bloat.

Completeness4/5

The tool set covers core code understanding: overview (repository_map), search (search_symbol), reading (read_file), and reference tracking (find_references). A minor gap is lack of directory listing, but repository_map likely provides it.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Satori

    ham-zax
    A
    license
    Not graded
    quality
    B
    maintenance
    Agent-safe code retrieval MCP server that indexes repositories and provides semantic search, file navigation, call graph analysis, and bounded file reading tools for coding agents.
    3,448,419
    3
    AGPL 3.0

  • local-code-intel-mcp

    tungvt93
    F
    license
    Not graded
    quality
    D
    maintenance
    Provides code intelligence by indexing source code into SQLite and offering MCP tools for symbol search, flow tracing, and context retrieval to assist with code navigation and understanding.
    -

  • ast-outline-mcp

    Xayan
    A
    license
    A
    quality
    A
    maintenance
    Enables AI coding agents to efficiently explore codebases by providing structural outlines, module digests, symbol bodies, and AST-aware grep via MCP.
    4
    17
    1
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ziiyue-eee/RepoPilot'

If you have feedback or need assistance with the MCP directory API, please join our Discord server