Guide
GitHub MCP Server
A bot that can read your code but knows nothing about your repository is missing most of the story — the issue that explains why, the pull request that changed it, the build that failed last night. GitHub’s official MCP server closes that gap. Works on OpenClaw and Hermes.
The One You Do Not Have to Host
Most connected tools expect you to run a server. This one does not: GitHub hosts the endpoint at https://api.githubcopilot.com/mcp/, so connecting is a matter of a URL and a token. If you would rather run it in your own network, the project is MIT licensed and a self-hosted Streamable HTTP server works here too.
Connect It
- Create a GitHub token with only the access you want the bot to have. This is the step that decides everything the tool can do — see below.
- Open the dashboard, go to Tools, pick a running bot, and find GitHub MCP Server. Enter the endpoint —
https://api.githubcopilot.com/mcp/. The field shows that address as a grey hint but does not fill it in, and Connect stays disabled while it is empty. - Set authentication to Bearer and paste the token. The form opens on None, so this is a change you have to make deliberately — leaving it on None is the usual reason a first connection fails.
To confirm it worked, mcp tools lists what the server exposes and mcp call get_me {} asks GitHub who the token belongs to. If that returns the wrong account, you pasted the wrong token — better to learn it now than from an issue filed by a stranger.
Scope the Token Like It Matters
It does matter. A token is the agent’s entire authority on GitHub, and the model deciding what to do with it is not a colleague who will hesitate. Give it the narrowest access that makes your use case work — read-only if you only want triage and summaries, a single repository rather than an organisation where you can, and a short expiry.
Write access is genuinely useful for the workflows below. Grant it when you want those, not by default, and revoke it the moment an experiment is over.
What to Ask For
- “Summarise the open issues on this repo and group them by theme.”
- “What changed in this pull request, and what would you push back on?”
- “Did last night’s workflow pass? If not, what failed?”
- “Draft release notes from the commits since the last tag.”
- “Are there open security alerts I should look at first?”
Pair it with a scheduled job and the good version appears: a morning message about what broke overnight and what needs review, instead of you going to look.
Where It Stops and Serena Starts
It does reach your code — the catalog lists repositories and code alongside the rest — but reading files through an API is not the same as navigating a codebase. Worth separating, because the two get confused:
- GitHub MCP Server — your repositories and the platform around them: code, issues, pull requests, Actions, releases, security alerts.
- Serena — precise navigation inside a checked-out codebase, backed by a language server: where a symbol is defined, what calls it.
- Codebase Memory — durable structural knowledge of a repository across sessions.
They compose well. The interesting questions — why does this code look like this, and is the fix already in review — need the repository and the platform together.
Troubleshooting
- Authentication fails. Check the mode is Bearer, not None, and that the token has not expired.
- A tool exists but returns nothing. Usually token scope: the account can see the repository but the token cannot. Confirm with
mcp call get_me {}. - The bot will not write anything. Read-only token. That is the system working; widen it only if you meant to.
- Rate limits. GitHub’s limits apply as normal. Ask narrower questions rather than having the agent enumerate everything.
Try It
Connect it read-only, then ask your bot to summarise the open issues on one repository and tell you which three it would do first. It is a small question that immediately shows whether the connection, the token and the scope are all right.
Related: the Tools catalog, Serena, coding workspaces, best MCP servers.