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

No annotations exist, so the description carries the full disclosure burden. It does add real value by describing the response ('the request and anything else the peer said') and the decline path, but it omits state-change consequences: whether the peer is notified, what status the task moves to, whether the action is reversible via cancel_task, or what happens with an already-accepted or expired task.

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 short sentences, front-loaded with the action and followed by return behavior and the alternative. Every sentence carries information; minor awkwardness in 'anything else the peer said' but nothing wasteful enough to penalize.

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?

An output schema exists, so the return value needn't be explained in depth, and the key routing information is present. However, for a mutation tool with zero annotations and one undocumented parameter, the description should at minimum cover reversibility, notification side effects, and error conditions before it is 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 50% — message is documented in the schema, task_id is not. The description partially compensates by implying task_id originates from list_available_tasks, but never explains the identifier's format, scope, or failure behavior for a stale/unknown id. Baseline 3 is appropriate given the schema does half the work.

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 ('Take on new work') and immediately anchors the source of that work via list_available_tasks. It also names the contrasting action path (update_task with rejected), so an agent can distinguish it from siblings like accept vs. delegate vs. reply without opening their 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?

Explicitly tells the agent when to use this tool (on work surfaced by list_available_tasks) and gives a concrete when-not with the exact alternative call (update_task with rejected). This is the rare case where the exclusion and its replacement are both 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 real work: it discloses that the call is tolerant of already-finished tasks, returning 'the final state it had already reached' rather than failing. It omits permission requirements, effects on the delegatee, and whether cancellation is reversible.

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 short sentences, zero filler, with the action front-loaded and the outcome semantics second.

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 tool with an output schema present, the description covers purpose, scope, and the tricky already-completed case. Only parameter meaning and permission prerequisites are left implicit.

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 0%, so the description must compensate for the single task_id parameter. It only implies the constraint that the task must be one you delegated; it adds nothing about identifier form or what an out-of-scope id does.

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 ('Stop a task') plus a scope qualifier ('you delegated') that separates it from accept_task, delegate, and update_task. An agent can pick it 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?

'You delegated' implies the prerequisite, but there is no explicit when-to-use versus alternatives such as update_task or delete_session, and no when-not guidance (e.g. tasks not delegated by you).

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 does disclose key behavior: this is asynchronous ('start', not 'run'), it returns task_id/state/version, and the answer may be included immediately if the peer responds quickly. It omits failure semantics, permission/auth requirements, and what cancellation via time_limit_minutes does to returned state, which keeps it from a 5.

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 tight sentences with the action front-loaded, then the return contract, then the follow-up pointer. No filler and no repetition of schema content.

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?

An output schema exists, so return values needn't be spelled out, yet the description helpfully summarizes task_id/state/version and the immediate-answer case. For a mutation tool with zero annotations, however, it could say more about session semantics and what happens when the peer is unreachable or the time limit trips.

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 peer, message, session_id, and time_limit_minutes are already fully documented in the schema, including the default of 60 minutes. The description only reinforces the list_peers linkage for peer, adding no semantics beyond the structured fields; baseline 3 applies.

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 ('Start a task on a peer') and explicitly names the discovery sibling list_peers for resolving the peer. It also names get_delegated_task_updates as the follow-up tool, so an agent can place it precisely in the delegation workflow.

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?

Clear routing guidance: use list_peers to find the peer and get_delegated_task_updates to follow the task afterwards. It doesn't state when *not* to delegate (e.g., local task tools like update_task) or any prerequisites such as needing an existing session, so it stops short of full when/when-not coverage.

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 cascade (tasks removed, running tasks cancelled on peers), which is exactly the behavioral context an agent needs before calling a destructive tool. It stops short of stating irreversibility explicitly or noting permission/auth requirements.

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 tight sentence with the outcome front-loaded after the trigger phrase. Every clause earns its place by conveying a distinct cascade effect.

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?

