Claude MCP code review.

Why review Claude's code with a council

A model reviewing its own output inherits its own blind spots. AI Council breaks that loop: independent agents for security, performance, architecture, and pragmatism each vote with a confidence score, agents that lack relevant expertise abstain, and dissenters trigger a structured debate before the final ruling. Claude gets a second, third, and fourth opinion, and so do you.

Step 1: Install the plugin

claude plugin marketplace add Zelltron/ai-council-plugin
claude plugin install ai-council@ai-council

Restart Claude Code, then run /mcp and check that ai-council is listed as connected. Plugins load at session start, so the restart is what makes a correct install take effect.

The plugin carries the MCP server, five slash commands, and two skills. It fetches the review engine on demand, so there is no global install to keep up to date. Its source is public if you want to read what you are installing first; it is about a dozen text files and no engine code.

Or register the server yourself

If you would rather not go through the plugin, install the CLI and register it as an MCP server directly:

npm install -g @mugzie/ai-council
claude mcp add --transport stdio ai-council -- ai-council mcp

This gives Claude the same review tools. You just don't get the slash commands or the skills that let Claude decide on its own when a change deserves a panel.

Step 2: Add your keys

Make sure your keys are available in the environment Claude Code runs in: AI_COUNCIL_LICENSE_KEY, plus OPENAI_API_KEY and/or GEMINI_API_KEY. Exports in one terminal do not reach a session launched from another, so put them in your shell profile. Your diffs go directly from your machine to those providers; they never touch AI Council's servers.

Step 3: Ask for a review

In any Claude Code session:

"Before we commit this, have the Council review the diff."

Claude invokes the review tools, waits for the ruling, and can act on it, applying the fixes agents suggested or pushing back with its own reasoning. The tools accept optional parameters Claude will set from your request:

• gitScope: staged, unstaged, or all working-tree changes (default: auto)
• suggestions: include concrete code fixes with REVISE and REJECT votes
• deepAnalysis: file-by-file review with structured findings and project-rule awareness
• agent: two-pass Claude Agent SDK review that explores the codebase before voting
• preContext / preContextTopK: AST-extracted, embedding-ranked context injection
• graph / noGraph: toggle knowledge-graph context discovery
• cwd: repo path, when Claude isn't running at the repo root

Convening a specific panel

When you already know which kind of scrutiny a change needs, the plugin's slash commands seat that panel directly instead of leaving the choice to Claude:

• /council-review: quality, hidden risk, and unnecessary complexity
• /council-security: trust boundaries, injection, and unsafe assumptions
• /council-perf: CPU, allocation, render frequency, async and IO
• /council-arch: whether the abstraction is justified, and what hurts in 6 to 12 months
• /council-sanity: whether this is over-engineered, and the simplest acceptable version

Each takes the same arguments, so /council-review --branch=main --suggestions reviews everything on your branch and asks for concrete fixes with any REVISE or REJECT vote. Pass --pr=123 to judge a pull request instead of your working tree.

A workflow that closes the loop

1. Claude writes the feature.
2. Claude convenes the Council on the diff.
3. The Council rules. Suppose it comes back REVISE with two concrete findings.
4. Claude applies the fixes and re-submits.
5. The Council approves; you commit.

The judgment step is cheap relative to the debugging it prevents. In one real session, the Council caught a response-parsing edge case in a "finished" bug fix that would have shipped a new false-negative bug.