Agent 15 · GitHub Repo Intelligence Agent
How a second Cloudflare Worker acting as an MCP server connects Claude to live GitHub data — making four real tool calls per analysis and surfacing a structured repo intelligence briefing.
Why MCP, Not Tool Use
Agents 1–14 in this portfolio all use a single Cloudflare Worker as a thin proxy to the Anthropic API — the model produces structured text output, and the frontend parses it. Agent 15 introduces a fundamentally different architecture: a second Worker that acts as an MCP server, giving Claude access to live external data through a defined tool protocol rather than baking data into the prompt.
The distinction matters. Tool use via the API simulates the MCP pattern but is self-contained — the tool logic lives in the Worker or the client. True MCP externalises the tool server entirely. The MCP server is a separate, independently deployable service with its own URL, its own secrets, and its own transport layer. Claude calls it; it calls GitHub; it returns structured data. The model never sees an API key.
Architecture
The setup uses two Cloudflare Workers. The existing luminary-proxy Worker handles the Anthropic API connection exactly as it does for all other agents — unchanged. A new github-mcp Worker is deployed as the MCP server, exposing four endpoints: /repo, /readme, /commits, and /issues.
When a user submits a repo URL, the frontend calls all four MCP endpoints in parallel using Promise.all — not sequentially. This brings the data-fetch latency down to the slowest single GitHub API call rather than four calls in series. The combined data is assembled into a structured context payload and sent to Claude in a single Anthropic API call.
get_repo
Fetches core repository metadata — name, description, primary language, star count, fork count, and last push date. This drives the OVERVIEW block and the HEALTH verdict field.
get_readme
Retrieves and decodes the README content (base64 from GitHub API). Capped at 1,200 characters before being sent to Claude — enough for project description and stack context without blowing the token budget.
list_commits
Pulls the last 30 commits with timestamps. Claude uses this to calculate recent activity velocity and determine whether the project is accelerating, steady, or declining — the ACTIVITY block signal.
list_issues
Fetches up to 50 open issues with titles and labels. Claude clusters these into 2–4 named themes ranked by frequency — identical in pattern to Agent 13's review theme cards, applied to a different data source.
Deployment Setup
The GitHub MCP Worker is deployed via Wrangler with a GitHub Personal Access Token stored as a Cloudflare secret — never exposed to the client. The Worker adds the token to every outbound GitHub API request.
repo:read and issues:read scopes at github.com → Settings → Developer settings → Personal access tokens.wrangler deploy github-mcp-worker.js --name github-mcp. This creates the github-mcp.vikramyeldandi.workers.dev endpoint.wrangler secret put GITHUB_TOKEN --name github-mcp. The token is encrypted at rest and injected at runtime — never visible in source or client.luminary-proxy Worker requires no changes. Agent 15's frontend calls both Workers directly — the MCP Worker for data, the proxy Worker for the Anthropic API call.Output Schema
The system prompt enforces four delimiter blocks — ===OVERVIEW===, ===ACTIVITY===, repeating ===ISSUE=== blocks, and ===VERDICT===. The OVERVIEW and ACTIVITY blocks carry named fields parsed into distinct UI components. The ISSUE blocks follow Agent 13's theme-card pattern exactly, with a PERCENT field driving the frequency bar. The VERDICT is a free-text paragraph constrained to a specific structure: health statement, strongest data signal, and a concrete adopt/monitor/avoid recommendation.
What I Learned
Parallel tool calls are essential at this architecture level. Sequential GitHub API calls would add 600–900ms of latency per run. Parallelising with Promise.all brings the data-fetch phase down to ~200ms — the slowest single call. At the MCP layer, parallel execution is the default assumption; designing for sequential calls would be a meaningful regression.
Context payload size requires active management. Raw GitHub API responses — especially commit and issue lists — can easily exceed 10,000 tokens if passed directly to Claude. Each endpoint is capped before the context is assembled: README at 1,200 characters, commits JSON at 2,000 characters, issues JSON at 2,500 characters. Without these caps, a repo with 500 open issues would blow the context window and spike cost on every run.
The tool trace is a trust signal, not decoration. Showing the four MCP tool calls in the response bubble — → get_repo, → get_readme, etc. — serves a specific purpose: it tells the user that the briefing is grounded in live data, not cached or hallucinated. In an agentic system, making the tool call chain visible is part of the product, not just a debug artefact.
MCP's value is composability, not just connectivity. The GitHub MCP Worker is a standalone service. It could be consumed by Agent 16, by a future CI/CD monitoring agent, or by a multi-agent orchestrator — without any changes. That's the architectural advantage of MCP over inline tool use: the integration is built once and reused across the workflow stack.
Typical Token Profile
A single repo analysis with four parallel MCP calls and capped context payloads typically produces: