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

The description adds behavioral context beyond annotations by noting that 'the durable cursor advances monotonically and is scoped to this channel.' This explains the side effect of acknowledgment, which is not covered by the annotations. However, it does not discuss error cases or idempotency behavior, though idempotency is hinted by the annotation.

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 very concise, two sentences long, with no filler. It front-loads the purpose and adds a behavioral note in the second sentence.

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 is minimal. It covers the core purpose and one behavioral effect, but misses details like the meaning of metadata, how to obtain message_id, or error handling. With 4 parameters and a nested object, the description is not complete enough for an agent to know all inputs and expected outcomes, though output schema is present.

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 description does not explain the individual parameters. It mentions 'for a named consumer' but does not map that to consumer_id. The schema has 4 parameters with 0% coverage in the description, so the description fails to compensate. No information is given about channel, message_id, or metadata.

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 action: 'Acknowledge a message for a named consumer.' It specifies a specific verb and resource, and mentions scoping to channel, which distinguishes it from other bridge operations like send or receive.

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 provides no guidance on when to use this tool versus alternatives. It does not mention any exclusions or conditions for using it. There is no reference to sibling tools 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 declare readOnlyHint=true and destructiveHint=false, establishing the safety profile. The description adds that it lists active (not all) channels and includes message counts, which is useful context beyond the annotations, but it does not describe any other behavioral aspects such as performance, pagination, or filtering limitations.

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 extraneous words. It conveys the core action and the additional data included, making it maximally concise and well-structured.

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 there is zero parameters and an output schema exists, the description covers the essential scope ('active channels' and 'message counts'). It does not mention any potential limitations of 'active', but the output schema likely supports understanding the return. The description is sufficient for a simple enumeration 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 has zero parameters, so the schema requires no elaboration. The description adds no parameter-specific meaning, and per the rubric, a baseline of 4 is appropriate for zero-parameter tools.

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') and a clear resource ('all active channels') with an additional detail ('their message counts'). It is unambiguous and distinct from the sibling operations like bridge_send or bridge_receive, which are clearly not listing operations.

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?

No guidance is provided on when to choose this tool over siblings such as bridge_status or bridge_ping. The description implies it is for discovering channels, but does not mention exclusions or alternatives, leaving the agent to infer usage without explicit support.

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?

Adds a strong behavioral contract beyond the annotations: atomicity semantics, lease expiration, and requeue behavior, plus the long-poll hint. Consistent with annotations (readOnlyHint:false, idempotentHint:false, destructiveHint:false) — 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?

Three lean sentences with the core contract front-loaded ('Atomically claim the next task'), then the lease lifecycle and the key parameter hint. Every sentence earns its place with 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?

Covers the full concurrency and discharge lifecycle, and the presence of an output schema removes the need to describe return values. The remaining gap is empty-queue behavior (e.g., whether wait_seconds=0 means immediate failure or return-empty) — a detail that would only surface at the boundary, not in a typical invocation.

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?

Compensates for 0% schema coverage on two of four parameters: lease_seconds defines the lifecycle window and wait_seconds is explicitly tied to long-polling. But channel and consumer are wholly undocumented — especially the required 'consumer', whose meaning is not inferable from the description and doesn't get the accidental context.

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?

Says exactly what it does with a specific verb+resource: 'Atomically claim the next task from a channel's queue.' The uniqueness guarantee ('no two workers ever get the same task') plainly differentiates it from siblings like bridge_receive, bridge_ack, and bridge_tasks, so an agent can select 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?

