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

cc-code-review

by KentQi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Check Review Job Status

claude_review_status
Read-onlyIdempotent

Poll a background code review by job ID to check progress, retrieve the finished report, cancel a running job to stop billing, or list current jobs.

Instructions

Poll a background review started by claude_code_review (real reviews take 2-15 minutes, so the async call returns a jobId). With jobId: returns elapsed time while running, or the full report/result when finished. With cancel=true: aborts the run and stops billing (requires a jobId). Without jobId: lists this server process's jobs. Retention: the 10 most recent finished jobs are kept in this server process; a restart clears them all.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "claude_review_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
jobIdNoThe jobId returned by claude_code_review
cancelNoAbort the running job (kills the claude process tree, stops billing). Requires a jobId.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.18.9
    • changedInput schema / properties / cancel / description
      Previous value: -"Abort the running job (kills the claude process tree, stops billing)"New value: +"Abort the running job (kills the claude process tree, stops billing). Requires a jobId."
  2. Addedv1.8.2

TDQS

A4.9/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses the 2-15 minute runtime, that cancel stops billing and kills the process tree, and the retention policy (10 most recent finished jobs, cleared on restart, process-scoped). These are exactly the behavioral facts an agent cannot infer from readOnlyHint/idempotentHint. Note the cancel path is a state-changing side effect that readOnlyHint doesn't capture, but the description discloses it accurately rather than contradicting it.

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

Conciseness5/5

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

Front-loaded with the core purpose, then three mode clauses and a retention note in four dense sentences with no filler or redundancy.

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?

No output schema exists, and the description compensates fully by describing what each mode returns: elapsed time while running, the full report when finished, and a job list without a jobId. Retention and lifecycle limits are also covered, so nothing needed to call this correctly is missing.

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 100%, so baseline would be 3, but the description adds real meaning: it explains that jobId comes from claude_code_review and that its absence switches the tool into list mode, plus the cancel-without-jobId failure condition. That is semantic behavior the schema alone does not convey.

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?

States a specific verb and resource — poll a background review job's status — and explicitly ties itself to the sibling that creates the job (claude_code_review). An agent can immediately distinguish this from claude_review_env and claude_review_followup.

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?

Enumerates all three calling modes with their preconditions: jobId to poll, cancel=true (requires a jobId) to abort, and no jobId to list jobs. It also gives the timing rationale (2-15 minute reviews) that explains why polling is the correct pattern rather than blocking.

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