prompt

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

No annotations are provided, so the description carries the full burden and does so: it discloses blocking semantics, that the server imposes no time limit, what happens to the turn on client timeout, and the connection staying alive. It also names the two terminal return states ("approval_needed", "question_needed") and the tools that resolve them.

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 primary action and the exception states, and the timeout guidance is placed where it prevents a costly mistake. Slight redundancy in the closing sentence, which restates the approval/question return values already introduced in sentence two and partly covered by the output schema.

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?

For a blocking, state-dependent tool with no annotations, this covers preconditions, failure mode, recovery path, and return states. An output schema exists, so the description needn't detail payload shape, and the named return markers are a helpful addition rather than a gap.

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 67% — wait is documented in the schema and session points at open, but text has no description anywhere. The description implies the task content and that session is a live IDLE session, yet adds no format, size, or content guidance for text beyond what the schema already implies. Baseline 3 is appropriate at this coverage level.

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 and resource ("Send a task to an IDLE session") and immediately distinguishes behavior from the approval/question path and from the sibling tools status/output/approve/answer. An agent can tell what this does versus open, status, and output without opening any 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?

Explicit preconditions (session must be IDLE; ASKING/QUESTIONING returns the pending approval instead; idly-closed sessions are reopened first) plus an explicit anti-pattern: on client timeout, do not resend — call status and output instead. Alternatives are named by name.

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