Skip to main content
Glama
Sign In
cc-code-review

cc-code-review

by KentQi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Follow Up on a Review

claude_review_followup

Continue a previous code review session to ask follow-up questions or re-check fixes, using the returned session ID; runs asynchronously by default and can block when waitForResult is true.

Instructions

Continue the conversation of a previous claude_code_review run (same reviewer context, e.g. '为什么第 2 条是问题？' or 're-check after my fix'). Pass the session_id returned by claude_code_review. Async by default (returns a jobId after a fast preflight; poll claude_review_status) — waitForResult=true blocks synchronously.

Input Schema

NameRequiredDescriptionDefault
modelNo
messageYesQuestion or instruction for the reviewer (max 100000 chars)
repoPathYesAbsolute path of the repo the original review ran in (~/ prefix allowed)
sessionIdYessession_id returned by a previous claude_code_review / claude_review_followup call
maxBudgetUsdNoAPI spend cap via --max-budget-usd. Default 0 = NO CAP (same policy as claude_code_review); the timeoutMinutes guard applies. A followup has no subagent fleet, so its typical spend is small.
waitForResultNoBlock synchronously for the reply. Default false: returns a jobId after a fast preflight (poll claude_review_status) — use that with clients that cut tool calls at ~30s.
outputLanguageNo中文
timeoutMinutesNoHard wall-clock timeout for this followup turn, in minutes (default 10 — a followup is a Q&A turn, not a full review).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.18.9
    • addedInput schema / properties / maxBudgetUsd / description
      Added value: +"API spend cap via --max-budget-usd. Default 0 = NO CAP (same policy as claude_code_review); the timeoutMinutes guard applies. A followup has no subagent fleet, so its typical spend is small."
    • changedInput schema / properties / message / description
      Previous value: -"Question or instruction for the reviewer"New value: +"Question or instruction for the reviewer (max 100000 chars)"
    • addedInput schema / properties / message / maxLength
      Added value: +100000
    • addedInput schema / properties / timeoutMinutes / description
      Added value: +"Hard wall-clock timeout for this followup turn, in minutes (default 10 — a followup is a Q&A turn, not a full review)."
    • changedInput schema / properties / waitForResult / description
      Previous value: -"Block synchronously for the reply. Default false: returns a jobId at once (poll claude_review_status) — use that with clients that cut tool calls at ~30s."New value: +"Block synchronously for the reply. Default false: returns a jobId after a fast preflight (poll claude_review_status) — use that with clients that cut tool calls at ~30s."
  2. Changed1 schema field changedv1.9.2
    • addedInput schema / properties / waitForResult
      Added value: +{
+  "default": false,
+  "description": "Block synchronously for the reply. Default false: returns a jobId at once (poll claude_review_status) — use that with clients that cut tool calls at ~30s.",
+  "type": "boolean"
+}
  3. First observedv1.6.0

TDQS

A4.3/5.0
Behavior4/5

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

Adds real behavior beyond annotations: async-by-default with a fast preflight returning a jobId, synchronous blocking via waitForResult, and the reason (clients that cut tool calls at ~30s). One gap: it doesn't say that each call appends a turn to the same session (non-idempotent), which matters given idempotentHint=false.

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?

Front-loaded with purpose, then the required sessionId, then the async/sync contract in one compact sentence. Dense parentheticals and the 'fast preflight' shorthand make it slightly compressed, but no sentence is wasted.

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

Completeness4/5

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

Covers the prerequisites, the async-vs-blocking contract, and the polling sibling for an 8-parameter async tool with no output schema. It does not say what a followup reply looks like (plain reviewer text vs. structured finding), which is the only meaningful omission.

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?

Schema coverage is 75% and already documents sessionId, message, repoPath, waitForResult and timeouts; the description still adds value by naming the source of sessionId and giving example messages. The 0-means-no-cap budget policy lives only in the schema, so the description adds little there but nothing is lost.

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?

Specific verb+resource ('continue the conversation of a previous claude_code_review run') with a parenthetical clarifying it preserves reviewer context. It is clearly distinguishable from claude_code_review (starts a review) and claude_review_status (polls a job).

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

Usage Guidelines4/5

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

States the prerequisite (pass the session_id returned by claude_code_review) and routes polling to claude_review_status, plus the waitForResult=true synchronous alternative. Missing an explicit inverse ('use claude_code_review to start a new review, not this'), but the alternative routing is strong.

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

Deploy Server

Other Tools