An output schema exists so return values need no explanation, and the cascade behavior is covered. But for a destructive, unannotated tool, the definition says nothing about irreversibility, failure modes (e.g., session already ended), or permissions — meaningful gaps remain.

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?

One parameter with 0% schema description coverage, and the description never mentions session_id or what a valid identifier looks like. It does not compensate for the schema gap, leaving the agent to infer the parameter's meaning entirely from its name.

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 ('removes a session') plus the cascading effects on tasks and peer-running tasks. It does not explicitly name a sibling or contrast with cancel_task/start_session, but the action is unambiguous and distinct within the sibling list.

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?

'Done with a session' implies the trigger condition (session no longer needed), which is a reasonable usage hint. However, there is no explicit when-not guidance, no mention of alternatives (e.g., cancel_task for individual tasks), and no prerequisites stated.

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?

Since there are no annotations, the description must carry the full burden. It successfully discloses key behavioral traits: the specific content returned (state, messages, outputs), and the waiting behavior enabled by combining the wait_seconds and after_version parameters. This adds significant contextual depth beyond the input schema.

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 definition is effective but slightly conversational. While dense with information, the structure places the critical scope definition (updates on delegated tasks) first, followed by technical use cases and finally the sibling routing advice.

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 the existence of an output schema, the description doesn't need to explain return structure. It provides all necessary context for an agent to understand the tool's scope (delegated tasks), its monitoring capability (wait_seconds/after_version), and its relationship to other tools (get_task_full).

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?