Gives actionable context: complete or fail within the lease window or the task gets requeued, and sets wait_seconds to long-poll. It does not explicitly name when NOT to use this tool over bride_receive or bridge_ack, but the lease/atomicity framing makes the intended worker-pool scenario clear.

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 destructiveHint=true and idempotentHint=true, so the description does not need to restate the destructive nature. The description adds the purpose ('resetting state') and the scope ('all messages in a specific channel'), which provides some context beyond the annotations. However, it does not disclose any additional behavioral nuances (e.g., permanence, side effects on channel metadata) that are not already covered by 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 extremely concise, consisting of two short sentences that immediately convey the action and purpose. There is no redundant or extraneous information, and the key detail (the destructive action) is front-loaded.

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 tool with a single parameter, an output schema, and annotations that cover safety (destructive and idempotent hints), the description is largely complete. It explains the purpose and scope, and the output schema addresses return values. However, it does not explicitly warn about the irreversible nature of clearing all messages, although the destructiveHint annotation partially covers this. Minor gap but acceptable.

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 0%, so the description must clarify the parameter semantics. The description only vaguely references 'a specific channel' without explicitly naming the 'channel' parameter or explaining its format, constraints, or how it is used to identify the channel. This adds minimal value over the bare schema definition, leaving the agent to infer the parameter's role.

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 verb 'clear' and the resource 'all messages from a specific channel,' making the tool's function unambiguous. It adds a practical use case ('resetting state') that helps distinguish it from sibling tools like bridge_send, bridge_receive, and bridge_status, which serve different purposes.

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 provides a clear context for when to use the tool ('resetting state'), which implies a specific scenario. However, it does not explicitly mention alternatives or when not to use it, such as for partial deletion or non-destructive operations. This is adequate guidance given the tool's simplicity, but it lacks explicit exclusions.

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 indicate this is a write operation that is not idempotent and not open-world. The description adds valuable behavioral context beyond those flags: the completion depends on a valid lease_token from bridge_claim, and a stale lease invalidates completion. It does not speculating at all, and the account for possible invalid-token errors, but the main behavioral precondition is disclosed.

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 two sentences with no filler. The primary action is front-loaded, and the critical lease on constraint follows immediately. Every word contributes.

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 output schema exists and annotations cover mutation/idempotency, the description does not need to explain return values. The lease_token requirement and stale-lease restriction cover the main tricky workflow. The only real gap is the meaning of channel and task_id, which prevents a higher score.

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 only 25%, since only result has schema documentation. The description does add meaning to lease_token by identifying bridge_claim as its source, but it never explains channel or task_id, and it does not instruct how result is structured or used. This leaves most required parameters under-documented.

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 and resource: 'Mark a claimed task completed.' This clearly differentiates it from related sibling tools like bridge_claim, bridge_fail, and bridge_ack, and the lease_token condition reinforces what makes this tool distinct.

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 gives clear context: use this after a task has been claimed, and the lease_token from bridge_claim is required. It also states an explicit exclusion: a task whose lease expired and was reclaimed cannot be completed by the previous holder. It does not name sibling alternatives such as bridge_fail, so it stops short of full when/when-not guidance.

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 signal a mutating operation, and the description adds useful behavioral nuance: idempotency via idempotency_key prevents duplicate tasks on retry. It also explains that tasks are enqueued pending worker claim, which is meaningfully beyond the 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?

Two tight sentences: the first states the main action, and the second covers the critical payload/content distinction plus idempotency. No redundant wording or schema repetition.

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?

