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 and no output schema, the description carries the full disclosure burden and does well: it reveals that both available and unavailable harnesses are returned, that unavailability comes with a reason, and that server limits are included. It does not explicitly state the operation is read-only, though 'Lists' strongly implies a safe read.

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?

A single front-loaded sentence with no filler. The purpose and the returned structure are packed into one clean clause.

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 zero-parameter tool with no output schema, the description adequately explains the return payload, covering available, unavailable, and limit categories. Minor gaps remain about exact format or size of the response, but nothing essential for correct invocation 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?

The tool takes zero parameters, so the baseline of 4 applies. The description correctly implies no filtering or selection arguments are needed to obtain the full harness list.

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 (harnesses), then enumerates exactly what is returned: available harnesses with models and effort levels, unavailable ones with reasons, and server limits. This clearly separates it from siblings like list_thronglets, since it is specifically about agent values consumed by run_thronglet.

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 framing the output as the 'valid agent values for run_thronglet,' it implies the tool should be called to discover acceptable inputs before invoking run_thronglet. There is no explicit when-not or named alternative, but the usage context is unambiguous.

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 it does disclose a non-obvious behavioral caveat: live state reflects this server while sessions run by another throng instance show their recorded state. That is genuinely useful, but read-only safety, ordering, and staleness limits are not spelled out.

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 action and scope, followed by the field list and the cross-instance caveat. No filler.

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, so the description usefully enumerates the return fields (description, agent, cwd, state, queue length, timestamps, last error), which is exactly the compensation needed. Ordering and pagination behavior are the only gaps.

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 no parameter syntax to document; baseline 4 applies. Nothing is missing on this dimension.

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?

Specific verb (lists) and resource (thronglet sessions) with the returned fields enumerated, so the agent knows exactly what comes back. It is clearly distinguishable from siblings like list_harnesses and the mutating run_thronglet/cancel_thronglet tools.

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 by the name and the 'on this machine' scope, but there is no explicit statement of when to call this instead of wait_thronglet or run_thronglet, and no exclusions or prerequisites. Adequate but leaves routing to inference.

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 real work: it discloses the JSON return shape ({session_id, text, stop_reason, usage, duration_s, warnings?}), the structured-output substitution, and the background return contract ({session_id, state, queued}). It implies filesystem impact via "the agent works in this tree" but never states permissions, reversibility, or that the run mutates cwd.

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?

Everything is front-loaded into one dense paragraph with no filler, and the return contract comes first. The semicolon-chained clauses make it slightly harder to parse than a clean multi-sentence structure, 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?

No output schema exists, and the description compensates by documenting both the sync and background return shapes plus the structured-output path, which is exactly what an agent needs. It stops short of noting cancel_thronglet as a lifecycle alternative or any failure/timeout behavior beyond the default config value.

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%, so the baseline is 3; the description earns above that by tying parameters to behavior the schema doesn't state — schema replaces text with structured, background returns early, and description feeds session listings. It adds meaning beyond the field-level docs.

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 ("Runs a coding agent") with named harnesses and the execution context (cwd), and it distinguishes this tool from the sibling wait_thronglet by explaining the async handoff. An agent can tell what this does 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?

It gives clear conditional usage for the background: true path and names wait_thronglet as the collection mechanism. It doesn't explicitly state when to prefer this over alternatives like send_message to an existing thread, but the sync/async guidance is concrete.

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?

No annotations, so the description carries the full burden and does so richly: turn serialization ('turns on one session never overlap'), the waiting behavior, the background return shape {session_id, state, queued}, and steer semantics including interruption of the in-flight call. This is exactly the kind of behavioral disclosure annotations would otherwise provide.

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?

Four dense sentences, front-loaded with the core action and session_id provenance, then waiting semantics, then background, then steer. No filler; every clause carries distinct 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?

Comprehensive for a 6-param mutation tool with no output schema: it covers return shape, concurrency, background and steer flows. It does not mention timeout_s behavior or the structured-output schema param, both of which are documented in the schema but the description stays silent on their runtime effect.

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%, so the baseline is 3, but the description adds non-obvious semantics: background returns early and needs wait_thronglet, and steer interrupts the running turn and jumps ahead of queued messages. That sequencing relationship between steer and queued messages is not derivable from the schema alone.

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 (sends) and resource (next message into an earlier session), and ties the session_id directly to the sibling run_thronglet. An agent can tell this apart from cancel/wait/list siblings immediately.

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?

Clearly positions this as the continuation mechanism after run_thronglet and routes to wait_thronglet for background collection. Does not explicitly say when-not-to-use, but the alternative and its trigger conditions are named.

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.