GitHub Analytics MCP Server

Ein produktionsreifer Model Context Protocol (MCP) 2.x-Server für GitHub-Analysen.

Dieses Projekt geht über ein einfaches MCP-Tutorial hinaus und zeigt, wie man einen MCP-Server mit den Engineering-Mustern baut, die man im realen Einsatz tatsächlich benötigt:

• Asynchrones HTTP

• Connection-Pooling

• Explizite Timeouts

• TTL-Caching

• GitHub-Rate-Limit-Erkennung

• Retry mit exponentiellem Backoff

• Strukturiertes Logging

• Eingabevalidierung

• Parallele API-Anfragen

• Sauberes MCP-Lifecycle-Management

• Echte End-to-End-Tests des MCP-Protokolls

Entstanden als Teil der Reihe Production AI Engineering auf Agentic Data Lab.

🎥 YouTube: Agentic Data Lab

Was macht dieser MCP-Server?

Der Server stellt GitHub-Repository-Analysen als MCP-Tools bereit.

Ein MCP-kompatibler KI-Client kann damit:

• Repository-Metadaten prüfen

• aktuelle Commits abrufen

• Mitwirkende analysieren

• offene Issues prüfen

• Commit-Aktivität analysieren

• zwei Repositories vergleichen

• GitHub-API-Rate-Limits prüfen

Beispiel:

User:
Compare pallets/flask and django/django.

Which repository looks more active?

Der KI-Client kann aufrufen:

compare_repos

und über diesen MCP-Server Live-Daten von GitHub abrufen.

Architektur

                ┌─────────────────────┐
                │   MCP Client / AI   │
                │ Claude / MCP Client │
                └──────────┬──────────┘
                           │
                           │ MCP stdio
                           ▼
                ┌─────────────────────┐
                │ GitHub Analytics    │
                │     MCP Server      │
                └──────────┬──────────┘
                           │
                 ┌─────────┴─────────┐
                 │                   │
                 ▼                   ▼
          Input Validation       TTL Cache
                                     │
                           ┌─────────┴─────────┐
                           │                   │
                      CACHE HIT          CACHE MISS
                           │                   │
                           │                   ▼
                           │          Async HTTP Client
                           │                   │
                           │          Retry + Backoff
                           │                   │
                           │                   ▼
                           │            GitHub REST API
                           │                   │
                           └───────────◄───────┘
                                       │
                                       ▼
                               Structured MCP Result

7 implementierte Produktionsmuster

1. Asynchrones HTTP + Connection-Pooling

Der Server verwendet:

httpx.AsyncClient

anstelle von synchronen HTTP-Anfragen.

Der HTTP-Client wird einmal im Lebenszyklus des MCP-Servers erstellt und über Tool-Aufrufe hinweg wiederverwendet.

Das bietet:

• nicht blockierendes I/O

• Wiederverwendung von Verbindungen

• bessere Nebenläufigkeit

• explizite Timeout-Steuerung

Der Server konfiguriert separate Timeouts für:

connect
read
write
pool

Related MCP server: ship-it-mcp

2. TTL-Caching

KI-Clients rufen möglicherweise dasselbe MCP-Tool mehrmals in einer Unterhaltung auf.

Anstatt jedes Mal GitHub anzufragen, speichert der Server Antworten im Arbeitsspeicher zwischen.

Beispiel:

First request

MCP Client
    │
    ▼
MCP Server
    │
    ▼
GitHub API
    │
    ▼
Cache

Zweite Anfrage:

MCP Client
    │
    ▼
MCP Server
    │
    ▼
CACHE HIT

Es ist keine weitere GitHub-Anfrage erforderlich.

Verschiedene Tools verwenden unterschiedliche TTLs, je nachdem, wie schnell sich ihre Daten ändern.

3. GitHub-Rate-Limit-Erkennung

GitHub stellt Informationen zum Rate-Limit über die Antwort-Header bereit.

