Records an idempotent review decision for a saved result, approving, rejecting, or requesting changes, and optionally triggers one prepared continuation plan.
Record one idempotent user review for a saved result; an explicit approved continuation may run one already prepared next plan.
| Name | Required | Description | Default |
|---|---|---|---|
| decision | Yes | ||
| feedback | No | ||
| result_id | Yes | ||
| continuation | No | ||
| review_event_id | No | ||
| revision_request | No | ||
| user_message_ref | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It usefully states idempotency and conditional continuation side effects, but omits permissions, error behavior, effects of non-approved decisions, revision_request semantics, and validation constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is compact and front-loads the core purpose before the continuation note. It is concise, but its extreme terseness for a complex nested schema leaves critical structure unaddressed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given seven parameters, nested revision_request operations, no annotations, no output schema, and zero schema description coverage, the description is far too incomplete. It gives the basic action but leaves an agent without enough context to invoke the tool correctly across its full parameter surface.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are seven parameters with 0% schema description coverage, and the description explains none of them in detail. It vaguely references an 'approved continuation' and 'next plan' but does not clarify decision values, result_id, feedback, revision_request, review_event_id, or user_message_ref.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Record one idempotent user review for a saved result.' It gives scope enough to understand the core operation, though it does not explicitly differentiate itself from other review-adjacent siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies the tool is used for a saved result and notes that an explicitly approved continuation may run a prepared next plan. However, it provides no explicit when-not guidance or alternatives, leaving usage largely inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.