Although schema coverage is only 67%, the description clearly explains the semantics of the optional parameters. It describes the interdependent nature of wait_seconds and after_version, explaining that the waiting mechanism is triggered by using a specific version identifier, which adds practical meaning to the parameters.

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 clearly defines the tool as the place to check the status of a delegated task. It differentiates itself by focusing on task 'updates' (state, peer messages, outputs) rather than providing the full task details, and it explicitly refers to get_task_full as the alternative for the whole conversation.

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 usage guidelines are exceptionally clear: it advises against relying on the tool for long-term monitoring ('no need to if this session gets toli's notifications') and explicitly directs the agent to use the 'get_task_full' sibling tool when broad conversation context is required. This preemptive guidance prevents misapplication.

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 are provided, so the description carries the burden. It does disclose the payload breadth ('everything', 'whole conversation and all outputs'), which implies a read-only retrieval, but it never states that it is non-mutating, says nothing about permissions or whether it errors for tasks not owned by the caller, and leaves polling/side-effect behavior implicit.

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 short sentences with the payload scope front-loaded and no redundant restating of the tool name. The second sentence is terse to the point of being cryptic, but it earns its place as the only usage signal.

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?

An output schema exists, so return-shape detail is unnecessary, and with one parameter the surface is small. However, with zero annotations the description should at least confirm this is a safe read and clarify the 'not to wait' alternative; it does only the former implicitly and the latter not at all.

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 0% and the single required parameter task_id is never mentioned in the description. The phrase 'delegated or assigned to you' loosely bounds which task IDs are valid, but format, source, and failure behavior for an invalid ID are undocumented in both schema and description.

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 ('get') and resource ('a task') plus the scope of the return payload: the whole conversation and all outputs. It also scopes to tasks 'delegated or assigned to you', which helps separate it from the many list/update siblings, though it never names a specific sibling tool.

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?

'Use it to catch up, not to wait' gives implied guidance and even a when-not, but the alternative it is contrasting with (presumably get_delegated_task_updates) is never named. An agent must infer which sibling corresponds to 'wait'.

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 disclose useful traits: sort order (newest first), default filter (working and input-required), and that each result includes the count of unresponded peer messages. It omits pagination/limit behavior, which is the main remaining 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?

One dense sentence that front-loads the identity of the tool and then adds ordering, default scope, and the unresponded-message metric. Slightly comma-heavy but 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?

Return values need not be explained because an output schema exists, and the description covers the essential calling context: default state, ordering, and a notable aggregate field. It could be more complete by naming allowed state overrides or sibling alternatives.

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% and the single parameter is fully documented in the schema, including its default. The description's 'by default what's still in progress' restates the default but adds little syntax or semantic detail beyond the schema, so baseline 3 applies.

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 ('Work you've accepted' = list accepted tasks) and describes ordering and default scope. Sibling differentiation is implicit via 'accepted' versus list_available_tasks / list_delegated_tasks, but those siblings are never named, so an agent must infer the distinction.

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 phrase 'by default what's still in progress' implies when this tool is useful and what the default filter does, but it never says when to prefer list_delegated_tasks or list_available_tasks, nor when to override the state parameter.

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 are provided, so the description carries the full burden. It usefully discloses newest-first ordering and that wait_seconds blocks when no work is available, but it does not state read-only safety, pagination behavior, or permission requirements.

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 short sentences, front-loaded with the core resource and ordering, with the wait behavior appended only as needed. There is no redundant or wasted text.

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 simple one-parameter listing tool with an output schema, the description covers the essential behavior and wait semantics. The main minor gap is the absence of explicit read-only framing, though 'list' strongly implies it.

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 single parameter is already documented in the input schema. The description's note about wait_seconds largely repeats the schema's explanation rather than adding new semantic detail.

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 clearly identifies the resource as new work sent by peers that has not yet been accepted, and specifies newest-first ordering. It implicitly distinguishes this from accepted-task siblings via 'haven't accepted yet,' but does not name an alternative tool explicitly.

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 description implies this is for checking pending peer tasks and explains the wait behavior when no tasks exist. However, it does not explicitly state when to use this versus list_accepted_tasks or list_delegated_tasks.

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?

Since no annotations are provided, the description must carry all behavioral context. The specification 'newest first' is a crucial behavioral trait regarding the sorting and return order that is not captured in the input schema, providing significant value to the AI agent.

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 description is highly efficient, using a single, well-structured sentence to convey the core function, sorting behavior, and optional filtering criteria.

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 that an output schema exists, the description provides maximum necessary context for successful tool invocation by defining the scope, constraints, and inherent sorting behavior of the resulting list. It is complete for a read-only list operation.

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?

With 100% schema coverage, the description's role is supplementary. It provides helpful human context for the parameters, defining 'state' as requiring an example ('input-required') and clarifying the focus on 'session' vs. general tasks.

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 clearly defines the resource ('tasks you delegated') and the operation ('Find'), making it unambiguous. The context implies this tool retrieves tasks assigned to the current user by another party, effectively distinguishing it from other list-type 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 explicitly guides the user on how the tool should be constrained by the caller by describing the optional filtering logic ('optionally only a session's or only one state'). This helps the agent determine the necessary scope for the API call.

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 are provided, so the description must carry the behavioral load. It does disclose the return content (per-peer purpose and reachability), which is useful context beyond the name, and 'list' implies a read-only operation. It stops short of stating whether the roster is scoped to the caller, how reachability is determined, or how failures are reported.

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 clause that names the resource and enumerates the per-entry fields with no filler. It is efficient, though the fragmentary phrasing ('with what each does') is slightly informal for a tool contract.

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?

An output schema exists, so the description needn't enumerate return fields, and it correctly only hints at the shape (purpose plus reachability). With zero parameters and a simple read operation, little else is required, though a note on scope or staleness of the peer list would have made it 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?

The tool takes zero parameters, so the baseline of 4 applies. The description correctly implies no filtering or selection arguments are needed, consistent with the empty schema.

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?

Names the resource (peers available for delegation) and what each entry conveys: capability description and reachability. It distinguishes itself from task-oriented siblings like list_available_tasks and list_delegated_tasks by making clear the subject is peers, not tasks. The verb is only implied by the tool name rather than stated, which keeps it just short of a 5.

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 connection to delegate is implicit in 'peers you may delegate work to', so an agent can infer this is a discovery step before delegating. However, there is no explicit when-to-use or when-not-to-use statement and no sibling is named as an alternative, leaving routing entirely 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. It does disclose the interaction model — an asynchronous peer that is actively working and can be interjected with — which is genuinely useful beyond the name. However, it says nothing about what happens on an invalid task_id, whether the reply blocks or is fire-and-forget, or whether messaging alters task state.

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 tight sentence with the resource and recipients front-loaded and the two use cases enumerated parenthetically. No wasted prose, though the parenthetical makes the sentence slightly dense.

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?

An output schema exists, so return values need not be explained. For a simple two-parameter messaging tool the description covers intent and triggers adequately, but with an undocumented task_id and no error or delivery semantics, an agent still lacks enough to call it confidently in edge cases.

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 50%: 'message' is documented in the schema with an example, while 'task_id' is bare. The description adds meaning by framing task_id as the delegated task and message as either an answer or a working note, but it does not clarify task_id format or origin (e.g., from list_delegated_tasks).

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 names a specific verb ('Message the peer') and a specific resource ('a task you delegated'), so an agent can tell it is a send-a-message operation rather than task state mutation. It does not explicitly contrast itself with siblings like update_task or delegate, so it stops short of a 5.

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 trigger conditions: use it to answer a peer's input-required question, or to send informational context while the peer works. It scopes usage to tasks you delegated, implicitly excluding accepted/available tasks. No explicit alternatives (e.g., 'use update_task to change state instead') 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?

No annotations are provided, so the description carries the full burden. It usefully discloses that the session yields a session_id intended for delegate, but says nothing about session lifetime, whether titles must be unique, or whether duplicate sessions are created on repeated calls.

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 short sentences, zero filler, with the core action front-loaded and the downstream handoff stated second. Nothing here is redundant or padded.

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?

An output schema exists, so return values needn't be explained, and the single parameter is fully covered in the schema. What's left unsaid is session lifecycle and its relation to delete_session, a modest gap for such a small 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?

Only one parameter and schema coverage is 100%, so the schema already documents title fully. The description's example ("users api") reinforces the grouping intent but adds no syntax or constraint details beyond what the schema states.

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 ("Start a session") plus the reason it exists ("group related tasks"), with a concrete example. It hints at the relationship to delegate, though it doesn't explicitly contrast with siblings like delete_session or the list_* 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?

Gives clear context for when this applies — grouping related tasks under a titled session — and tells the agent the next step by pointing at delegate. It stops short of explicit exclusions (e.g. when not to create a new session versus reusing an existing one).

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 still discloses distinctive behaviors: batching all questions in one message, keeping one open question at a time, and having wait_seconds block for an answer. It omits state-transition rules, whether terminal states are irreversible, permission/auth requirements, and other side effects, so it does not fully carry the behavioral burden.

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 description is compact and front-loads the task/peer context before enumerating states. The single long sentence with nested parentheticals is dense and slightly harder to scan, so it is good but not maximally clear.

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 five-parameter mutation tool with an output schema and no annotations, it covers purpose and the important interaction modes. It still leaves the agent to infer sibling-tool routing and task lifecycle constraints, so it is strong but not 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 already high at 80%, so the baseline is 3, but the description adds cross-parameter meaning by linking wait_seconds to input-required and emphasizing that all questions belong in a single message. It also clarifies the purpose of each state, though task_id is left obvious from the schema.

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 names the resource (work you accepted) and the concrete state-based actions (post progress, ask, finish, give up, decline), so it is more than a restatement of update_task. It does not explicitly contrast with siblings such as reply or cancel_task, which keeps it from a 5.

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 each state value, including when to use working, input-required, completed, failed, or rejected, so invocation is reasonably guided. However, it does not say when to use update_task rather than reply, accept_task, cancel_task, or other siblings, and offers no exclusions.

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