Der Server verfolgt Folgendes:

X-RateLimit-Limit
X-RateLimit-Used
X-RateLimit-Remaining
X-RateLimit-Reset
Retry-After

Der Server kann erkennen, wenn GitHub Anfragen tatsächlich einem Rate-Limit unterwirft, und dann einen nützlichen MCP-Tool-Fehler zurückgeben, anstatt eine rohe Ausnahme offenzulegen.

4. Retry + exponentielles Backoff

Vorübergehende Netzwerkfehler und 5xx-Antworten vorgelagerter Dienste werden automatisch erneut versucht.

Retry-Ablauf:

Attempt 1
   │
   └── failure
        │
        ▼
      wait 1s

Attempt 2
   │
   └── failure
        │
        ▼
      wait 2s

Attempt 3
   │
   └── final result

Die Backoff-Formel lautet:

2 ** (attempt - 1)

Der Server wiederholt normale 4xx-Client-Fehler nicht blind.

5. Strukturiertes Logging

MCP stdio nutzt stdout zur Protokollkommunikation.

Betriebsprotokolle werden daher separat über Python-Logging geschrieben.

Beispiel:

2026-08-27T14:14:03 | INFO | Starting GitHub Analytics MCP server
2026-08-27T14:14:04 | INFO | GET /repos/facebook/react → 200
2026-08-27T14:14:04 | INFO | CACHE HIT /repos/facebook/react

Dadurch lässt sich leicht Folgendes prüfen:

• API-Anfragen

• HTTP-Status

• Latenz

• Retry-Versuche

• Cache-Treffer

• Validierungsfehler

• Rate-Limit-Warnungen

6. Eingabevalidierung

Repository-Besitzer und Repository-Name werden validiert, bevor eine Netzwerkanfrage gestellt wird.

Gültige Namen dürfen Folgendes enthalten:

letters
numbers
.
-
_

Zum Beispiel:

face../../book

wird lokal abgewiesen, bevor es Teil einer GitHub-API-Anfrage werden kann.

7. Parallele API-Anfragen

Das MCP-Tool compare_repos benötigt Informationen aus zwei unabhängigen Repositories.

Anstatt sie nacheinander abzurufen:

repo_a = await get_repo_a()
repo_b = await get_repo_b()

führt der Server beide Anfragen parallel aus:

repo_a, repo_b = await asyncio.gather(
    get_repo_a(),
    get_repo_b(),
)

Konzeptionell:

Sequential

Repo A ───────────────► Done
                        Repo B ───────────────► Done


Parallel

Repo A ───────────────► Done
Repo B ───────────────────► Done

Das reduziert die Wartezeit, wenn Anfragen unabhängig voneinander sind.

Verfügbare MCP-Tools

Der Server stellt derzeit 7 MCP-Tools bereit.

get_repo_overview

Gibt zurück:

• Sterne

• Forks

• offene Issues

• Beobachter

• Sprache

• Themen

• Lizenz

• Datum des letzten Push

• Startseite

• Repository-Größe

Beispiel:

get_repo_overview(
    owner="facebook",
    repo="react"
)

list_recent_commits

Gibt die letzten Commits des Repositories zurück.

Beispiel:

list_recent_commits(
    owner="vuejs",
    repo="core",
    limit=5
)

get_contributors

Gibt die wichtigsten Mitwirkenden des Repositories zurück.

Beispiel:

get_contributors(
    owner="django",
    repo="django",
    limit=10
)

list_open_issues

Gibt offene GitHub-Issues zurück, ohne Pull-Requests.

Beispiel:

list_open_issues(
    owner="pallets",
    repo="flask",
    limit=10
)

get_commit_activity

Gibt die Commit-Aktivität des Repositories zurück, einschließlich:

• Gesamtzahl der Commits

• durchschnittliche Commits pro Woche

• Spitzenaktivität

