Sora Commander

Overview Schema Source Related Servers Discussions Admin

review_status

Retrieve the stored approval, launch, or DEV_ONLY input outcome for a pending_id without approving, launching, sending input, or rerunning; use it to inspect the original review result.

Instructions

Read-only observation using an existing pending_id: returns the stored Owner command approval/launch result, or the DEV_ONLY send_input input outcome when the ID belongs to stdin input. Does not approve, launch, send input or rerun. For command reviews, RUNNING / LAUNCH_ACCEPTED may remain after the job has COMPLETED: this is NOT the current job state. Use request_status(request_id) or await_process_output(session_id) for the job. For send_input, observe its original pending_id, not the command launch, and never send the input again. On PENDING follow the same pending_id; UNKNOWN does not prove no job ran or no input was sent. Never resubmit to check status.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "pending_id": "<pending_id>"
    },
    "name": "review_status"
  }
}

Input Schema

Name	Required	Description	Default
`pending_id`	Yes	Existing 32-hex pending_id from an Owner command review or DEV_ONLY send_input; NOT the request_id or input_id. Read-only; never fabricate or resubmit.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.2Nov 9, 2026

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations, the description fully carries the burden: it declares read-only behavior, enumerates the operations it never performs, and warns that RUNNING / LAUNCH_ACCEPTED can be stale after COMPLETED. It also discloses that UNKNOWN does not prove no job ran or no input was sent — exactly the non-obvious semantics an agent would otherwise get wrong.

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?

Purpose and read-only constraint are front-loaded, then caveats about stale states, send_input, PENDING and UNKNOWN follow. Nearly every sentence earns its place, though the mid-section clauses are packed densely and 'DEV_ONLY' is used without definition.

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?

For a single-parameter read-only tool with an output schema already declaring the return shape, the description supplies the missing behavioral and disambiguation context — stale-state semantics, error-state meaning, and sibling routing. An agent has everything needed to call it correctly.

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 the 3 baseline applies, and the description goes further by disambiguating pending_id from request_id and input_id and by noting that idempotent re-checks reuse the same ID. It stops short of adding format details beyond the schema's 32-hex note.

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?

Opens with a specific verb and resource: 'Read-only observation using an existing pending_id' that returns the stored Owner command approval/launch result, or the DEV_ONLY send_input outcome. It explicitly carves out what it is not ('Does not approve, launch, send input or rerun'), separating it from run_command, send_input and request_status.

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?

Gives explicit routing: use request_status(request_id) or await_process_output(session_id) for actual job state, and for send_input observe its original pending_id rather than the command launch. It closes with a clear prohibition ('Never resubmit to check status') and states the PENDING follow-up path.

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