Ask Claude or Cursor "is this GitHub repo still maintained?" and it does the only thing it can from a chat box: fetch the README and guess. The README is marketing. It won't tell you that one file has been rewritten nine times in the last twenty commits, that CI is mostly green-by-skip, or that three of the top five contributors stopped pushing a year ago.

That gap — the repo's behaviour versus the repo's description — is exactly the kind of thing an MCP tool can close, because it needs live API calls the model can't make on its own. So I built a small remote MCP server that does six read-only things against any public repo and hands the agent back clean structured JSON.

The six tools

  • get_repo_overview — stars, forks, language, license, topics, last push
  • list_recent_prs — recent PRs with author, state, merge dates
  • get_contributors — who actually commits, and how much
  • get_hot_files — the files churning hardest right now
  • get_ci_status — sampled check-run health on the default branch
  • get_dependencies — declared deps

No local install. It's a hosted Standby Actor on Apify speaking Streamable-HTTP MCP, so you point your client at one URL and it's there.

What the output actually looks like

get_hot_files on cli/cli, last 20 commits:

{ "branch": "trunk", "commits_scanned": 20, "top_files": [ { "path": "go.mod", "changes": 9 }, { "path": "go.sum", "changes": 9 }, { "path": "git/client_test.go", "changes": 4 }, { "path": "pkg/cmd/api/api.go", "changes": 3 } ] }

An agent can now say "dependency churn is high, the API command and the git client are the active surfaces" instead of paraphrasing the README.

get_ci_status is the one I was most careful with, because a naive version lies. It paginates, so I return what was actually sampled, not a total dressed up as a verdict:

{ "ref": "trunk", "total": 784, "sampled_count": 100, "totals_sampled": { "success": 46, "skipped": 54 } }

sampled_count and totals_sampled are deliberate field names — if the tool only looked at the first 100 of 784 checks, it says so, and the model doesn't get to tell you "CI is 46% passing" as if it counted all of them.

Wiring it into a client

It's a remote Streamable-HTTP server, so in a client that supports remote MCP you give it the URL and an Authorization: Bearer <apify-token> header:

{ "mcpServers": { "github-repo-intel": { "url": "https://cg-nguyen--github-repo-intel-mcp.apify.actor/mcp", "headers": { "Authorization": "Bearer apify_api_..." } } } }

Then tools/list returns all six and the agent self-discovers them.

Two things I'd flag if you build one of these

Pass a GitHub token. Unauthenticated GitHub is 60 requests/hour shared across everyone hitting the same IP. Every tool takes an optional github_token and with one you get your own 5,000/hr. The fan-out tools (get_hot_files, get_contributors) read per-commit, so without a token you'll rate-limit yourself in under ten calls. Read-only public_repo scope is enough.

Charge on success, never on entry. The server bills per tool call, and the charge fires after the upstream GitHub call succeeds, right before the result is returned. If GitHub 404s or rate-limits, no charge. Charging at handler entry would bill people for failures, which is both wrong and a fast way to get delisted.

It's live here if you want to point an agent at it: https://apify.com/cg_nguyen/github-repo-intel-mcp. First calls are cheap; the whole point is that your agent spends a fraction of a cent to stop guessing about a repo and actually look.