• aktuelle wöchentliche Aktivität

compare_repos

Vergleicht zwei Repositories nebeneinander.

Beispiel:

compare_repos(
    owner1="pallets",
    repo1="flask",
    owner2="django",
    repo2="django"
)

Zurückgegebene Felder umfassen:

stars
forks
open issues
language
last push

get_rate_limit_status

Gibt Informationen zum GitHub-API-Rate-Limit sowie lokale MCP-Server-Zähler zurück.

Beispiel:

{
  "limit": 60,
  "used": 4,
  "remaining": 56,
  "resets_in_seconds": 3599,
  "server_outbound_http_requests": 4,
  "server_cache_hits": 1
}

Die tatsächlichen Werte hängen von deiner aktuellen GitHub-API-Nutzung ab.

Projektstruktur

mcp-github-analytics/
│
├── server.py
│   └── Main MCP server and GitHub tools
│
├── demo_mcp.py
│   └── Real end-to-end MCP client demo
│
├── requirements.txt
│   └── Python dependencies
│
├── .env.example
│   └── Environment variable template
│
└── .gitignore

Einrichtung

1. Repository klonen

git clone https://github.com/sweta2503/mcp-github-analytics.git

In das Projekt wechseln:

cd mcp-github-analytics

2. Virtuelle Umgebung erstellen

python -m venv .venv

macOS / Linux

source .venv/bin/activate

Windows

.venv\Scripts\activate

3. Abhängigkeiten installieren

pip install -r requirements.txt

Das Projekt verwendet:

mcp[cli]==2.1.1
httpx==0.28.1
python-dotenv==1.2.3

GitHub-Token einrichten

Ein GitHub-Token ist optional, wenn du nur mit öffentlichen Repositories arbeitest, aber es wird empfohlen.

Kopiere die Beispiel-Umgebungsdatei:

cp .env.example .env

Füge dein GitHub-Token hinzu:

GITHUB_TOKEN=your_github_token_here

Commite deine echte .env-Datei oder dein Token nicht.

Echte MCP-Demo ausführen

Ausführen:

python demo_mcp.py

Das ist ein echter MCP-End-to-End-Test.

demo_mcp.py importiert die Funktionen aus server.py nicht einfach.

Stattdessen:

1. Starts server.py as an MCP subprocess
2. Connects using MCP stdio
3. Negotiates the MCP protocol
4. Discovers the MCP tools
5. Calls the tools through MCP
6. Receives structured MCP responses

Du solltest eine Ausgabe ähnlich wie die folgende sehen:

MCP CONNECTED — discover the real server tools

Negotiated protocol: ...
Tools discovered (7):
get_repo_overview
list_recent_commits
get_contributors
list_open_issues
get_commit_activity
compare_repos
get_rate_limit_status

Cache testen

Die Demo ruft Folgendes auf:

get_repo_overview(facebook/react)

und zwar zweimal.

Der erste Aufruf fragt GitHub an.

Der zweite sollte Folgendes zeigen:

CACHE HIT

und deutlich schneller zurückkommen.

Parallelen Repository-Vergleich testen

Die Demo führt außerdem Folgendes aus:

compare_repos(
    pallets/flask,
    django/django
)

Beide vorgelagerten GitHub-Anfragen werden gleichzeitig ausgelöst über:

asyncio.gather(...)

Demo-Ausgabe und Server-Logs erfassen

Du kannst die MCP-Client-Ausgabe und die Server-Logs getrennt erfassen:

python demo_mcp.py > demo_output.txt 2> server.log

Dadurch werden erstellt:

demo_output.txt

für MCP-Client-Antworten und:

server.log

für serverseitige Logs.

Das Server-Log enthält nützliche Informationen wie:

GET /repos/facebook/react → 200
CACHE HIT /repos/facebook/react
GET /repos/pallets/flask → 200
GET /repos/django/django → 200

