Skip to main content
Glama

clonst_review

Submit a plan, code, or proposal for adversarial AI review. Iterate revisions with the reviewer until consensus is reached.

Instructions

Have a plan, code or proposal critiqued by Codex (a second LLM, through its CLI and the user's ChatGPT subscription). One call = one structured critique (APPROVED/CHANGES_NEEDED verdict, required changes, suggestions, risks). The revision loop lives on your side: critically evaluate each critique - apply what holds, reject with justification what is wrong, drifts from the project's intent, or would break something else - then call this tool again with the revised content and the returned thread_id - the reviewer keeps its session memory across rounds. Loop until consensus=true, following the returned next_action field, or until the user decides to stop. WHEN TO USE IT: the criterion is LOGIC, not size. Call it by default, without being asked, for any development that touches the project's logic or behavior (business logic, computations, data flows, models, routes, APIs, state, error handling, concurrency, security, migrations), and for plans and architecture decisions before coding. Do NOT use it for pure presentation (static HTML/CSS, copy), documentation, renames without behavior change, or throwaway content the user will not run. Every call consumes the user's subscription quota; when the scope is unclear, ask the user.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
roundNoRound number (default: 1 without thread_id, 2 with). Hard safety cap: 50 rounds (a ping-pong reaching that point is a runaway, not a review).
contentYesThe plan, code or proposal to review, COMPLETE (on later rounds: the full revised version, not a diff).
contextNoRound 1 only: the reviewer's yardstick for the intent-drift check - user goal, intended behavior, non-goals, constraints, business/product intent, and decisions already made with the user. The reviewer measures the deliverable against this and flags divergences; the richer it is, the better the review. Ignored when thread_id is provided (the reviewer already holds the context in session memory).
languageNoLanguage code for the reviewer's free-text output: language[-Script][-Region] only (e.g. "fr", "pt-BR", "zh-Hans"). Pass the language of your conversation with the user so critiques read naturally to them. Omit to let the reviewer use the language of the reviewed content.
thread_idNoLater rounds: the identifier returned by the previous call. Resumes the reviewer's session, so it remembers its critiques. Omit on round 1.
max_roundsNoRound limit set by the user for THIS ping-pong (the reviewer is informed and calibrates its demands). Omit by default: no limit, the loop continues until consensus. Pass the same value on every round.
changes_madeNoLater rounds: summary of the changes made in response to the previous critiques.
project_pathNoAbsolute path of the project: the reviewer runs there and can read the real files. Reserve it for reviews that must verify existing APIs/contracts/files: by default the content parameter is enough. When set, the ENTIRE project (including .env and secrets) becomes readable by the reviewer, and token consumption can grow sharply: the reviewer explores files agentically, repeatedly re-sending its growing context (largely served from cache when the CLI reports cache hits). Pass it only when independent verification adds value.
review_focusNoRound 1: review focus. Default: all.
changes_rejectedNoLater rounds: rejected critiques, each with its justification (the reviewer will evaluate them).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
roundYes
scoreYes
usageYes
statusYes
verdictYes
critiqueYes
consensusYes
report_idYes
thread_idYes
next_roundYes
next_actionYes
report_pathYes
session_logYes
suggestionsYes
total_usageYes
report_errorYes
reviewer_modelYes
should_reinvokeYes
duration_secondsYes
next_action_kindYes
required_changesYes
risks_identifiedYes
session_migratedYes
reviewer_feedbackYes
requires_user_inputYes
parsed_from_fallbackYes
total_duration_secondsYes
reviewer_reasoning_effortYes
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses behavior: it explains the review round loop, session memory via thread_id, the 50-round cap, the need for critical evaluation, and the next_action field. It also warns about subscription quota and token consumption when using project_path, making agent behavior highly predictable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense and informative but lacks structural breaks like bullet points or sections, which would improve scannability. However, every sentence serves a purpose and there is no extraneous information given the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (10 parameters, iterative process, output schema exists), the description is fully complete. It covers the review workflow, usage conditions, parameter roles, loop mechanism, and safety caps. The presence of an output schema removes the need to describe return values, and the description adequately fills all other gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema description coverage is 100% with parameter descriptions, the tool description adds workflow context beyond schemas. For example, it explains when to pass thread_id (later rounds), why context is ignored if thread_id exists, and that max_rounds should be the same each round. This enriches agent understanding beyond the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Have a plan, code or proposal critiqued by Codex.' It specifies it provides a structured critique with verdict, changes, and risks. It differentiates from siblings (e.g., clonst_ping, clonst_report_summary) through its detailed description of the review process and iteration loop.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly details when to use the tool: 'WHEN TO USE IT: the criterion is LOGIC, not size. Call it by default... for any development that touches the project's logic or behavior.' It also lists exclusions: 'Do NOT use it for pure presentation, documentation, renames without behavior change, or throwaway content.' This provides clear guidance on when to use versus alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

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/capritora/clonst'

If you have feedback or need assistance with the MCP directory API, please join our Discord server