RepoPilot MCP
Based on the schema, the server exposes health; per the README, it also provides read-only GitHub inspection and two explicit write tools.
health: returns basic server health and safety posture.Repository content:
list_directory,get_filefor browsing trees and reading UTF-8 files (≤100KB).Issues:
list_issues,get_issuefor browsing/fetching issues (PRs excluded).Pull requests:
list_pull_requests,get_pull_request,get_pull_request_filesfor PR details and changed-file patches.Writes:
create_issue,comment_on_issue— require a token, validate input, and are never retried automatically.
Provides tools for inspecting GitHub repositories, including listing directory contents, reading text files, browsing issues and pull requests, viewing changed files and patches, and limited write actions such as creating issues and commenting on issues.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@RepoPilot MCPrun a health check"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
RepoPilot MCP
RepoPilot MCP is a small Python Model Context Protocol server for safe, GitHub repository inspection with deliberately limited write actions.
RepoPilot is an educational, intentionally smaller implementation for learning how AI agents, MCP, and GitHub's REST API fit together. GitHub maintains an official production GitHub MCP server; RepoPilot does not replace it.
Why I Built This
To build and evaluate an MCP server incrementally: typed GitHub integration, LLM-friendly tool contracts, bounded context, deliberate write safety, and deterministic tests rather than a single opaque agent integration.
Related MCP server: MCP Server - Placeholder Implementation
Architecture
flowchart LR
Host[AI host] --> Client[MCP client]
Client --> Server[RepoPilot MCP server]
Server --> API[Typed GitHub client]
API --> GitHub[GitHub REST API]Requests flow from an AI host through MCP tool selection into normalized client responses; raw GitHub payloads and tokens are not returned to the model.
Included
src/package layoutpyproject.tomlwith uv-compatible dependenciestyped environment configuration
isolated GitHub REST API client with mocked unit tests
process logging configuration
bounded directory and UTF-8 text-file inspection MCP tools
normalized, read-only GitHub issue inspection MCP tools
bounded, read-only pull-request and changed-file inspection MCP tools
pytest coverage for configuration and MCP bootstrap behavior
.env.example,.gitignore, GitHub Actions CI, and MIT license
Requirements
Python 3.11+
Setup
uv sync --devFor local configuration, copy .env.example to .env and edit values locally.
Never commit .env or real credentials. GITHUB_TOKEN is optional for public
repositories, and supports private-repository access and higher API limits.
Development
CI runs locked dependency installation, Ruff formatting/linting, and the isolated pytest suite on Python 3.11 and 3.12. It has read-only repository permissions and never requires GitHub or LLM credentials.
Run tests:
uv run pytestRun the local check suite:
.\scripts\check.ps1Start the MCP Inspector:
.\scripts\dev-inspector.ps1Run the server directly over stdio:
uv run repopilot-mcpSee INTEGRATION.md for a client configuration example and the separation between automated MCP checks and an optional manual live smoke test.
Project Structure
src/repopilot/
__init__.py
config.py
github_client.py
server.py
tests/
test_github_client.py
test_server.pyCurrent Scope
MCP Tools
Category | Tools |
Repository content |
|
Issues |
|
Pull requests |
|
Explicit writes |
|
Read tools inspect only. Write tools have immediate side effects, require a token, reject empty input, and are never retried automatically.
Implemented, read-only tools:
list_directory(owner, repo, path="", ref=None, limit=50): start here to inspect a repository tree. Results are normalized, sorted with directories first, and capped at 100 entries. If a directory is larger than the requested limit, the response explicitly reportstruncated: trueand its total count.get_file(owner, repo, path, ref=None): use after a file path is known. Returns complete UTF-8 text only; it rejects directories, binary/non-UTF-8 content, unavailable encodings, and files over 100,000 bytes. It never silently truncates file content.
The server uses GitHub's Contents API only. It does not clone repositories and does not provide editing or other write-capable GitHub operations.
Issue inspection uses GitHub's Issues API and remains read-only:
list_issues(owner, repo, state="open", labels=None, assignee=None, page=1, limit=30)browses a bounded, filterable page of issues when the issue number is unknown. GitHub includes pull requests in this endpoint, so RepoPilot excludes them and reports how many were excluded.get_issue(owner, repo, issue_number)retrieves one known issue. It rejects a pull request number rather than presenting it as an issue; pull-request tools will be added separately.
Pull-request inspection is also read-only:
list_pull_requests(owner, repo, ...)browses bounded PR summaries when an exact pull-request number is unknown.get_pull_request(owner, repo, pull_number)returns a known PR's branches, draft/mergeability state, and change totals.get_pull_request_files(owner, repo, pull_number, ...)returns changed-file metadata and available patches. Patches over 12,000 characters are explicitly truncated; unavailable patches remainnull.
Write Safety
The only write tools are create_issue and comment_on_issue. Both require a
GITHUB_TOKEN, validate their inputs before contacting GitHub, and are never
automatically retried. They should be used only with explicit user instruction.
GitHub's issue-comment endpoint also supports pull-request conversation comments;
this does not add review, approval, merge, or other pull-request write support.
Reliability and Security
Secrets are read only from
GITHUB_TOKEN; RepoPilot neither logs nor returns it.Requests use the configured timeout and distinguish authentication, permission, rate-limit, not-found, validation, server, timeout, and network failures.
RepoPilot does not retry requests automatically. This deliberately prevents duplicate issue or comment creation when a write response is uncertain.
Unit tests use mocked HTTP only; CI never needs GitHub or LLM credentials.
Evaluation
evaluation_cases.json contains 15 provider-neutral cases covering discovery,
files, issues, PRs, tool choice, unknown information, and permitted writes.
Record outcomes from a baseline model and the same model with RepoPilot, then
score them with repopilot.evaluation.score. The harness reports accuracy,
completion, hallucination, tool selection, calls, latency, and errors; it does
not call an LLM or fabricate benchmark results.
Limitations and Future Work
RepoPilot does not support OAuth, GraphQL, remote transport, file mutation, branch creation, PR creation/merging, workflow execution, or permission edits. Potential extensions remain deliberately out of scope until explicitly chosen.
Demo
See DEMO.md for a concise portfolio/demo sequence. See INTEGRATION.md for client setup and the manual smoke test.
Available Tools
1 toolhealthA
Return basic server health and safety posture.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates a read-only action ('Return') but says nothing about authentication, rate limits, or what 'safety posture' concretely includes. The disclosure is minimal.
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?
A single, front-loaded sentence with no filler. Every word contributes to conveying the tool's purpose.
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 is a simple health check with no parameters and an output schema, the description provides adequate context. The phrase 'safety posture' could be more precise, but the overall scope is clear.
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 tool has zero parameters and schema coverage is 100% (empty). No parameter explanation is needed; the description's simplicity is appropriate for a parameterless interface.
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 identifies the action ('Return') and the resource ('basic server health and safety posture'). It is specific enough to understand the tool's purpose, though the term 'safety posture' is a bit vague. No sibling tools exist, so differentiation is not applicable.
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 does not explicitly state when to use this tool or when to avoid it. The health-check nature implies usage for server status and safety monitoring, but no alternative tools or exclusions are mentioned.
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 tool update
v0.1.0- First observed
health
TDQS
Only one tool exists, so there is no possibility of ambiguity or overlap between tools.
With a single tool named 'health', the naming is unambiguous and internally consistent.
The server provides only one trivial health-check tool, which is an extreme under-provisioning for a server presumably intended for repository management.
The sole tool only reports health status, leaving no functionality for actual repository operations, making the surface severely incomplete for the stated domain.
Maintenance
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
Create, deploy, and operate MCP servers directly from your GitHub repositories.
Guarded MCP server for agent-readable business truth, provenance, readiness, and discovery.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceA production-ready Python template for building MCP servers with enterprise features including registry integration, configuration management, structured logging, and extensible patterns for tools, resources, and prompts.MIT
- FlicenseNot gradedqualityDmaintenanceAn MCP server implementation in Python with placeholder tools, deployable to Azure Web App via GitHub Actions. Supports STDIO, HTTP REST, and WebSocket interfaces.-
- AlicenseCqualityCmaintenanceA production-ready MCP server for GitHub operations, providing tools for repository management, issues, pull requests, and more via both MCP stdio and REST API.27MIT
- AlicenseAqualityBmaintenanceAn MCP server that provides operational tooling over the GitHub API — issue triage, PR review monitoring, repo health audits, and team access reviews.111MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/ompatelz/Omi-GithubMCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server