GitHub Intelligence MCP server
2026년 10월 21일 커밋Provides AI clients with structured, validated JSON data to investigate and analyze GitHub repositories, including issues, pull requests, and commits.
다른 이름 Dayyan-Saeed/Github-Intelligence-Mcp
- 스타
- 2
- Tools
- 7
- 다운로드, 30일
- —
- 최신 버전
- —
- 마지막 커밋
- 2026년 10월 21일
- 라이선스
- MIT
GitHub Intelligence MCP란?
GitHub Intelligence은(는) MCP server입니다. Provides AI clients with structured, validated JSON data to investigate and analyze GitHub repositories, including issues, pull requests, and commits. 7개 도구를 제공합니다. 예: get_repository, search_repositories, get_issues.
프로젝트 README에서 생성된 요약
GitHub Intelligence MCP server 정보
Analyzing GitHub repository health and metrics from within AI clients like Claude, Cursor, or OpenCode is what this server enables. It provides developers and AI agents with deterministic, validated JSON data instead of relying on an LLM to guess repository statistics. By handling the heavy lifting of fetching and structuring data, it allows the model to focus on reasoning rather than error-prone calculations.
Users run this server locally via stdio using Python 3.12 and uv. To connect, you must provide a GitHub Personal Access Token through a GITHUB_TOKEN environment variable. The server offers read-only tools such as get_repository, search_repositories, get_issues, get_pull_requests, get_recent_commits, get_contributors, and get_releases. All list operations are safely bounded with a limit between 1 and 100 items to ensure stability.
This tool is designed for those who need reliable facts about metadata, contributors, and release history. It uses Pydantic models to ensure a stable output contract, meaning the data returned is always structured and predictable. It also includes built-in error handling to translate GitHub API issues into clear, user-safe messages.
활용 사례
- 1Compare repository activityAsk an AI to compare the star counts, issue health, and recent activity between two different repositories.
- 2Identify top contributorsRequest a list of the most active developers contributing to a specific project.
- 3Track recent software releasesFind out what has been merged or released in a repository recently.
- 4Audit repository issuesSearch for and analyze issues within a repository filtered by specific labels or states.
프로젝트의 README를 바탕으로 작성되었습니다. 모든 활용 사례는 해당 내용의 인용문과 대조하여 확인합니다.
GitHub Intelligence MCP 도구 7
README에서 감지됨get_repositorysearch_repositoriesget_issuesget_pull_requestsget_recent_commitsget_contributorsget_releases
| get_repository | — | |
| search_repositories | — | |
| get_issues | — | |
| get_pull_requests | — | |
| get_recent_commits | — | |
| get_contributors | — | |
| get_releases | — |
구성
GITHUB_TOKEN
| 이름 | 설명 | 유형 |
|---|---|---|
| GITHUB_TOKEN | — |
자동 검사
2026년 11월 14일에 실행됨전체 보고서 →아직 인증되지 않았습니다. 서버는 80점 이상의 점수, 심각한 결함 없음, 그리고 검사에 충분한 데이터를 갖추어야 합니다. 검사 방식 · 점수를 높이기 위해 수정할 항목
- 소스 저장소 연결 및 접근 가능dayyan-saeed/github-intelligence-mcp is public and reachablegithub.com/dayyan-saeed/github-intelligence-mcp ↗통과
- 패키지가 이 저장소를 소스로 명시검사되지 않음
- 빌드 출처(Sigstore 증명)검사되지 않음
- 오픈 소스 라이선스 (OSI)MITspdx.org/licenses/MIT.html ↗통과
- 최근 1년 내 커밋 또는 릴리스Last commit or release 2026-10-21github.com/dayyan-saeed/github-intelligence-mcp ↗통과
- OpenSSF Scorecard검사되지 않음
- 패키지 이름이 인기 패키지와 유사하지 않음검사되지 않음
- 패키지 및 해당 종속성에 중요한 보안 권고 없음검사되지 않음
- 모델에 대한 숨겨진 지침 없음7 tool descriptions and the README read; no override phrases, credential paths or hidden characters통과
- 파괴적인 도구에 라벨 표시됨No tool named like delete, drop or exec통과
- 원격 엔드포인트가 MCP 핸드셰이크에 응답검사되지 않음
README
GitHub에서 보기GitHub Intelligence MCP
Live Dashboard: https://github-intelligence-mcp-ashy.vercel.app/
An intelligent, structured MCP (Model Context Protocol) server for investigating and analyzing GitHub repositories.
MCP-compatible AI clients (OpenCode, Claude, Cursor, etc.) connect to this server and gain read-only tools that return deterministic, validated, structured JSON about any GitHub repository — metadata, issues, pull requests, commits, contributors, releases, and search.
Why it exists
AI agents answering questions like "analyze facebook/react" or "find stale issues" need reliable facts. Computing repository metrics with an LLM is slow, expensive, and error-prone. This server does the deterministic work in code — fetching, validating, bounding, and structuring GitHub data — so the LLM can focus on what it is good at: reasoning and explanation.
Architecture
┌───────────────────────────── MCP client (LLM) ─────────────────────────────┐
│ asks questions, reasons over structured results │
└───────────────────────────────┬───────────────────────────────────────────┘
│ MCP protocol (stdio JSON-RPC)
┌───────────────────────────────▼───────────────────────────────────────────┐
│ server.py MCPServer assembly + tool registration │
├───────────────────────────────────────────────────────────────────────────┤
│ tools/* tool boundary: validation, logging, clean errors │
├───────────────────────────────────────────────────────────────────────────┤
│ github/* async GitHub REST client (httpx), payload mapping │
├───────────────────────────────────────────────────────────────────────────┤
│ models/* stable Pydantic response models (output contract) │
└───────────────────────────────┬───────────────────────────────────────────┘
│ HTTPS + Bearer token
▼ GitHub REST API v3
Key layers are strictly separated: the github package knows nothing about
MCP; the tools package contains no HTTP logic; the models package defines
a stable output contract decoupled from raw API payloads. See
docs/architecture.md for the reasoning behind every
decision.
Available tools (Phase 1 MVP)
| Tool | Description |
|---|---|
get_repository |
Structured metadata for one repository (stars, forks, license, timestamps, …) |
search_repositories |
Search repos; optional sort (stars, forks, help-wanted-issues, updated), order, bounded limit |
get_issues |
Issues filtered by state/labels/sort — pull requests automatically excluded |
get_pull_requests |
PRs with created/updated/closed/merged timestamps and draft flag |
get_recent_commits |
Commits from the last N days (1–365) with author/committer info |
get_contributors |
Top contributors by contribution count |
get_releases |
Recent releases with tag, author, draft/prerelease flags |
All list operations accept a limit clamped to 1–100, enforced twice:
once by the generated input schema, once inside the service layer.
Example interaction
An MCP client calling the server over stdio:
{"jsonrpc": "2.0", "id": 1, "method": "tools/call",
"params": {"name": "get_repository", "arguments": {"owner": "facebook", "repo": "react"}}}
returns structured content:
{
"name": "react",
"full_name": "facebook/react",
"stars": 238000,
"open_issues": 612,
"license": "MIT",
"default_branch": "main",
"created_at": "2013-05-24T16:15:54Z"
}
Natural-language prompts the tools support:
- "Compare stars, issue health, and recent activity of X and Y."
- "Who are the most active contributors of this repository?"
- "What was merged or released here recently?"
Installation
Requirements: Python 3.12+ and uv.
git clone <repository-url>
cd github-intelligence-mcp
uv sync
cp .env.example .env # then set GITHUB_TOKEN in .env
Create a GitHub token at https://github.com/settings/tokens — a fine-grained token with read-only access is sufficient.
Running locally
uv run github-intelligence-mcp # stdio transport (default)
Connecting to an MCP client
Example OpenCode configuration (opencode.json):
{
"mcp": {
"github-intelligence": {
"type": "local",
"command": ["uv", "run", "--directory", "/path/to/github-intelligence-mcp", "github-intelligence-mcp"],
"environment": { "GITHUB_TOKEN": "your-token" }
}
}
}
Claude Desktop (claude_desktop_config.json) uses the equivalent
mcpServers block with command/args.
Configuration
| Variable | Required | Default | Purpose |
|---|---|---|---|
GITHUB_TOKEN |
yes | — | GitHub PAT used for all requests |
GITHUB_API_URL |
no | https://api.github.com |
API root (useful for GitHub Enterprise) |
LOG_LEVEL |
no | INFO |
DEBUG…CRITICAL; logs go to stderr |
REQUEST_TIMEOUT_SECONDS |
no | 30 |
Per-request HTTP timeout |
CACHE_ENABLED |
no | false |
Reserved for Phase 4 response caching |
CACHE_TTL_SECONDS |
no | 300 |
Reserved for Phase 4 response caching |
Secrets are never hardcoded and never logged: the token lives in a
SecretStr and is only materialized inside the Authorization header.
Error handling
Domain exceptions map to clean, user-safe messages — never stack traces, never credentials:
| Situation | Client sees |
|---|---|
| Unknown/private repo | Repository 'owner/repo' was not found or is inaccessible. |
| Bad token | GitHub rejected the configured credentials. Check GITHUB_TOKEN. |
| Rate limit exhausted | GitHub API rate limit exceeded. Please retry after the provided reset time. Reset at: … |
| Missing permission | The configured token does not have permission to access this resource. |
| Invalid input | Field-specific validation message |
Transient failures (5xx, network errors) retry up to 3 times with capped exponential backoff. Client errors are never retried.
Repository health algorithm (Phase 2 roadmap)
Phase 2 adds deterministic scoring — no LLM involved — using explainable, documented weights:
| Component | Weight | Signals |
|---|---|---|
| Activity | 25% | commits 30/90 days, active contributors, recent PRs/releases |
| Issue health | 20% | stale-issue ratio, closure activity, average age (stale = open & untouched ≥ 90 days) |
| PR health | 20% | open/stale PR counts, merge cadence (stale = open ≥ 30 days) |
| Contributor health | 15% | active contributor count, concentration / bus-factor risk |
| Release activity | 10% | release intervals over 30/90-day windows |
| Documentation | 10% | README/docs/license presence signals |
Each component yields a 0–100 score with published formulas so results are reproducible.
Security model
- Read-only V1: no write operations exist to misuse; attack surface stays minimal.
- Input allow-lists prevent path traversal via
owner/repo. - Pagination and retries are bounded by construction.
- Logs contain tool names, repos, durations, statuses — never tokens or headers.
- Unanticipated exceptions are masked by the SDK; clients only see curated messages.
Testing
uv run pytest # 100% offline — respx mocks every HTTP call
Unit tests cover config, validation, models, client behavior (auth headers,
error mapping, retries, rate limits, pagination), and service filtering.
Integration tests drive the real MCPServer instance end-to-end: schema
generation, dispatch, structured output, and error translation.
Docker
docker build -t github-intelligence-mcp .
docker run --rm -i -e GITHUB_TOKEN=ghp_xxx github-intelligence-mcp
Multi-stage build on python:3.12-slim, runs as non-root, installs from the
committed uv.lock, and receives secrets only at runtime.
Development
See docs/development.md. Quality gates:
uv run ruff check .
uv run ruff format --check .
uv run mypy .
uv run pytest
CI runs all four on every push and pull request.
Roadmap
- Phase 2 — deterministic health analysis, maintenance-risk detection, repository comparison
- Phase 3 — MCP resources (
github://repo/{owner}/{repo}/…) and guided prompts - Phase 4 — SQLite response cache with per-endpoint TTLs, advanced rate-limit handling, GraphQL
- Phase 5 — LangGraph autonomous investigation agent
- Phase 6 — Next.js dashboard
License
GitHub Intelligence MCP 질문
GitHub Intelligence MCP는 어떤 도구를 제공하나요?
7개 도구를 제공합니다. 예: get_repository, search_repositories, get_issues, get_pull_requests, get_recent_commits.
What kind of data can I retrieve from GitHub?
The server provides structured metadata, issues, pull requests, commits, contributors, and releases.
Do I need a GitHub token to use this server?
Yes, a GitHub Personal Access Token (PAT) is required. A fine-grained token with read-only access is sufficient.
Is this server capable of making changes to my repositories?
No, the current version is read-only and contains no write operations.
How are errors handled when a repository is not found?
The server returns a clean, user-safe message instead of a stack trace.