GitHub Intelligence MCP server
Commit Oct 21, 2026Provides AI clients with structured, validated JSON data to investigate and analyze GitHub repositories, including issues, pull requests, and commits.
Also known as Dayyan-Saeed/Github-Intelligence-Mcp
- Stars
- 2
- Tools
- 7
- Downloads, 30 days
- —
- Latest version
- —
- Last commit
- Oct 21, 2026
- License
- MIT
What is GitHub Intelligence MCP?
GitHub Intelligence provides AI clients with structured, validated JSON data to investigate and analyze GitHub repositories, including issues, pull requests, and commits. It exposes 7 tools, such as get_repository, search_repositories, get_issues.
Summary generated from the project's README
About 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.
What you can do with it
- 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.
Written from the project's README. Every use case is checked against a quote from it.
GitHub Intelligence MCP tools 7
Detected from the READMEget_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 | — |
Configuration
GITHUB_TOKEN
| Name | Description | |
|---|---|---|
| GITHUB_TOKEN | — |
Automated checks
Ran Nov 14, 2026Full report →Not verified yet. A server needs a score of 80, no serious finding, and enough data for us to check. How checks work
- Source repository linked and reachabledayyan-saeed/github-intelligence-mcp is public and reachablegithub.com/dayyan-saeed/github-intelligence-mcp ↗Pass
- Package names this repository as its sourceNot checked
- Build provenance (Sigstore attestation)Not checked
- Open source license (OSI)MITspdx.org/licenses/MIT.html ↗Pass
- Commit or release in the last yearLast commit or release 2026-10-21github.com/dayyan-saeed/github-intelligence-mcp ↗Pass
- OpenSSF ScorecardNot checked
- Package name not close to a popular packageNot checked
- No critical advisory in the package or its dependenciesNot checked
- No hidden instructions to the model7 tool descriptions and the README read; no override phrases, credential paths or hidden charactersPass
- Destructive tools are labelledNo tool named like delete, drop or execPass
- Remote endpoint answers the MCP handshakeNot checked
README
View on GitHubGitHub 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 questions
What tools does GitHub Intelligence MCP provide?
It exposes 7 tools, including 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.