The default GitHub MCP server works, sort of. You can point it at a repo and ask questions about it. But "point it at a repo" is doing a lot of work in that sentence, because if you don't already know the repo URL, you're stuck. There's no way to say "find my project about Florida parks" and have Claude figure out which repo that is. You have to already know. Which kind of defeats the point.
The other thing that's broken: writing files. You'd think "write this to a file in my repo" would be a one-step operation. It's not. The GitHub API requires a blob SHA to update an existing file, and the default tooling just hands that problem to you. So you end up doing a manual fetch to get the SHA, then passing it back in, which is the kind of thing that should just happen automatically.
I wanted a connector that works the way I actually think about my repos. "Find my contrast checker extension and update the README" should be a complete instruction. So I built one.
What it does
The server has 17 tools. Most of them are things any GitHub integration would have: list issues, create PRs, read files. The ones that matter for daily use are these four:
list_repos pulls every repo you have access to, sorted by recently
active. No URL needed. You can ask Claude "what repos have I been working on lately" and get an
actual answer.
search_repos searches across your repos by name, description, topic,
or language. Scoped to your account by default. Good for when you can't remember what you named a
thing.
search_code searches code across all your repos in one call. Returns
the file and path, and you follow up with get_file to read the full contents. Useful
when you know a pattern exists somewhere but not where.
write_file is the one I'm most happy about. It handles the SHA
automatically. If the file already exists, it fetches the SHA, uses it, and commits the update. If
it doesn't exist, it creates it. You just pass content and a path. It figures out the rest.
The setup
It's a Node.js MCP server written in TypeScript. You build it once and point Claude Desktop at it via config.
You'll need a GitHub Personal Access Token with repo and read:user
scopes. A classic token works fine. Create one at
github.com/settings/tokens.
# clone and build
git clone https://github.com/peterbenoit/github-mcp
cd github-mcp
npm install
npm run build
Then add it to
~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"github": {
"command": "/path/to/node",
"args": ["/path/to/github-mcp/dist/index.js"],
"env": {
"GITHUB_TOKEN": "your_token_here"
}
}
}
}
Restart Claude Desktop and it should connect. When it does, you'll see a confirmation in the logs:
✓ GitHub MCP ready — authenticated as @yourusername.
The gotchas
Use the full path to node, not just node. Claude Desktop launches as
a GUI app, so it doesn't inherit your shell's PATH. If you're using nvm, it has no idea where node
lives. Run which node in your terminal and use whatever path that returns.
The config file location is fixed. It lives at
~/Library/Application Support/Claude/claude_desktop_config.json. Claude Desktop's
Settings UI manages some MCPs internally, but custom servers have to go in that JSON file manually.
Build before you point Claude at it. The config points at
dist/index.js, which only exists after npm run build. If you skip the
build, Claude Desktop will silently skip the server on startup with no error message. Check
~/Library/Logs/Claude/mcp*.log if nothing shows up.
The mcpServers key goes at the top level of the JSON. Easy to
accidentally nest it inside preferences if you're editing the file by hand.
What I use it for
Mostly repo discovery and quick file edits. I can ask Claude to find a specific project, browse the structure, read a file, and write changes back, all in one conversation without touching the terminal or GitHub's UI. For the kind of scattered-across-many-repos situation most personal projects end up in, that's actually useful.
The code search earns its place too. "Find all the files in my repos that import from that one utility I wrote three years ago" used to mean running grep locally or giving up. Now it's a question I can just ask.
The source is on GitHub. If you use it and something breaks, file an issue.
Written by
UI developer and federal design-systems engineer in Florida. I build accessible interfaces for federal health infrastructure and the open web.
Keep reading
All writing