AI Extensions: GitHub MCP Server 1.13.0 adds comment-hiding tools
An MCP server that can hide a pull-request review is no longer only reading your repository.
An MCP server that can hide a pull-request review is no longer only reading your repository. GitHub MCP Server 1.13.0, released on October 1, adds that kind of write capability, which makes it a good day to check how its toolsets, read-only mode and lockdown mode fit together.
The short version
Official project: github/github-mcp-server, MIT licensed. The v1.13.0 release adds granular tools to hide and unhide issue comments, PR review comments and PR reviews, and removes the flag gate on MCP Apps UI in the remote server. Observed October 2: 33,324 stars, 5,070 forks, last push 10:48:50 UTC. Stars measure attention, not quality or safety. I reviewed the project on GitHub and did not install or run it. ↗
What changed in 1.13.0
The release was published October 1 at 19:11:31 UTC. The changelog lists the hide and unhide tools, a fix that preserves versioned STDIO API user agents across MCP protocols, source revisions for non-release Docker builds, and always enabling MCP Apps UI. The pull request describing the hide tools says there is one pair per object type, they use GraphQL minimize mutations, each hide call requires a classifier such as SPAM or OFF_TOPIC, and the tools sit behind the issues_granular and pull_requests_granular feature flags. ↗
Before you install: setup, license, activity
The README documents a GitHub-hosted remote server with OAuth or a personal access token, and a local server run with Docker (image ghcr.io/github/github-mcp-server) or as a binary. The LICENSE file is MIT. Recent releases were v1.12.2 on September 16 and v1.13.0 on October 1, so maintenance is active. The count of stars and forks on October 2 says people are watching it, nothing more. For a first trial I would pin the version, use a token or OAuth scope limited to one disposable repository, and keep a note of the exact toolsets enabled. ↗
Where the permission lines sit
The README says toolsets are chosen with --toolsets, and that read-only mode takes priority: write tools are skipped when --read-only is set, even if requested through --tools. Lockdown mode is described as a best-effort filter on content from public repositories whose authors lack push access, meant to reduce prompt injection risk, and explicitly not an authorization boundary. My analysis: read-only controls what the server offers, lockdown controls some of what it returns, and the token controls what GitHub will accept. Repository text is still untrusted input to the model. A new write tool deserves a deliberate decision, not a default upgrade.
A checklist I wrote
The code below is bookkeeping I ran locally with invented tool names. It filters a review list by name prefix to show which entries a read-only plan would drop. It is not how the server enforces anything: test the real --read-only flag against a disposable repository and confirm that hide tools are not offered.
Original synthetic check
write_prefixes = ("hide_", "unhide_", "create_", "update_", "merge_", "delete_")
tools = ["get_issue", "list_issues", "hide_issue_comment", "unhide_issue_comment"]
read_only = [t for t in tools if not t.startswith(write_prefixes)]
assert read_only == ["get_issue", "list_issues"]
print("kept in a read-only plan:", read_only)
# Name-prefix bookkeeping for a review list. The server's --read-only flag,
# not this script, is the control to test.