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

Annotations already declare readOnlyHint/openWorldHint/non-idempotent, but the description adds genuinely non-structural behavior: the token is single-use and expires after 15 minutes, and the server may re-elicit requiring a new token. That expiry/single-use detail is exactly the kind of constraint an agent cannot infer. It does not state what the relayed answers ultimately cause (which is where readOnlyHint=true sits slightly at odds with 'continue a call' semantics), so it stops short of 5. Not flagged as a contradiction because continue_call itself only relays answers rather than performing the mutation.

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?

Front-loaded with the trigger condition, and every sentence carries operational weight — no restatement of the tool name. It is a single dense block rather than a structured list, which makes the answer-shape rules slightly harder to scan, keeping it below 5.

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?

There is no output schema, and the description compensates by explaining the input_required signal and the re-ask loop. What it omits is what a successful continuation returns or what happens if the token has already expired, so an agent lacks a picture of the terminal state; otherwise complete for a 2-parameter relay tool.

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?

Schema coverage is already 100%, but the description still teaches the non-obvious nested shape of answers: one entry per question key, with action values accept/decline/cancel and content carrying the requested fields. That is meaning the schema's generic additionalProperties object cannot convey, and it is what makes the call correct on the first try.

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?

States a specific verb (continue) plus the exact precondition that identifies the resource: a site tool call whose result had input_required: true. That precondition distinguishes it from every sibling, which either initiate calls (run_across_sites, execute-ability) or read state; none is the continuation counterpart. An agent can identify the tool without opening the schema.

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?

Gives an explicit trigger (input_required: true in a prior result) and a full when-to-use procedure: ask the person each question, never invent answers, use decline if the person says no, cancel to stop. It also names the re-entry condition — if the server asks again, call again with the new token — so the agent knows the loop has a defined repeat path.

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