GitHub MCP Server: Read-Only vs Write Permissions

Two Token Profiles

The github MCP server's capabilities are entirely determined by the token's GitHub permissions. The same server binary, the same env var name, but very different blast radius depending on the scopes.

Profile 1: Read-only (recommended default)

Token permissions:

• Repository → Contents: Read-only
• Repository → Issues: Read-only
• Repository → Pull requests: Read-only
• Repository → Metadata: Read-only (auto-included)

What the model can do:

• Search code across selected repos
• Read issue and PR bodies, comments, labels
• List branches, commits, releases

What it cannot do:

• Open issues or PRs
• Comment on existing issues
• Push code

This is the right default. The model can answer "what's in our backlog?" without ever writing anything to the repo.

Profile 2: Read + write (selective)

Add:

• Repository → Contents: Read and write (allows commits and PR creation)
• Repository → Issues: Read and write (allows new issues + comments)
• Repository → Pull requests: Read and write (allows opening + reviewing PRs)

What changes:

• The model can call github.create_issue, github.create_pull_request, etc.
• Every write is attributed to your GitHub account in the audit log.

Config (identical for both profiles)

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxx"
      }
    }
  }
}

The token's scopes determine which tools succeed at runtime; the JSON config is the same.

Best practice

Keep two PATs — one read-only PAT for daily use and a separate write PAT you swap in only when you explicitly want the model to take action. Use the secret redactor before sharing config snippets to prevent accidental token leaks.