RepoPilot MCP는 작은 Python Model Context Protocol 서버 부트스트랩입니다. 향후 GitHub 저장소 도구를 위한 프로덕션 스타일의 시작점으로 구성되어 있지만, 아직 GitHub API 기능을 구현하지는 않습니다.
src/ 패키지 구조
uv 호환 의존성이 포함된 pyproject.toml
타입이 지정된 환경 설정
mock 단위 테스트가 포함된 격리된 GitHub REST API 클라이언트
프로세스 로깅 설정
디스커버리 확인용 무해한 health MCP 도구 하나
설정 및 MCP 부트스트랩 동작에 대한 pytest 커버리지
.env.example, .gitignore, GitHub Actions CI, MIT 라이선스
Related MCP server: MCP Server - Placeholder Implementation
Python 3.11+
uv sync --dev로컬 구성의 경우 .env.example을 .env로 복사하고 값을 로컬에서 편집하세요. .env나 실제 자격 증명을 커밋하지 마세요. GITHUB_TOKEN은 내부 GitHub REST API 클라이언트에서 사용되며 아직 MCP 도구를 통해 노출되지 않습니다.
테스트 실행:
uv run pytest로컬 검사 모음 실행:
.\scripts\check.ps1MCP Inspector 시작:
.\scripts\dev-inspector.ps1stdio를 통해 서버를 직접 실행:
uv run repopilot-mcpsrc/repopilot/
__init__.py
config.py
github_client.py
server.py
tests/
test_github_client.py
test_server.py구현됨:
health MCP 도구
환경 변수에서 로드되는 설정 모델
재사용 가능한 GitHub REST API 클라이언트 계층
로깅 부트스트랩
구현되지 않음:
저장소, 파일, 이슈 또는 풀 리퀘스트 도구
쓰기 가능한 GitHub 작업
Return basic server health and safety posture.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0healthScored across 1 tool
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.
Create, deploy, and operate MCP servers directly from your GitHub repositories.
Guarded MCP server for agent-readable business truth, provenance, readiness, and discovery.
