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

Annotations already declare destructiveHint=true, openWorldHint=true and idempotentHint=false, so the safety profile is covered externally. The description usefully adds that a durable task and A2A context mapping are returned (relevant for continuation), but it never explains the non-idempotent/destructive posture or how mode affects blocking behavior.

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 sentence, front-loaded with the action and followed by the return-value clause; nothing is padded. It is dense with domain jargon ('A2A context mapping', 'bridge task') that is never unpacked, which slightly undercuts 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?

With a rich 9-parameter schema, full annotations and an output schema, the description does not need to carry everything. Still, for a conversation-continuation tool it omits the practical guidance an agent most needs: how the returned task/context IDs feed back into subsequent calls.

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 78%, so the schema already documents mode, profile, timeout, context_id, idempotency_key and conversation_key. The description's phrase 'A2A context mapping' loosely echoes context_id but adds no syntax, defaults, or reuse rules 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 or continue a Hermes conversation') and adds a distinctive output promise ('durable bridge task and A2A context mapping'). It does not, however, name or contrast any sibling (e.g. hermes_task_wait, hermes_contexts), so an agent must infer where this sits in the family.

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?

'Start or continue' implies a lifecycle but gives no explicit when-to-use guidance: nothing says when to reuse task_id/context_id versus starting fresh, nor when to prefer sync over async. No alternatives or exclusions 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?

Annotations already provide idempotentHint=true and destructiveHint=false. The description adds a specific behavioral guarantee that 'close never deletes Hermes data,' which goes beyond the annotations and clarifies safety. No contradictions with annotations, and the tool is low-risk, so this level of disclosure is adequate.

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 a single sentence that front-loads the core actions (list, inspect, close) and adds a crucial caveat about data safety. Every word earns its place, with no redundancy or 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?

The tool is simple with all parameters optional and documented, an output schema present, and annotations covering idempotency and destructiveness. The description adequately covers the actions and a behavioral guarantee. It does not explicitly address parameter-action pairing, but the schema descriptions already convey that, so the overall context is sufficient.

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%, with each parameter having a clear description (e.g., 'Mapping operation', 'Select a mapping by A2A contextId'). The tool description does not add additional parameter-level meaning, so the baseline of 3 for full schema coverage 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?

The description clearly states the tool's function: listing, inspecting, or closing bridge-owned conversation/context mappings. It names the specific resource and actions, making the purpose unambiguous. While it does not explicitly name sibling tools for differentiation, the resource is distinct enough that the purpose is clear.

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 its usage for managing context mappings but provides no explicit guidance on when to choose this over alternatives or when not to use it. Siblings are clearly different in scope, so the decision is straightforward, but the lack of explicit routing or exclusion prevents a higher score.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the specific scopes of the check (bridge persistence, health, connectivity, Agent Card summary), which is useful context, but it does not detail return structure, latency, or other behavioral nuances. This is consistent with the annotations, so no contradiction.

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 a single, clear sentence with no filler. It front-loads the primary action ('Check') and then lists the elements, making it immediately scannable for an agent.

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 status-check tool with no parameters, full read-only annotations, and an output schema present, this description provides all necessary context. It covers the full scope of the tool's function and leaves no ambiguity about what it reports.

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 has zero parameters, so the description does not need to explain parameter semantics. With an empty schema, the baseline of 4 applies, and the description's mention of what is checked is sufficient.

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 the specific verb 'Check' and enumerates the exact resources checked: bridge persistence, Hermes health, connectivity, and Agent Card summary. This clearly distinguishes it from sibling tools like hermes_chat or hermes_task_get, which perform other functions.

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 is implied: the description states it checks various status aspects, making it evident this is for status queries. However, it does not explicitly mention when to use it instead of alternatives or any exclusions, lacking the direct guidance seen in stronger examples.

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?

The description goes beyond the annotations (all false) by explicitly warning that cancellation is only a request and that Hermes may continue underlying computation. This is a critical behavioral disclosure that prevents the agent from assuming the task will be stopped, and it surfaces a non-obvious execution semantic.

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 compact sentence that front-loads the core action ('Request task cancellation') and immediately follows with the most important caveat. Every word earns its place; there is no redundancy or extraneous detail.

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?

