The verdict

“The model can call GitHub” is not a precise permission statement. GitHub’s official MCP Server offers toolsets, individual tool selection, and a read-only mode. A safe configuration should be derived from the action the task must perform, rather than enabling a convenient bundle and hoping a prompt prevents writes.

Three narrowing layers

A toolset groups related capabilities, such as repos, issues, or pull requests. It is useful for defining a first boundary, but a group may still contain read and write tools. An individual-tool allowlist narrows the context and callable surface further. The configuration guide also says that read-only mode takes precedence: a mutating tool is not exposed even when it is explicitly requested.

These controls answer “which tools does the server offer?” They do not answer which identity the request represents or which repositories it can access. Token scope, organization policy, branch protection, and approval rules are separate gates. A read-only flag is not proof that account authorization is minimal.

A read-only research task

For a task that only reads files, issues, and pull requests, choose the required toolsets and enable read-only:

toolsets: repos,issues,pull_requests
mode: read-only

Then verify three things: the exposed inventory has no mutation tools; the token is limited to the intended repositories; and the prompt does not turn “find a problem” into “open an issue” or “submit a pull request.” Tool exposure, identity authorization, and behavioral instructions must agree.

Separate read and write phases

An automated fix may eventually need to read code, propose a patch, create a branch, and open a pull request. That does not mean one long session should start with the full write surface. A safer sequence is read-only collection, human review of a candidate diff, a narrow write authorization, and a second check of the repository and branch.

Even if the server’s read-only filter works as documented, it cannot validate a webhook, branch-protection rule, or bot-account policy for you. Credentials must not appear in prompts, logs, screenshots, or article examples. Use an unmistakable placeholder in documentation.

Common failure modes

Typical mistakes include treating repos as a purely read-only group, enabling every toolset, trusting “do not write” in the prompt, using a personal high-privilege PAT for unattended work, and treating a remote MCP URL as a public service that needs no identity review. Each creates a gap between the tool layer and the account’s actual power.

Acceptance checklist

List the enabled toolsets and individual tools
Confirm write tools disappear in read-only mode
Check token repository and organization scope
Verify branch protection and PR approval rules
Run a harmless read-only smoke test
Compare requested tools with actual tool calls

Scope

Read-only research, code search, and pull-request summaries are good first uses. Merge, release, and production configuration should not become automatic merely because an MCP server is connected; each needs its own approval and rollback path.

Evidence boundary

GitHub’s repository and configuration guide support the toolset, individual-tool, and read-only semantics. This article did not test a real account and does not display or read a token. Account scope, organization policy, and deployment details still need verification in the target environment.