ReviewGuard

ReviewGuard MCP

MCP server (review-guard-mcp) that lets AI agents work on GitHub PR reviews behind a safety boundary. The server holds the write-enabled GitHub token and exposes only review operations, so the agent never sees the token. What those operations are allowed to do is fixed at server start, not negotiable by the agent.

Why

A write-enabled GitHub token is needed to create review comments, but giving that token directly to an agent risks accidental or prompt-injected actions: submitting approvals, requesting changes, closing other people's review threads, or touching unrelated repositories. This server sits in between and narrows the token down to exactly the review capabilities you opt into.

Modes

The server supports two modes of use:

Pending mode (default)

The agent reads PR discussion context and builds a pending (draft) review. Nothing it writes is visible to anyone else until a human opens the PR, inspects the draft comments, and submits the review themselves. Submission is structurally unreachable: the submit tool is not even registered, and the underlying client refuses every submit action.

Use this when an agent assists a human reviewer, for example in IDE setups (Claude Code, Codex, Theia) where the agent drafts inline comments and the human stays the reviewer of record.

Submit mode (opt-in, --allow-submit)

Started with --allow-submit, the server additionally registers a submit tool so the agent can post the review itself. Guardrails stay in place:

• The allowed review actions are restricted to the set you list (for example comment-only, with no approvals).
• Every submitted review starts with a fixed, server-configured disclaimer the agent cannot change or remove.
• Optionally, --allow-resolve lets the agent resolve its own review threads (never anyone else's), and --repo/--pr pin the server to a single pull request.

Use this for unattended, autonomous review bots, for example a watcher that reviews every PR where a review is requested from the bot account and posts a real (comment-only) review.

Installation

Requires Node.js >= 22.

Install globally (makes review-guard-mcp available in PATH):

npm install -g @eclipsesource/review-guard-mcp

Or pin to a specific version:

npm install -g @eclipsesource/review-guard-mcp@<version>

The server is also listed in the MCP Registry as com.eclipsesource/review-guard, so clients that browse the registry can find and install it from there. The entry is metadata only, there is no hosted instance to connect to: it describes the npm package above, which your client installs and runs locally in the default pending mode.

From source

Requires npm >= 12 and a Node version supported by it (see CONTRIBUTING.md):

git clone https://github.com/eclipsesource/review-guard.git

cd review-guard npm ci npm run build npm link # creates a global symlink to the binary

Tools

Submit mode flags

By default the server cannot submit reviews. To allow it, start the server with --allow-submit listing one or more of approve, comment, reject:

review-guard-mcp --port 4000 \

--allow-submit approve,comment \ --submit-body "This is an autonomous, AI-based review and may contain mistakes."

• --allow-submit enables the submit tool and restricts its action enum to exactly these values. approve maps to APPROVE, comment to COMMENT, and reject to REQUEST_CHANGES. Invalid actions abort startup.
• --submit-body sets the fixed review summary prefix posted with every submission. The agent cannot change or remove it and may only append its own summary below it. If omitted while --allow-submit is set, a built-in default disclaimer is used. Its wording adapts to the allowed actions (when approve is not allowed it states the review is not an approval, rather than caveating one). Requires --allow-submit and must not be empty.
• --allow-resolve registers the resolve_review_thread tool. The client resolves only threads whose first comment was authored by the authenticated user, so a bot can tidy up its own now-fixed findings on a re-review but never close another reviewer's conversation.

Without --allow-submit, the submit tool is not registered and the submitReview client method refuses every action, so submission is structurally unreachable.

Scoping to a single PR (opt-in)

Start the server with --repo --pr to pin it to one pull request:

review-guard-mcp --port 4000 --repo eclipsesource/some-repo --pr 123

When scoped, every tool drops its owner/repo/pull_number arguments and acts on that PR only. resolve_review_thread additionally checks that the thread belongs to it. The client (github.ts) enforces this independently of the tool schemas, so a caller cannot reach a different PR or repo the token can otherwise write to. Use this whenever the server backs an automated review of a known PR (typically together with submit mode), so a prompt-injected agent cannot post to or resolve threads on unrelated PRs. Both flags are required together. Omitting them leaves the server unscoped (the caller supplies the PR per call).

MCP Client Configuration

Stdio mode (recommended for IDEs)

The server runs as a child process managed by the IDE. No port configuration needed.

For MCP clients that use the common JSON config shape (Claude Code, VS Code, Theia):

{

"mcpServers": { "review-guard": { "command": "npx", "args": ["-y", "@eclipsesource/review-guard-mcp", "--stdio"] } } }

For Codex, add the server to ~/.codex/config.toml or a trusted project-local .codex/config.toml:

[mcp_servers.review-guard]

command = "npx" args = ["-y", "@eclipsesource/review-guard-mcp", "--stdio"]

Or pin to a specific version:

{

"mcpServers": { "review-guard": { "command": "npx", "args": ["-y", "@eclipsesource/review-guard-mcp@ ", "--stdio"] } } }

Remote HTTP mode

The server runs standalone and exposes a Streamable HTTP endpoint.

Start the server:

review-guard-mcp --port 4000                     # bind to 127.0.0.1 (localhost only)

review-guard-mcp --port 4000 --host 172.17.0.1 # bind to a specific address instead

Then point your MCP client at the printed URL (e.g. http://127.0.0.1:4000/mcp). Each POST is an independent stateless request.

Codex HTTP configuration uses the same TOML shape:

[mcp_servers.review-guard]

url = "http://127.0.0.1:4000/mcp"

--host flag

By default the HTTP server binds to 127.0.0.1, which makes it unreachable from containers and other machines. Pass --host to bind one specific address instead. Because the endpoint is unauthenticated, the unspecified addresses (0.0.0.0, ::) are rejected at startup.

The main use case is a reviewing agent that runs inside a container (e.g. a sandboxed agent runtime) and needs to reach the MCP server on the host. On Linux, bind the container network's gateway IP, e.g. for Docker's default bridge (typically 172.17.0.1):

review-guard-mcp --port 4000 \

--host "$(docker network inspect bridge --format '{{(index .IPAM.Config 0).Gateway}}')"

The host firewall must also allow traffic on the MCP port from the container subnet, e.g. with ufw:

sudo ufw allow from 172.17.0.0/16 to any port 4000 proto tcp

From inside the container you can point the client at whichever local name reaches the host: the gateway IP itself, host.docker.internal (Docker) or host.containers.internal (Podman), or a localhost/127.0.0.1 alias that your runtime maps to the host. With a non-loopback --host the server accepts the Host header for any of these while still rejecting unknown hosts, so DNS-rebinding protection stays on.

Authentication

If the GitHub CLI is installed and authenticated (gh auth login), no token configuration is needed. The server automatically retrieves the token via gh auth token.

If gh is not available, provide a token explicitly via the MCP config:

{

"mcpServers": { "review-guard": { "command": "npx", "args": ["-y", "@eclipsesource/review-guard-mcp", "--stdio"], "env": { "GITHUB_TOKEN": "ghp_..." } } } }

The full resolution order is:

1. `GITHUB_TOKEN` environment variable
2. `GH_TOKEN` environment variable
3. `gh auth token`, which reads the token from the GitHub CLI

A fine-grained personal access token scoped to the repositories you review is recommended.

Security considerations

• The agent never sees the token. The server holds it and only exposes the tool set configured at startup.
• HTTP mode binds to `127.0.0.1` by default and validates the Host header against the bound address (DNS rebinding protection), so a malicious website cannot reach the server through a victim's browser.
• The `/mcp` endpoint itself is unauthenticated. Anyone who can reach the port can use the configured capabilities. Keep it on localhost, or with a non-loopback --host restrict the port to the intended subnet via firewall, because every machine or container on that network can otherwise reach it. Unspecified bind addresses (0.0.0.0, ::) are refused at startup.
• Prefer a fine-grained token scoped to only the r