Covers the required invocation pattern and the most important optional safeguard (idempotency_key). With an output schema present and the remaining optional parameters largely self-explanatory or schema-described, the tool is adequately complete for an agent to call correctly.

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 description clarifies the key design choice between structured payload and string content, and explains idempotency_key's purpose. However, schema coverage is only 50%, and the description does not compensate for undocumented fields like enqueued_by or max_attempts.

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 (add/enqueue), a specific resource (a task in a channel's work queue), and the downstream behavior (held for a worker to claim). This clearly distinguishes it from sibling tools like bridge_claim or bridge_complete.

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 gives clear context: use this tool to enqueue tasks, distinct from claiming or completing them. It does not explicitly name alternative tools or when not to use it, so it falls just short of full routing guidance.

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?

Beyond what annotations already convey (mutation, non-idempotent), the description discloses the full state machine behavior: a failed task is requeued after retry_delay_seconds until max_attempts is exhausted and then dead-lettered. It also exposes the immediate dead-letter path (requeue=false) and the lease_token prerequisite — all operational behaviors the agent cannot infer from the annotations or schema. The description is consistent with annotations; 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 two sentences with no filler, front-loaded with the action verb. The second sentence efficiently captures the default retry behavior, the terminal dead-letter outcome, the immediate-path alternative, and the required resource. Every clause adds necessary behavioral 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?

With an output schema present, return-value explanation is unnecessary. The description covers the complete contract of this tool: the state transition, the retry/dead-letter timeout behavior, the forcing path to immediate dead-letter, and the token prerequisite from bridge_claim. Nothing missing that an agent needs to invoke this tool correctly within the bridge task lifecycle.

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 only 17%, so the description shoulders the explanatory load. It meaningfully explains the critical parameters: requeue (false => immediate dead-letter), retry_delay_seconds (the retry wait), and lease_token (source and meaning). The remaining parameters (channel, task_id, error) are left implicit — task identity is clear from the 'claimed task' context and the schema already describes error — so the compensation is strong but not exhaustive.

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 opens with the direct action 'Mark a claimed task failed,' which names the verb and resource clearly. It further differentiates this operation from the task-lifecycle siblings by spelling out the failure path (requeue/dead-letter), making it easy to distinguish from complementary tools like bridge_ack and bridge_complete.

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 gives a concrete and important prerequisite — 'Requires the lease_token from bridge_claim' — which tells the agent exactly when in the workflow this tool is valid. It also spells out the two usage paths (default requeue vs. requeue=false for immediate dead-letter), but it does not explicitly name the alternative tools (e.g., 'use bridge_complete when the task succeeded'), so the when-not guidance is implicit rather than 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?

The readOnlyHint annotation already indicates this is a safe read operation, and the description adds minimal context by mentioning a status summary. It does not elaborate on potential side effects, authentication requirements, or rate limits, but given the annotation coverage, a baseline score is appropriate.

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 concise sentence with no redundant words. It front-loads the core action (check if alive) and quickly mentions the secondary outcome (status summary), making it efficient and easy to parse.

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 simplicity of the operation (no parameters, no side effects) and the presence of an output schema, the description provides sufficient context. It hints at the return content (status summary), and the output schema would fill in exact details, so nothing critical 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?

There are no parameters to describe, so schema coverage is trivially complete. The description adds nothing about parameters, but with zero params the baseline score is 4, as there is nothing to clarify.

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 identifies the resource as the bridge server, clearly indicating a liveness/health check. It also mentions getting a status summary, which distinguishes it from other bridge operations like send, receive, or 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 description provides no guidance on when to use this tool versus alternatives. It does not mention specific conditions or contrast it with sibling tools such as bridge_status or bridge_receive, leaving the agent to infer the appropriate usage context.

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 indicate readOnlyHint=true and destructiveHint=false, and the description does not contradict these. However, the description does not clarify whether reading messages removes them from the queue or if they persist until acknowledged. Since a separate bridge_ack tool exists, this behavior is important but not specified, so the description adds only partial transparency.

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, concise sentence that avoids unnecessary detail or verbosity. It is well-structured, front-loading the primary purpose and then adding parameter-specific guidance in a clear order.

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 lacks an explanation of its output schema, which is present but not described. It also does not mention how it interacts with bridge_ack (e.g., whether messages are auto-acknowledged or require explicit ack). This incomplete context makes it difficult for an agent to fully understand the flow.

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 description only explains two of the four parameters: 'since_id' and 'consumer_id'. It does not explain the 'limit' parameter (pagination/volume control) or the required 'channel' parameter (which channel to read from). With 0% schema description coverage, this leaves significant gaps in understanding the correct invocation.

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 purpose: 'Read durable messages.' This is a specific verb with a defined resource, and it distinguishes itself from sibling tools like bridge_send, bridge_ack, and bridge_clear by focusing on reading rather than sending, acknowledging, or clearing.

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 provides parameter usage guidance for 'since_id' and 'consumer_id' but does not explicitly state when to use this tool versus alternatives such as bridge_wait (likely a blocking wait) or how it relates to bridge_ack. The absence of contextual usage instructions leaves some ambiguity for an agent deciding between tools.

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=false, destructiveHint=false, idempotentHint=false. The description adds the idempotency_key behavior (retry must not create duplicate), which is useful. It doesn't disclose what happens on failure, delivery guarantees, or whether the message is persisted. With annotations covering the basic safety profile, the description adds some value but not deep behavioral context.

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 sentences, each earning its place. The first states the action, the second explains the two payload options, the third covers idempotency. No fluff, front-loaded with the core purpose.

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 has 5 parameters, 2 required, nested objects, and an output schema. The description covers the key decision points (content vs message, idempotency_key). It doesn't explain the output schema, but that's available separately. It doesn't mention channel/sender requirements, but those are self-explanatory from the schema. Given the complexity, the description is reasonably complete for an agent to call it correctly.

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 40%, so the description must compensate. It explains the distinction between content (legacy) and message (versioned structured envelope), and the purpose of idempotency_key. This adds meaning beyond the schema, which only describes content as 'Legacy text or JSON' and message as 'Structured protocol-v1 envelope'. The description clarifies the semantic difference and the idempotency use 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 states a specific verb ('Publish') and resource ('durable message'), and distinguishes between two payload formats (content vs message). It doesn't explicitly name sibling tools, but the purpose is clear enough to differentiate from bridge_receive, bridge_ack, etc.

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 gives clear guidance on when to use content vs message, and when to supply idempotency_key. It doesn't explicitly state when not to use this tool or name alternatives, but the context of siblings (receive, ack, wait) implies this is the send operation. The guidance is practical and actionable.

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 annotations already declaring readOnlyHint=true and destructiveHint=false, the safety profile is covered. The description adds useful behavioral context by stating the tool aggregates messages across all channels rather than a single channel or a wait/ack mechanism, and frames it as a status-viewing 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?

The description is two purposeful sentences with no filler. The core action and scope are front-loaded in the first sentence, and the second sentence provides brief utility. Every word contributes value.

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 read-only status tool with one optional parameter, complete schema coverage, and an output schema, the description is sufficient. It explains the core result, the scope, and the likely use case without needing to document return fields or side effects.

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 covers the only parameter, per_channel, with a clear description and default. The tool description does not add much about parameter details, but the schema fully documents it, so a baseline score 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 states a specific verb and resource: 'Get the last N messages from ALL channels at once.' It clearly identifies the tool's unique aggregation behavior, distinguishing it from likely siblings like bridge_receive or bridge_channels that might target individual channels or channel metadata.

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 gives clear context: use this when you want a cross-channel snapshot, as suggested by 'full picture of what's happening across agents.' It does not explicitly name alternatives or state when not to use it, but the scope 'ALL channels at once' alone is a strong routing signal against channel-specific tools.

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 cover readOnlyHint and destructiveHint, so the description's 'Read-only' adds little. It does add that the response contains per-status counts and a recent task list, which is useful behavior context. However, it does not explain ordering, pagination, or what happens when the channel does not exist.

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 one focused sentence with no wasted words and front-loads the core operation. 'Read-only' adds a compact safety signal even though it is already captured by annotations.

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 and has an output schema, so return shape does not need to be repeated. Still, the description leaves important gaps: distinguishing bridge_tasks from bridge_status, explaining how the optional status parameter interacts with the counts, and noting any channel not found or permission behavior.

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 0%, so the description should compensate for parameter meaning, but it only weakly supports 'channel' and 'status' via wording. It does not explain how status affects the counts and list, what the limit bounds mean in practice, or what values like 'dead' imply semantically.

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 that bridge_tasks inspects a channel's task queue and summarizes it via per-status counts and a recent task list. It is specific about the resource and operation, but it does not explicitly distinguish itself from sibling tools like bridge_status or bridge_channels.

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 that this is for inspection and is safe to call, but it gives no explicit guidance about when to use it versus send, wait, ack, or status tools. It offers no scenarios, exclusions, or alternative tool recommendations.

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 adds meaningful behavior beyond the annotations: it explains the waiting mechanism (after since_id or durable cursor) and caps timeout at 55 seconds, which directly informs call behavior. The readOnlyHint and destructiveHint annotations already cover safety, and the description complements them without 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?

Exactly two sentences with no filler. The core guidance ('use instead of repeated polling') is front-loaded, and the timeout constraint is concise and essential.

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 output schema exists, the description need not detail return format. It covers the primary usage pattern (waiting after a cursor), the key cap (55s), and the polling alternative. The anyOf logic (since_id vs consumer_id) is inferable from the wording. Only minor gaps like limit semantics remain, but these are self-evident from the schema.

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 0% schema description coverage, the description must compensate. It explains since_id and consumer_id (the two trigger parameters) and mentions the timeout cap (relating to timeout_seconds), but does not explain limit or channel. Since those have defaults and are straightforward, partial compensation is acceptable but not complete.

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 waits for new messages, anchored by since_id or a consumer cursor. It names the resource and verb ('Wait efficiently for new messages'), and implicitly distinguishes itself from polling, though it does not explicitly contrast with sibling tools like bridge_receive.

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 recommends using this instead of repeated polling, which provides a clear alternative. It does not define when not to use it (e.g., when immediate reply is needed), but the guidance is actionable and unambiguous.

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