How Reviewer Zero Turns Peer Review Into a Staged, Debated MCP Pipeline

Sharvari Raut
Sharvari Raut
How Reviewer Zero Turns Peer Review Into a Staged, Debated MCP Pipeline
How Reviewer Zero Turns Peer Review Into a Staged, Debated MCP Pipeline

Reviewer Zero is an MCP server, built and deployed under Amrita University's Amritapuri campus, that reviews LaTeX manuscripts and searches for related literature through eighteen separate tools rather than a single "review this paper" prompt. It runs on NitroCloud and connects to Cursor, Claude, ChatGPT, Codex, and other MCP clients from one deployment.

What this enables

  • Runs deterministic LaTeX cross-reference, figure, and table checks before any model call
  • Splits critique across persona tools for rigor, math derivations, structure, and weaknesses instead of one generic prompt
  • Resolves contradictions between persona flags with a dedicated debate tool
  • Produces a venue-graded review and a draft author rebuttal letter
  • Searches Semantic Scholar for related work and citations missing from the draft

A researcher's two slow problems

Preparing a paper for submission involves two separate bottlenecks. The first is finding relevant literature: scanning venues, filtering by time range and topic, and checking whether a claim already has supporting citations. The second is getting a second opinion on the manuscript itself before a real reviewer does, catching unsupported claims, weak baselines, missing ablations, or a citation gap, without waiting weeks for peer review to surface the same problems.

Most tools solve one half. A citation-search tool won't tell a researcher that their central claim lacks a supporting bound. A generic AI reviewer prompt tends to flatten different failure modes, a broken LaTeX cross-reference, a missing statistical significance test, a shaky derivation, into the same undifferentiated pass, which makes it hard to trust or debug any single finding.

Why MCP fits here

MCP lets Reviewer Zero expose each review stage as its own callable tool with its own input schema, rather than hiding the whole pipeline behind one chat prompt. A client can call check_crossrefs on its own, or run the full review_paper entry point and let the server orchestrate the rest. Because the server is remote, the same tool set works from Cursor, Claude's connector UI, ChatGPT's custom-tool setup, Antigravity, or a raw SSE connection, without the team maintaining a separate integration for each client.

Inside the review pipeline

The docs page lists the tool set in five informal stages. Stage 1 runs before any persona-level critique: check_crossrefs deterministically validates LaTeX cross-references, figures, and tables, while summarize_paper and recommend_venue establish what the paper is about and where it might fit. analyze_structure checks section ordering, abstract quality, and formatting.

Article image

From there, three persona tools generate independent flags. audit_claims scans for absolute or unsupported claims lacking empirical or mathematical backing. check_rigor evaluates baselines, ablations, statistical significance, and reproducibility. theorist_check walks through math derivations and bounds. detect_weaknesses plays a critical "Reviewer #2," looking for logical gaps and missing experiments.

Those personas will not always agree, so debate_flags resolves contradictions between them against a rubric, and meta_review curates the surviving flags into a coherent set. grade_for_venue then applies venue-specific rubric constraints, generate_review_letter formats the result as a NeurIPS/ICLR-style letter, and generate_rebuttal_letter drafts an author response. render_suggested_fixes renders proposed fixes as diffs for display, without mutating the source file. A separate track, discover_research_papers and convert_pdf_to_latex, handles literature search and turning extracted PDF text into structured LaTeX.

Where NitroStack fits

The eighteen tools are organized as one NitroStack application rather than eighteen separate services, which is what lets a single review_paper call orchestrate structural checks, persona critique, debate, and grading in sequence. NitroCloud hosts the deployment the docs page points to, and the same hosting generates the connection instructions shown for each supported client, so the team did not have to hand-write a separate integration guide for every tool.

The interesting part

The obvious version of this project is "point an LLM at a paper and ask for a review." The more interesting design choice is debate_flags: instead of trusting whichever persona speaks last, the pipeline treats disagreement between the rigor check, the theorist check, and the weakness check as a signal worth resolving explicitly, before a meta-review step curates what survives. That mirrors how a program committee handles reviewer disagreement more than it mirrors a single autograder pass.

What the build demonstrates

Reviewer Zero is a working deployment with a live tool set, not a claimed production research-lab rollout. The pitch describing it is a project demo, and there's no verified data yet on review accuracy or adoption by researchers. What it does demonstrate is that a review pipeline can be decomposed into a deterministic pass, several narrow model-driven checks, and an explicit adjudication step, all addressable as separate MCP tools from one remote server.

Reusable takeaway

The pattern worth reusing is not "AI reviews things." It's splitting an evaluation task into a cheap deterministic check, several narrow model-driven checks, and one dedicated tool whose only job is resolving disagreement between the others. That structure generalizes past peer review to any workflow where a single prompt would otherwise have to hold too many failure modes at once.

Connect Reviewer Zero from Cursor, Claude, or ChatGPT using the setup on its docs page, or look at NitroStack's SDK and NitroCloud to build a similar staged pipeline.

If you want to see Reviewer Zero in action, check out the complete video here.

It walks through the MCP server, the staged review pipeline, how the persona tools and debate step handle a real manuscript, and how the deterministic checks run before any model call.

To explore the implementation in more detail, head over to the NitroStack docs for guides on building tools, resources, prompts, testing MCP servers in NitroStudio, and deploying them through NitroCloud.

Check out the complete code over here. You can also read the source and build your own MCP application using the same SDK and workflow at nitrostack.ai.