I Built a Better GitHub Connector for Claude

The one that ships with Claude works, sort of. But it requires you to already know the repo URL, and writing files means manually handling a SHA you never asked to know about. I fixed both of those things.

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.

Peter Benoit

Written by

Peter Benoit

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