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 <csv> 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 <text> 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 <owner/name> --pr <number> 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@<version>", "--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 <address> 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

Read the full README on GitHub →