Skip to main content
Glama
rajat1994

github-repo-summarizer

by rajat1994

github-repo-summarizer

An MCP server that turns any public GitHub repository into a PDF report containing a codebase summary, the most recent commits, and suggested improvements — generated locally by an Ollama model.

What it does

The server exposes a single MCP tool:

summarize_github_repo(repo_url: str, output_dir: str = ".") -> str

Given a GitHub URL (e.g. https://github.com/owner/repo, owner/repo shorthand, or a git@github.com:owner/repo.git SSH URL), it:

  1. Fetches repository metadata, the latest 25 commits, and the recursive file tree from the public GitHub API.

  2. Picks a representative set of source files (up to 25 files, each ≤ 40 KB, total ≤ 400 KB), prioritising entry points and manifests (README, pyproject.toml, package.json, Dockerfile, etc.) and skipping noise (node_modules, dist, lockfiles, snapshot folders).

  3. Sends that corpus to a local Ollama model in two passes — one for the codebase summary, one for improvement suggestions.

  4. Renders a PDF (via ReportLab) and returns the absolute path.

The PDF contains

Section

What's in it

Title block

Repo full name, generation timestamp (UTC), link to the repo

Metadata table

Description, primary language, default branch, stars, forks, open issues, license, created/last-pushed dates

Codebase Summary

250–400 word LLM-written prose summary of architecture, modules, tech stack

Recent Commits

Table of the latest 25 commits (SHA, author, date, message)

Suggested Improvements

Numbered list of 5–10 actionable items grounded in the actual code

Related MCP server: MCP GitHub Reader

Requirements

  • Python ≥ 3.11

  • uv for dependency management

  • Ollama running locally with at least one model pulled

  • An MCP-aware client (e.g. Claude Desktop)

Installation

# 1. Clone or copy this folder
cd github-repo-summarizer

# 2. Install dependencies into a project-local .venv
uv sync

# 3. Configure environment
cp .env.example .env
# then edit .env to taste (see "Configuration" below)

# 4. Pull at least one Ollama model
ollama pull llama3.2          # small, fast
# or
ollama pull qwen2.5-coder:7b  # better for code analysis, ~4.7 GB

Make sure the Ollama server is running:

ollama serve          # in a terminal
# or just launch the Ollama.app — it starts the server automatically

Configuration

All settings come from environment variables, which can live in a .env file next to main.py (loaded automatically at startup).

Variable

Default

Purpose

OLLAMA_MODEL

llama3.2

Tag of the Ollama model to use. Must be pulled.

OLLAMA_HOST

http://localhost:11434

Ollama HTTP endpoint.

OLLAMA_NUM_CTX

16384

Context window in tokens. Bump for larger repos; lower if memory-constrained.

Example .env:

OLLAMA_MODEL=qwen2.5-coder:7b
OLLAMA_HOST=http://localhost:11434
OLLAMA_NUM_CTX=32768

Choosing a model

Local LLMs vary widely in code-comprehension quality. Suggestions:

  • llama3.2 — 3 B parameters, fast, decent general summaries.

  • llama3.1:8b — bigger, better narrative quality.

  • qwen2.5-coder:7b — recommended for code-heavy repos; trained for code.

  • codellama:13b — older but solid for code review-style output.

Make sure the model's native context window is ≥ OLLAMA_NUM_CTX; otherwise the corpus will be silently truncated.

Using it with Claude Desktop

Add the server to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) — adjust the absolute paths to wherever you cloned the project:

{
  "mcpServers": {
    "github-repo-summarizer": {
      "command": "/absolute/path/to/uv",
      "args": [
        "run",
        "--directory",
        "/absolute/path/to/github-repo-summarizer",
        "--frozen",
        "--with",
        "mcp[cli]",
        "mcp",
        "run",
        "/absolute/path/to/github-repo-summarizer/main.py"
      ]
    }
  }
}

Notes:

  • Use the absolute path to uv (which uv). Claude Desktop is a GUI app and doesn't inherit your shell's PATH.

  • --directory must point at the project directory, not the script itself. uv chdirs into it.

  • Fully quit Claude Desktop (⌘Q on macOS) and reopen it after editing config. Just closing the window won't reload MCP servers.

Once connected, ask Claude to use it:

Use github-repo-summarizer to summarize https://github.com/anthropics/anthropic-sdk-python and save the PDF to my Desktop.

Claude will call summarize_github_repo(repo_url=..., output_dir=...) and return the path to the generated PDF.

Using it from any other MCP client

The server speaks MCP over stdio. Any client that can launch a subprocess and exchange JSON-RPC over stdin/stdout will work. The launch command is:

uv run --directory /path/to/github-repo-summarizer --frozen \
       --with mcp[cli] mcp run /path/to/github-repo-summarizer/main.py

