Inspectrum
Submit a development or architecture plan (Markdown, up to 16k characters) for automated peer review by multiple LLMs.
Choose specific reviewers (e.g., codex, gemini, claude, local models) and optionally run them in parallel.
Focus the review on specific aspects: correctness, completeness, risk, clarity, or all.
Provide optional codebase context (up to 8k characters) to inform the review.
Receive a consolidated verdict (
approve,revise, orreject) via a judge agent when using two or more reviewers.Obtain structured findings with severity (
blocker,major,minor,nit), category, reviewer attribution, detailed description, and optional suggested fix.Get a full Markdown report of the review.
Automatically log each review session to
~/.inspectrum/sessions/(returning session ID and path) for audit and traceability.Optionally receive a revised plan incorporating the reviewers' suggestions.
Leverages Codex (GPT) as a reviewer for plans generated by Claude Code, providing independent second opinions; also supports Codex as the agent with Claude reviewing.
Inspectrum
Independent review before a risky agent change becomes hard to undo.
Claude plans it. GPT reviews it. You approve it.
A plausible plan can commit an agent to a migration, authentication change, payment flow, compatibility break, or deployment that is expensive to undo.
Inspectrum is an independent pre-flight check before that decision. Its first automatic integration runs when Claude Code exits plan mode: Codex (GPT) reviews the plan before the approval dialog reaches you, findings can send the plan back for revision, and you keep final approval. If the reviewer cannot run, the plan passes through with a visible warning instead of being silently reported as reviewed.
Here, independent means a reviewer distinct from the author model, invoked separately. It does not mean their errors are statistically independent. Inspectrum makes the checkpoint repeatable and its failures visible; a net reliability gain and a defensible moat are not yet proven. The post-0.2.2 strategy defines the evidence gates and keeps code review, pull-request review, and pair programming out of scope.
When a skill is enough
For an occasional second opinion, a rule can tell one agent to call another and compare the replies. That is a reasonable lightweight option.
Inspectrum is for the repeatable checkpoint. In Claude Code, the plugin runs at the plan-to-execution boundary without relying on a remembered prompt, caps revision loops, and fails open on operational errors. Other local MCP hosts can call the same review_plan contract on demand. Both paths keep findings attributed, return a common verdict shape, preserve human control, and write local evidence for successful reviews.
Recreating those guarantees with a skill means maintaining the orchestration, output validation, health checks, failure policy, and session record yourself.
Public availability as of 1 August 2026: npm 0.2.3, the GitHub release, and the repository's Claude and Codex plugins are aligned on 0.2.3. Glama is public. The MCP Registry may still show 0.2.2; it was not republished in this pass. Inspectrum was not in the public Claude Community catalog, while PulseMCP blocked the one-time recheck with HTTP 403, so no current PulseMCP listing claim is made.
The public 0.2.3 activation evidence records exact commands, timings, one useful finding, one null result, one visible fail-open case, and the limits of the measurement.
Related MCP server: checkyourself
Quick start
You need Node 20+, Claude Code, and Codex CLI >= 0.99.0 authenticated with a ChatGPT subscription (no API key):
claude plugin marketplace add yannmenec/inspectrum
claude plugin install inspectrum@inspectrumThat's the whole install. Next time you finish a plan in plan mode:
⏺ ExitPlanMode
⎿ inspectrum×codex: REVISE (round 1/2) # abridged — real output
Majors: # adds a full-report path
- [codex] Migration drops the unique index before backfilling —
concurrent writes can insert duplicates.
Fix: backfill first, drop the index last.
Revise the plan to address these findings, then finish the plan again.
⏺ ExitPlanMode
⎿ inspectrum: codex approved the plan (session 2026-07-12…).
┌ Ready to code? ────────────────
│ Here is Claude's plan… ← your normal approval dialogNo prompt to remember, no button, zero tokens spent on triggering. The gate is a deterministic hook — it fires on every plan, whether your session runs Fable, Sonnet, or Haiku. Two commands give you the automatic gate; the on-demand /inspectrum:review command needs one extra line (registering the MCP server — shown in the assisted setup below).
Set up Inspectrum's Codex plan gate. Use normal approvals only — do not
switch to Bypass Permissions or Full Access.
Steps:
1. Run `node --version`. If < 20, stop and tell me to install Node 20+
from https://nodejs.org first.
2. Run `codex --version`. If it is missing or older than 0.99.0, run
`npm install -g @openai/codex@latest` and verify again.
3. Run `claude plugin marketplace add yannmenec/inspectrum`, then
`claude plugin install inspectrum@inspectrum`.
4. Run `claude mcp add --transport stdio --scope user inspectrum -- npx -y inspectrum@latest`
(this powers the on-demand /inspectrum:review command).
5. Run `npx -y inspectrum@latest doctor` and show me the output,
including the resolved codex model/effort lines.
6. Run `codex login status`.
- If it prints "Logged in", tell me: "✅ Setup complete. Your next
plan-mode plan gets a Codex review automatically." Done.
- Otherwise (not logged in), pop open a Terminal window with codex
already running by executing:
`osascript -e 'tell application "Terminal" to do script "codex"'`
Then tell me: "A Terminal window opened with codex running.
Inside that window, click 'Sign in with ChatGPT', complete the
login in my browser, then close the Terminal window. Inspectrum
is then ready."
Do NOT use sudo, edit shell profiles, push git changes, read .env or
credentials, or publish packages. Report back: Node version, codex
install status, doctor verdict, and whether login was needed.How it works
you ──▶ Claude Code ──▶ plan ready ──▶ ExitPlanMode
│
inspectrum plan-gate (hook)
│
Codex reviews the plan
(read-only sandbox, your ChatGPT sub)
│
┌─────────────────────┴──────────────────────┐
APPROVE ✅ REVISE / REJECT ❌
│ │
your approval dialog findings go back to Claude,
appears as usual it revises, gate runs again
(max 2 rounds)Built to be boring and safe:
Fails open. Codex not installed, logged out, timed out, network down — the plan proceeds with a visible warning. Operational errors don't block your work; the gate degrades, it doesn't brick.
Never auto-approves. A green review still lands on your approval dialog. The gate can delay it (while Claude revises) but can never click it — you keep the final call.
No wasted reviews. Within a session, an unchanged plan is hash-cached and not re-reviewed; only real revisions spend a round.
Read-only reviewer. Codex runs in a pinned read-only sandbox (
codex exec -s read-only --ephemeral), and sandbox-weakening flags in your config are stripped. The reviewer reads; it doesn't write.Kill switch.
[plan_gate] enabled = falsein~/.inspectrum/config.toml, or disable the plugin per project.
Why a separate reviewer?
Plans are leverage. A flaw caught before execution can be cheaper to fix than the same flaw found after a difficult-to-reverse change.
Separation makes the check inspectable. The author and reviewer run independently, and findings remain attributed.
Cross-provider value is a hypothesis. Claude and GPT can raise different objections, but Inspectrum has not yet proved that this produces a net reliability gain after false positives, triage, cost, and latency.
Use an existing subscription. No separate API bill when using your ChatGPT subscription; reviews consume your existing Codex subscription allowance. API-key backends are billed by their provider.
What's in the box
🚦 Plan gate | Every Claude Code plan reviewed by Codex before it reaches you — automatic, max 2 revision rounds |
🔍 On-demand review |
|
🧑⚖️ Multi-reviewer + judge | Run codex + gemini + claude in parallel; a judge consolidates into one verdict |
📋 One verdict |
|
🗂️ Session logs | Markdown record of every review — verdict, findings, revised plan — under |
🩺 | One command to check your reviewer is installed, authenticated, and resolving the right model — fails loudly if Codex is logged out |
Works with
Your agent | Your reviewer | Setup |
Claude Code | Codex (GPT) | Plugin — 2 commands above |
Codex app / CLI | Claude |
|
Claude Desktop (macOS) | Codex (GPT) | Download |
Cursor | Codex (GPT) |
|
Paste this into the Codex app or CLI:
Set up Inspectrum so I can review my plans with Claude. Use normal
approvals only.
Steps:
1. Run `node --version`. If < 20, stop and tell me to install Node 20+
from https://nodejs.org first.
2. Run `claude --version`. If "command not found", run
`npm install -g @anthropic-ai/claude-code` and verify again.
3. If `~/.inspectrum/config.toml` does not exist, create it with:
[defaults]
reviewers = ["claude"]
4. Run `codex mcp add inspectrum -- npx -y inspectrum@latest`
5. Run `npx -y inspectrum@latest doctor` and show me the output.
6. Pop open a Terminal window with claude already running so I can
confirm or complete login, by executing:
`osascript -e 'tell application "Terminal" to do script "claude"'`
Then tell me:
- "If claude shows its chat prompt, you're already logged in —
close the Terminal window. Inspectrum is ready."
- "If claude shows /login or opens a browser, complete the sign-in
with your Claude account, then close the Terminal window.
Inspectrum is then ready."
(The ⚠ claude line in the doctor stays even after login because
claude doesn't expose a status command we can detect — harmless.)
Do NOT use sudo, edit shell profiles, push git changes, read .env or
credentials, or publish packages. Report back: Node version, claude
install status, doctor verdict, and whether login was needed.Needs a Claude Pro/Max subscription — no API key.
Tuning
Which model reviews, at which effort? On the Codex side, precedence is:
Setting | 1st (wins) | 2nd | 3rd |
model |
|
| codex built-in default |
reasoning effort |
|
| codex built-in default |
inspectrum doctor prints the resolved values. High effort gives the deepest reviews but can take minutes per plan — drop to effort = "medium" in [reviewers.codex] if the gate feels slow.
[defaults]
reviewers = ["codex", "gemini"] # called in parallel
judge = "codex" # consolidates when >= 2 reviewers
focus = "all" # correctness | completeness | risk | clarity | all
[plan_gate] # ExitPlanMode hook behavior
enabled = true
max_rounds = 2 # denials before the plan passes through
reason_max_chars = 3000 # budget for findings fed back to Claude
# reviewers = ["codex"] # gate-specific override of defaults.reviewers
[reviewers.codex]
effort = "high" # passed as -c model_reasoning_effort=high
timeout_seconds = 300 # per-reviewer override of limits.timeout_seconds
# model = "gpt-5.6-sol" # passed as -m; omit to inherit ~/.codex/config.toml
[reviewers.gemini]
type = "cli"
binary = "gemini"
model = "gemini-2.5-pro"
[reviewers.local]
type = "http"
backend = "ollama"
endpoint = "http://localhost:11434"
model = "qwen2.5:0.5b"
[limits]
report_max_chars = 8000 # caps the stored report
timeout_seconds = 300 # default reviewer wallclockWithout a config file, reviewers = ["codex"] is used. Free-tier-friendly: the Gemini CLI works with a personal Google account, no API key. Experimental backends: kimi, qwen, openrouter, ollama (local, zero egress).
Headless or CI host that can't run an interactive login? Pass the peer API key through the MCP host's env block instead — OPENAI_API_KEY (codex), ANTHROPIC_API_KEY (claude), GEMINI_API_KEY (gemini). Manual JSON/TOML examples live under examples/.
# Register the MCP server without the plugin:
claude mcp add --transport stdio --scope user inspectrum -- npx -y inspectrum@latest # Claude Code
codex mcp add inspectrum -- npx -y inspectrum@latest # Codex
# The automatic plan gate must use the plugin's pinned fail-open shim; do not
# register plan-gate through a mutable npm tag.
# Verify everything:
npx -y inspectrum@latest doctorSession logs live at
~/.inspectrum/sessions/<timestamp>__<id>/and contain your full plan plus a Markdown record of each reviewer's verdict and findings. Directory perms are 0700 on POSIX. Logs written by pre-0.1.0 versions keep their original perms — retrofit withchmod -R 700 ~/.inspectrum/sessions/.Never paste secrets into a plan or context. The plan is written to the local session log, and both the plan and context are sent to every active reviewer.
Cloud routes: claude → Anthropic (OAuth keychain or
ANTHROPIC_API_KEY); codex → OpenAI (ChatGPT login orOPENAI_API_KEY); gemini → Google (personal-account CLI login orGEMINI_API_KEY); openrouter → openrouter.ai; kimi → Moonshot AI; qwen → Alibaba Cloud; ollama → localhost only, zero egress unless you changeendpoint.Codex is invoked as
codex exec --ephemeral --skip-git-repo-check -s read-only …in a throwaway temp directory — the sandbox is pinned read-only, sandbox-weakening and cwd-override args from your config are stripped, and codex persists no session files.
FAQ
Does this slow me down? Only when it should. An approve verdict adds one review pass (seconds to a couple of minutes depending on effort); a bounced plan was a plan you wanted bounced. Within a session, an unchanged plan is cached and not re-reviewed.
What if Codex is down / logged out / not installed? The gate fails open with a visible warning and your plan proceeds untouched. An operational error never blocks your work — that's an architecture invariant, not a best effort.
Can it approve a plan behind my back? No. The gate can only delay the approval dialog (while Claude revises) — it can never click it. You see and approve every plan that ships.
Do I need API keys? Not for subscription-backed Codex or Claude CLI logins. Reviews consume the allowance of the existing subscription. API keys are supported for headless/CI setups and are billed by their provider.
My prompt/plan is sensitive — where does it go?
To the reviewer(s) you configured, and to a local session log under ~/.inspectrum/sessions/ (0700). Nothing else. Use ollama for a fully local, zero-egress reviewer.
Troubleshooting
sh: inspectrum: command not found / claude mcp list shows ✗ Failed to connect — but only when your current directory is the Inspectrum repo itself. npx inspectrum@<version> resolves the spec against the local package when cwd is inside a package named inspectrum whose version matches, and a package's own bin is never self-linked into its node_modules/.bin. The published package is fine. Fixes: run from any other directory, or install the real binary once and register that instead:
npm install -g inspectrum
claude mcp add --transport stdio --scope user inspectrum -- inspectrumGate feels slow? Set effort = "medium" in [reviewers.codex] (see Tuning). Something else? npx -y inspectrum@latest doctor diagnoses install, login, and model resolution in one shot — open an issue with its output.
If Inspectrum caught a bad plan for you, star the repo ⭐ — it's how other agent-wranglers find it.
MIT — Yann Menec. Contributions welcome: CONTRIBUTING.md.
Available Tools
1 toolreview_planReview PlanA
Review a development/architecture plan with peer LLMs and return a consolidated verdict (approve | revise | reject) with prioritized findings. Runs configured reviewer CLIs and writes a local session log to ~/.inspectrum/sessions/.
| Name | Required | Description | Default |
|---|---|---|---|
| plan | Yes | The plan to review, in Markdown. Max 16 000 characters. | |
| focus | No | Review focus area. | all |
| judge | No | Run judge agent to consolidate when >= 2 reviewers. | |
| context | No | Optional codebase excerpts for context. Max 8 000 characters. | |
| reviewers | No | Reviewer IDs (from config). Defaults to config defaults.reviewers. |
Output Schema
| Name | Required | Description |
|---|---|---|
| verdict | Yes | |
| findings | Yes | |
| session_id | Yes | |
| revised_plan | No | |
| session_path | Yes | |
| report_markdown | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, the description discloses that it runs configured reviewer CLIs and writes a local session log, adding specific side-effect information that the annotations only hint at. This provides useful transparency about external behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose in the first sentence and side effects in the second. No wasted words, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the primary purpose, side effects, and output summary. The presence of an output schema handles return value specifics. Minor gaps remain (e.g., configuration details) but are not critical given the richness of the schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are fully described in the JSON schema (100% coverage), so the description does not add parameter-specific meaning. The baseline of 3 applies because the schema carries the load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reviews a development/architecture plan, using a specific verb and resource, and describes the output as a consolidated verdict with prioritized findings. It is unambiguous and distinguishes the tool's function even without siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context for use is clear: you review a plan. However, there are no explicit when-not-to-use instructions or alternative tools mentioned, given there are no siblings. The description implies usage effectively but lacks explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
1 tool update
v0.2.2- First observed
review_plan
TDQS
With only one tool, there is no possibility of confusion or overlapping purposes. The tool's purpose is clearly distinct within the server.
The lone tool follows a clear verb_noun pattern (review_plan), which is consistent and readable. Since there are no other tools, there is no inconsistency.
The server has only one tool, which feels thin for a typical MCP server. While it may be intentional for a narrow purpose, the count is on the borderline.
The stated purpose is reviewing a plan, and the single tool directly accomplishes that with no apparent gaps. The domain is narrow and fully covered.
Maintenance
Related MCP Connectors
Built-environment forecasts, public benchmarks, and permit or zoning readiness through remote MCP.
Consult a multi-model panel on contested decisions via MCP: architecture, plan review, strategy.
Hybrid human + AI expertise for faster, trusted answers and decisions via MCP Server.
Free MCP tools: the only MCP linter, health checks, cost estimation, and trust evaluation.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceEnables hybrid code audits using MCP tools across 12 domains, producing structured, scored, and actionable code quality reports.121MIT
- AlicenseBqualityAmaintenanceLocal-first production-readiness MCP server for AI-built apps. It runs read-only checks, produces an evidence-based readiness score, and guides fixes before launch.95Apache 2.0
- AlicenseBqualityAmaintenanceMulti-model adversarial design review MCP server that distributes design documents to multiple LLMs, retrieves project knowledge, and produces calibrated consensus summaries.333Apache 2.0

convergeqa-mcpofficial
AlicenseBqualityBmaintenanceMCP servers for multi-model document review with critique/iterate and compare/due-diligence tools, using public verification receipts.16MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/yannmenec/inspectrum'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
