← All posts
July 30, 2026·3 min read

MCP Server for GitHub: Code, Issues, and Pull Requests

How to connect the official GitHub MCP Server to a local AI agent, give it access to code and issues, and not hand over more permissions than you need.

Working with GitHub through an AI usually starts with copy-pasting: bring a chunk of code into the chat, then the issue text, then a pull request comment. Context gets scattered, and half an hour later it's unclear which version of the file is even being discussed. The GitHub MCP Server removes that manual carrying-over: the agent reads the repository and its issues directly.

What the GitHub MCP Server can do

The official GitHub server gives an agent tools for working with repositories, issues, pull requests, and users. The main toolsets are available by default; extra ones can be enabled separately.

In practice, that looks like:

  • "Find the issue about slow startup and show me the code it refers to."
  • "Summarize the changes from open pull requests this week."
  • "Compare this branch against main and list what's worth reviewing."
  • "Draft an issue from this error in the log."

The difference from a regular chat is simple: the agent pulls live data from GitHub, instead of working with a fragment someone pasted in once.

What you'll need

You'll need the official GitHub MCP Server, Docker, and a GitHub token. It's best to create a separate fine-grained personal access token and scope it to only the repositories you need. If the agent's job is just reading code and issues, it doesn't need write access at all.

◆

Start in read-only mode. You can add permission to create issues or modify pull requests later, once you know which actions you actually need.

How to connect the server in Doka

In Doka, open the right panel → "MCP Servers" → "+ Add server" and fill in the fields like this:

  • Name: GitHub.
  • Command: docker.
  • Arguments, one per line: run, -i, --rm, -e, GITHUB_PERSONAL_ACCESS_TOKEN, -e, GITHUB_READ_ONLY, ghcr.io/github/github-mcp-server.
  • Environment variables: GITHUB_PERSONAL_ACCESS_TOKEN=your_token and GITHUB_READ_ONLY=1.

Save the server and start a new task. To verify, ask the agent to list open issues in a specific repository. If the list shows up, the connection works.

Docker here is just a convenient way to run the official server. You can build a binary from source and point the "Command" field at it instead, but for a first run a container is simpler and works the same on Windows and macOS.

Where "local" stops

The MCP server itself runs on your computer, and the model in Doka can be local too. But the repositories stay on GitHub — the server talks to the GitHub API over the network. This setup doesn't send code to an extra model provider, but it doesn't turn GitHub into local storage either.

For a private project, check three things: which repositories the token is scoped to, what permissions it has, and which model is active. Don't paste the token into a task or store it in a project file — that's what the environment-variables field is for.

Useful prompts to start with

Don't start with a vague "take a look at the repo." Give the agent boundaries:

  • "Read issue #42 and find the related code. Don't change anything."
  • "Compare open PRs, but only consider changes in server/."
  • "Draft a fix plan and wait for confirmation before editing."

That makes the result easier to check, and the agent doesn't burn context on the whole repository at once. The general MCP concept is explained in plain terms, and other connection options are collected in the article on useful MCP servers.