For quick local testing:

uv run python main.py

…and pipe an MCP initialize request to stdin to confirm it responds.

Output

PDFs are written to <output_dir>/<owner>-<repo>-summary.pdf. output_dir defaults to the current working directory of the server process (which, when launched by Claude Desktop, may not be where you expect — pass an explicit path when invoking the tool).

Limitations

  • Public repos only. Private repos would need authenticated GitHub access; this server doesn't ship that.

  • File budget. The server reads up to 25 files (≤ 40 KB each, ≤ 400 KB total). Very large monorepos will be sampled, not exhaustively analysed.

  • LLM quality is bounded by the model. A 3 B parameter model will produce shallower summaries than an 8 B+ model. Pick accordingly.

  • No streaming. PDFs are produced after both LLM calls complete; expect tens of seconds to a couple of minutes per repo, dominated by the model's generation speed.

  • PDF only. No HTML/Markdown output mode (yet).

Troubleshooting

Server shows "failed" in Claude Desktop developer settings. Check ~/Library/Logs/Claude/mcp-server-github-repo-summarizer.log for the real error. The two most common causes:

  • --directory value missing or pointing at a file → uv exits with Not a directory. Fix the path in claude_desktop_config.json.

  • uv not found → use the absolute path to uv in command.

Could not connect to Ollama at http://localhost:11434. Run ollama serve (or open Ollama.app).

Ollama model 'X' is not pulled. Run ollama pull X.

Truncated or empty summary. The corpus exceeded the model's context window. Lower OLLAMA_NUM_CTX only hurts; instead, switch to a model with a larger native context, or shrink MAX_TOTAL_BYTES in main.py.

Project layout

github-repo-summarizer/
├── main.py            # MCP server + GitHub/Ollama/PDF logic
├── pyproject.toml     # Project metadata and dependencies
├── .env               # Local config (gitignored)
├── .env.example       # Template
└── README.md

License

Not specified. Add one before redistributing.

Available Tools

1 tool
summarize_github_repoA

Generate a PDF report summarizing a public GitHub repository.

The PDF contains the repository's metadata, an LLM-written technical summary of the codebase, the most recent commits, and a list of suggested improvements.

Args: repo_url: A public GitHub repository URL (e.g. https://github.com/owner/repo) or "owner/repo" shorthand. output_dir: Directory where the PDF will be written. Defaults to the current working directory.

Returns: The absolute path of the generated PDF file.

ParametersJSON Schema
NameRequiredDescriptionDefault
repo_urlYes
output_dirNo.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the full burden. It discloses that the tool generates a PDF with specific content, takes a repo URL and output directory, and returns the absolute path. However, it does not mention whether the tool makes network calls, how long it takes, or error behavior (e.g., for invalid URLs or private repos). The transparency is adequate but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear purpose sentence, a list of report contents, and separate 'Args' and 'Returns' sections. It is front-loaded with the main action. It could be slightly more concise by integrating the 'Args' block with the schema, but it remains efficient and readable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with two parameters and a simple return (PDF file path), the description covers the essential elements: parameter details, output, and content. It lacks error handling or edge cases (e.g., invalid repo URL), but given the tool's simplicity, it is mostly complete. An explicit mention of required internet access would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, meaning the schema has no parameter descriptions. The description fully compensates by explaining both parameters: repo_url (format and examples) and output_dir (default behavior and purpose). This added meaning is essential and well-executed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Generate a PDF report summarizing a public GitHub repository.' It specifies the verb (generate) and the resource (public GitHub repo), and lists the report contents (metadata, LLM summary, commits, improvements). No sibling tools exist to differentiate, but the description is sufficiently specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states that the repository must be public, which is a key usage constraint. It does not provide when-not-to-use guidance or mention alternatives, but given no siblings, the guideline is clear enough. A minor improvement would be to explicitly state that private repos are not supported.

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.

  1. 1 tool updatev0.1.0
    • First observedsummarize_github_repo

TDQS

A4.3/5.0

Scored across 1 tool

Disambiguation5/5

Only one tool exists, so there is no ambiguity or risk of misselection. An agent can clearly identify its purpose.

Naming Consistency5/5

The single tool follows a clear verb_noun pattern ('summarize_github_repo'), which is consistent and predictable.

Tool Count3/5

With only one tool, the server feels thin for a typical MCP server, but it is still acceptable for a focused summarization task. The scope is narrow but complete.

Completeness5/5

The tool covers the full workflow of summarizing a GitHub repository into a PDF, including metadata, technical summary, recent commits, and suggested improvements. There are no obvious gaps in the stated purpose.

Maintenance

ActivityStale
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers