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

With no annotations, the description carries the full behavioral burden and does well: it discloses that queued messages are dropped, that a pending wait_thronglet surfaces a cancelled error, and that the session is idle afterward and accepts new messages. It does not mention authorization or permissions, leaving one gap for a mutation tool.

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?

Two dense sentences, front-loaded with the primary effect and back-loaded with post-conditions and the no-op case. No filler or restatement of the name.

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 one-parameter mutation with no annotations and no output schema, the description covers the key effects, side effects on queued messages and waiting callers, and the resulting state. Only the permission/authorization angle is unaddressed.

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 description coverage is 100% for the single session_id parameter, and the schema already ties it to run_thronglet. The description adds no syntax or format detail beyond that, so the baseline 3 is appropriate.

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 (cancels) and resource (the session's running turn) and even names the underlying operation (session/cancel). It also references siblings wait_thronglet and send_message, so an agent can distinguish this tool's role from theirs without opening a 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 clear context for when the tool matters and explicitly notes the no-op case on an idle session, which prevents pointless calls. It stops short of naming an alternative tool or exclusion for other cancel-like scenarios, so it is not a full when/when-not routing statement.

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

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

With no annotations, the description carries the full burden and does so well: it discloses what is included (runnable harnesses, non-runnable ones with reasons, server limits) and a meaningful exclusion rule (built-in harnesses that are not installed are omitted). It does not state that it is a read-only/safe operation, which leaves a small gap.

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 purpose is front-loaded and every clause carries distinct information (content types, failure reasons, server limits, exclusion rule). The first sentence is dense and slightly run-on, but nothing is wasted.

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?

With no output schema and no annotations, the description compensates by enumerating the shape of the returned content and the exclusion criteria. An agent has enough to decide when to call it and what to expect back.

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?

The tool takes zero parameters, so the schema has nothing to document and the description correctly adds no parameter information. Baseline for a zero-param tool is 4.

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 uses a specific verb+resource ('List valid agent values ... installed harnesses with their models and effort levels') and explicitly ties itself to run_thronglet, which distinguishes it from list_thronglets and the other siblings. An agent can tell exactly what this tool returns 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?

By stating it lists 'valid agent values for run_thronglet,' the description makes the intended call context clear: consult this before invoking run_thronglet. It does not spell out explicit when-not-to-use conditions or non-obvious prerequisites, so it falls short of a 5.

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

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

With no annotations, the description carries the full burden and does a good job: it defines the state enum, explains that accepts_messages=false means send_message will fail, and discloses the important caveat that live state belongs to this server while sessions from other throng instances may be stale records. It stops short of stating read-only/non-mutating nature explicitly.

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?

Dense but front-loaded: the verb and scope come first, followed by the returned fields and the freshness caveat. The long field enumeration is justified because there is no output schema to carry it, though it reads as a run-on list.

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?

No output schema exists, so the description must document return values itself, and it does so field by field, including the error field and cross-instance freshness semantics. An agent has everything needed to call and interpret this zero-param 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?

The tool takes zero parameters, so there is nothing for the schema to describe and the baseline is 4. No parameter-level ambiguity exists for the agent to resolve.

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 (lists) and resource (thronglet sessions) with a clear scope qualifier ('on this machine'), and enumerates the returned fields. It does not explicitly name the sibling tools it is distinct from, but 'list' versus run/cancel/send/wait is unambiguous.

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?

Usage is implied rather than stated: the agent can infer this is the discovery/inspection call before acting on a session. There is no explicit when-to-use, when-not-to-use, or pointer to an alternative sibling, so guidance is only adequate.

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

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

With no annotations, the description carries the burden and largely does: it discloses the exact success payload shape, the structured-vs-text substitution under schema, and the different return shape under background: true. It omits failure/timeout behavior, cancellation interaction, and whether a returned session_id can be reused for send_message.

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 core action and return contract, then the schema and background variants, with no filler sentences. It is dense to the point of being run-on, but each clause conveys distinct operational information.

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 7-parameter, nested-object tool with no output schema, the description correctly takes on the burden of documenting the return envelope and the background variant. It leaves gaps around error handling and session reuse (send_message), which a caller of a long-running agent runner would plausibly need.

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 100%, so the baseline is 3, but the description adds real meaning on top: it explains that `description` surfaces in session listings and that `schema` swaps `structured` for `text`, and it clarifies the background flag's semantics beyond the schema wording.

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+resource: runs an agent of an installed harness on a task in cwd, and returns its final message. It also distinguishes itself from siblings by pointing at list_harnesses for valid agent values and wait_thronglet for result collection, so an agent can place it in the family without opening schemas.

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 clear routing: use list_harnesses to resolve the agent string, use background: true plus wait_thronglet when you don't want to block. It does not address when to prefer this over send_message (new run vs. continuing an existing session), which is the most likely sibling confusion.

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

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

With no annotations, the description carries the full burden and does so well: turns never overlap, a message waits for the running turn, background returns {session_id, state, queued}, steer aborts the in-flight tool call and may leave a half-applied edit, and sessions whose harness cannot resume/load accept no messages at all. These are exactly the non-obvious behaviors an agent needs.

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 purpose and return shape are front-loaded in the first sentence, and no sentence is filler. However, several sentences pack multiple clauses (waiting semantics, steer ordering, harness failure) and require re-reading, which costs some clarity.

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, but the description supplies the return shapes itself (same JSON as run_thronglet, or {session_id, state, queued} in background mode) and covers the failure case for non-resumable sessions. Nothing an agent needs 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so per-parameter meaning is already documented and a baseline of 3 applies. The description goes beyond the schema by explaining cross-parameter behavior: queued messages follow a steer, and the result of a background call must be collected with wait_thronglet.

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 first sentence states a specific verb+resource+scope: it sends the next message into an earlier session identified by a session_id from run_thronglet, and it returns the same JSON as run_thronglet. This clearly separates it from run_thronglet (which creates the session) and from the other 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 gives clear context for use: message an existing session, use background:true to return early and collect via wait_thronglet, use steer:true to interrupt a running turn. It implies but never explicitly states the alternative (start a new session with run_thronglet), so routing guidance is strong but not fully spelled out.

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

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

With no annotations, the description carries the full burden and does well: it discloses the timeout behavior (returns {session_id, state, queued} instead of an error), idempotency, and that results are persisted with the session. It stops short of auth requirements or rate limits, but the core behavioral traits are covered.

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?

Three dense sentences with zero waste; the primary behavior is front-loaded and the timeout and idempotency caveats follow logically. Every sentence earns its place.

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?

With no output schema, the description must explain return values, and it does: both the success path (run_thronglet JSON or its error) and the timeout path ({session_id, state, queued}). It leaves the possible 'state' values undefined, but for a wait primitive this is largely complete.

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 100%, so both parameters are already documented in the schema, and the description's timeout detail (state returned instead of error) mirrors the schema description rather than adding new meaning. Baseline 3 is appropriate when the schema does the heavy lifting.

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 (waits) and resource (session turn), and explicitly distinguishes itself from run_thronglet by noting it returns 'the same JSON as run_thronglet, or its error'. An agent can tell what this does and how it relates to the sibling 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?

The tie to run_thronglet ('session_id from run_thronglet', 'same JSON as run_thronglet') implies this is used to await a previously started run, but there is no explicit when-to-use or when-not guidance, nor a named alternative (e.g., polling run_thronglet). Usage is inferable but not stated.

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