The tool is simple with only two parameters and has an output schema, so the description only needs to cover the critical behavioral uncertainty, which it does. It doesn't discuss edge cases (e.g., cancelling a completed task), but given the presence of an output schema and the straightforward nature of the operation, this is sufficient.

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 input schema already provides 100% coverage for both parameters (task_id and timeout) with meaningful descriptions. The tool description adds no additional information about parameter usage or syntax, so it relies on the schema, which is the baseline case.

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 'Request task cancellation' clearly identifies the action (request cancel) and the target (a task), and the 'request' caveat immediately distinguishes it from guarantee-style operations. This separates it cleanly from sibling tools like hermes_task_get, hermes_tasks_list, and hermes_task_wait.

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 intended use is implied by the name and description, but there is no explicit guidance on when to choose cancel over wait or get, nor any mention of conditions or exclusions. It doesn't tell an agent when cancellation is appropriate or when it might be too late to attempt.

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?

Annotations declare readOnlyHint=false and idempotentHint=false, so the agent already knows this is not a pure read. The description adds that acknowledgement is optional and that origin is verified, which explains the mutating profile, but it doesn't disclose what acknowledging actually does (marks consumed, irreversible?) or why the call is non-idempotent.

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 that leads with the core action and attaches the optional behaviour at the end. No wasted words, though the clause is packed tightly enough to be slightly cryptic.

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 described. For a tool that mixes a read with an optional state-changing acknowledgement, the definition is adequate but leaves the acknowledge side-effect and sibling selection under-explained.

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 only 50%: task_id and refresh are documented in the schema, while expected_origin and acknowledge_result_id are not. The description partially compensates by naming both undocumented parameters and their roles (consumption, origin verification), which is the baseline for this coverage level, but it gives no format or matching semantics for expected_origin.

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?

Clear verb+resource: 'Get a task/result' names both the action and the object, and the acknowledgement clause signals the consumption semantics. It does not, however, distinguish itself from siblings like hermes_task_wait, hermes_tasks_list, or hermes_task_cancel, so the agent must infer the boundary.

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 hints at a retrieve-then-acknowledge flow ('optionally acknowledge a consumed result_id'), which implies one usage scenario, but it never states when to use this tool versus hermes_task_wait or hermes_tasks_list, nor any exclusions or prerequisites.

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?

Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds the 'durable' characteristic and filter behavior, which is useful, but it does not disclose ordering, pagination behavior, or how status values map to concrete bridge states.

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 a single, front-loaded sentence with no filler. It communicates the core operation and the optional filters efficiently, and every word contributes meaning.

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 optional-parameter listing tool, the description combined with fully documented schema, strong annotations, and an output schema is nearly complete. It could be improved by explicitly directing agents to sibling tools for single-task retrieval, but no critical invocation details are 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 description coverage is 100%, so the parameters limit, status, and conversation_key are already documented. The description only loosely echoes the filtering parameters without adding new format constraints, allowed values, or behavioral details beyond 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 states a specific verb ('List'), a specific resource ('durable bridge tasks'), and the optional filtering dimensions ('conversation and bridge state'). It clearly distinguishes this tool from siblings like hermes_task_get, hermes_task_wait, and hermes_task_cancel by signaling a listing operation rather than a single-task or mutation operation.

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 when to use the tool: when you need to list bridge tasks, optionally filtered by conversation or status. However, it provides no explicit guidance about when not to use it or when a sibling such as hermes_task_get or hermes_task_wait would be more appropriate.

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?

The description discloses the operational mechanism (active stream, A2A subscribe, polling fallback), which adds value beyond the annotations. Since annotations already declare readOnlyHint=true and idempotentHint=true, the description's detail about stream/subscribe/polling provides useful context about how the wait is implemented without contradicting the annotations.

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 a single sentence that front-loads the core action ('Wait for task progress/result') before detailing the fallback mechanism. No redundant words or filler; every phrase 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?

The description covers the primary purpose and mechanism but omits explicit usage scenarios versus alternatives, timeout behavior (e.g., what happens on timeout), and error handling. While the output schema and annotations provide some coverage, the description alone is insufficient for an agent to fully understand when and how to use this tool in a broader workflow.

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 input schema fully describes both parameters (task_id with 'bridge_task_id or known A2A task id' and timeout with 'Maximum wait in seconds'), so the description adds no extra parameter meaning. With 100% schema coverage, a baseline of 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?

The description starts with 'Wait for task progress/result', which clearly states the action (wait) and resource (task). It differentiates from siblings like hermes_task_get (which likely fetches status without blocking) and hermes_task_cancel (which cancels). The mechanism detail further clarifies intent, making the purpose 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?

The description implies this tool is for blocking until a task progresses or completes, but it does not explicitly state when to prefer it over hermes_task_get or hermes_status. No alternatives are named and no 'when not to use' guidance is given, leaving the agent to infer from sibling names.

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