GitHub MCP Server toolsets: which tools read, write, or destroy

Why a toolset is not a risk boundary

A toolset is a grouping of related capabilities. For GitHub, the relevant areas are repositories, issues, pull requests, workflows and security features. The grouping is convenient for configuration, but it does not map cleanly to risk. Within one area, some tools only retrieve data, some change state, and some can delete or irreversibly alter a resource.

The practical consequence is that enabling a toolset is a decision about a mixed set of operations. A team that turns on pull request capabilities to let an assistant summarize changes may also expose operations that modify or close those pull requests. Without a per-tool map, nobody can say which of those operations the agent was permitted to perform.

For a regulated enterprise the question is two-sided: what was the agent allowed to do, and what did it do? Toolset selection answers only a coarse version of the first half and nothing about the second.

Classify every enabled tool by impact

Build the classification from the tool list of the version you actually deploy, and review it when that version changes. Assign each tool to one class based on what happens when it is called, not on how its name or description reads. The class then drives the default policy decision.

• Read: Retrieves repository, issue, pull request, workflow or security data. Default: allow, with redaction of secrets or sensitive content in results where policy requires it.
• Write, low impact: Adds or changes content that is easy to review or undo, such as a comment or a draft. Default: allow for approved identities, rate limited.
• Write, high impact: Changes state that others depend on, such as code, branches, workflow definitions or merge outcomes. Default: escalate for human approval.
• Destructive or hard to reverse: Deletes resources or alters them in ways that cannot be restored. Default: block, with a documented exception path.
• Read that influences action: Read tools whose output the agent may treat as instructions, such as issue or pull request text. Default: allow, but inspect content and constrain what follows.

What native controls do and do not do

Three server-side controls limit exposure. Toolset selection reduces the number of capabilities the agent can see. Read-only mode restricts the server toward retrieval. Token scopes bound what the credential behind the server can do against GitHub. Used together they shrink the blast radius, and they should be applied first, with the narrowest toolsets and scopes that support the use case.

Their limits matter as much as their value. They are set before the session starts, so they cannot reason about a specific call, its arguments, or the context in which the agent made it. A token scope allows an action for every caller that holds the token, whether or not that call makes sense in the moment. Read-only mode is a blunt switch: it removes writes, but it cannot permit one write for one approved purpose.

Authorization failures in MCP components show why authentication alone is insufficient. An MCP Python SDK flaw accepted a valid token issued for another service when audience was not independently validated, and a session-routing flaw in the same SDK let a different authenticated client inject messages into someone else's session. Both are classed as authorization weaknesses. Neither concerns the GitHub MCP Server, but they illustrate the point: being authenticated does not establish authorization for the intended resource, so credentials and sessions need independent validation beneath any policy layer.

Documented risks that apply at the tool-call level

A NIST CSRC presentation on agentic security uses a GitHub MCP tool as an example. The tool exposes operations such as listing repositories or getting branches, and the agent interprets that output as workflow guidance and performs unintended GitHub actions. The lesson is that a read-style tool can lead to state-changing behavior. Classifying the read tool as safe is not enough; what the agent does next with its output must also be governed.

Argument handling is a second risk. In the ai-sdlc plugin MCP server, an unvalidated repo argument was interpolated into gh issue view and gh pr view commands, which allowed a prompt-injected agent to execute commands as the server user. That is a different server from the GitHub MCP Server, but the pattern transfers: any tool that passes agent-supplied values to a shell or API needs those values inspected before the call runs.

Transport and surface flaws round out the picture. The MCP TypeScript SDK did not enable DNS rebinding protection by default for HTTP-based servers before version 1.24.0, while stdio servers were not affected. A PDF Reader MCP server logged that API-key authentication was enabled but never validated the header. And mcp-server-git removed its git_init tool because it accepted arbitrary filesystem paths. Together these argue for checking SDK versions, confirming authentication is enforced, and removing tools the use case does not need.

Evidence a regulated enterprise needs, and where Trussed fits

Evidence has to cover both sides of the question. For what the agent was allowed to do, keep the enabled toolsets, the tool classification, the token scopes and the policy version. For what it did, keep each call with its identity, arguments, decision, any human approval and outcome. Retaining only the executed calls leaves no basis for showing they were permitted, and retaining only configuration leaves no basis for showing what ran.

Trussed enforces policy in the execution path for models, agents, tools, MCP servers and coding assistants, at the level of individual interactions and tool calls: allow, redact, block, rate limit, and escalate for human approval. Enforcement is at runtime, not reviewed after the fact, and the same enforcement produces audit-ready evidence mapped to HIPAA, NAIC, NYDFS, EU AI Act and NIST. It can be deployed self-managed in the customer cloud, with configurable retention and data residency.

Trussed has run continuously in production in a regulated enterprise for more than 18 months at 99.95% uptime, with 100+ models under one policy plane and 30+ GB of audit evidence generated per day. It does not replace the native controls described above. Toolset selection, read-only mode and token scopes remain the first layer, and per-call enforcement is the layer that can show what actually happened.