Server direkt ausführen

Du kannst den MCP-Server selbst starten mit:

python server.py

Der Server läuft über MCP stdio.

Normalerweise startet ein MCP-kompatibler Client diesen Prozess automatisch.

Server mit Claude Desktop verbinden

Du musst keine maschinenspezifische claude_desktop_config.json in diesem Repository ablegen.

Füge den Server stattdessen zu deiner lokalen Claude-Desktop-Konfiguration hinzu.

Beispiel:

{
  "mcpServers": {
    "github-analytics": {
      "command": "/ABSOLUTE/PATH/TO/mcp-github-analytics/.venv/bin/python",
      "args": [
        "/ABSOLUTE/PATH/TO/mcp-github-analytics/server.py"
      ],
      "env": {
        "GITHUB_TOKEN": "YOUR_GITHUB_TOKEN"
      }
    }
  }
}

Ersetze:

/ABSOLUTE/PATH/TO/mcp-github-analytics

durch den tatsächlichen Projektpfad auf deinem Computer.

Commite niemals dein echtes GitHub-Token.

Nach einem Neustart von Claude Desktop sollten die GitHub-Analyse-Tools für Claude verfügbar sein.

Beispiel-Prompt:

Compare pallets/flask and django/django.

Which repository appears more active?

Use the GitHub MCP tools and explain which data you used.

End-to-End-Anfrageablauf

User
 │
 ▼
Claude / MCP Client
 │
 │ MCP tool call
 ▼
GitHub Analytics MCP Server
 │
 ├── Validate input
 │
 ├── Check TTL cache
 │
 ├── Cache hit ──────────────► Return result
 │
 └── Cache miss
          │
          ▼
     Async HTTP
          │
     Retry / Backoff
          │
          ▼
     GitHub REST API
          │
          ▼
       Response
          │
          ▼
       TTL Cache
          │
          ▼
 Structured MCP Response
          │
          ▼
     AI / MCP Client

Lokales vs. verteiltes Produktions-MCP

Dieses Projekt verwendet bewusst einen In-Memory-TTL-Cache, weil es als klares lokales/stdio-MCP-Beispiel konzipiert ist.

Für ein verteiltes MCP-Deployment mit mehreren Instanzen würde man den prozesslokalen Zustand typischerweise durch Infrastruktur wie die folgende ersetzen:

Redis
PostgreSQL
distributed rate limiting
centralized observability
authentication
tracing

Die in diesem Repository demonstrierten Muster sind die Bausteine für diese nächste Stufe.

Den vollständigen Build ansehen

Ich erkläre die Architektur, den Code, das Caching, die Retry-Logik, die Validierung, parallele Anfragen und die echte MCP-Demo auf meinem YouTube-Kanal:

🎥 Agentic Data Lab

https://www.youtube.com/@agenticdatalab

Auf dem Kanal behandle ich:

• Production AI Engineering

• MCP

• KI-Agenten

• LangGraph

• RAG

• KI-Evaluierungen

• Agent-Beobachtbarkeit

• KI-Systemdesign

• Data Engineering + KI

• Produktions-Benchmarks und Experimente

Wenn du daran interessiert bist, KI-Systeme zu entwickeln, die über Tutorial-Demos hinausgehen, solltest du ein Abo in Betracht ziehen.

👉 YouTube: Agentic Data Lab

Mitwirken

Issues, Verbesserungen und Pull-Requests sind willkommen.

Wenn du den MCP-Server um ein weiteres nützliches GitHub-Analyse-Tool erweiterst, kannst du gerne einen PR eröffnen.

Projekt unterstützen

Wenn dir dieses Repository geholfen hat:

• ⭐ Gib dem Repository einen Stern

• 🍴 Forke es und baue deine eigenen MCP-Tools

• ▶️ Abonniere Agentic Data Lab

Weitere Produktions-KI-Engineering-Projekte sind in Arbeit.