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

With no annotations, the description carries the full behavioral burden, and it does disclose two non-obvious traits: the sender-visible receipt format ('✔ taking #id: <note>') and the persistent per-prompt reminder until acknowledgement. It says nothing about repeating the call, invalid/past message ids, or any permissions, so failure and idempotency semantics are absent.

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 tight sentences, the core action front-loaded and emphasized before mechanics. The one slightly redundant clause ('does not have to ask whether you saw it') still earns its place by explaining why the acknowledgement matters.

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 document return values — yet it helpfully describes the receipt anyway. Given a two-parameter, low-nesting tool with no annotations, the only real gap is error/duplicate handling.

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 compensate. It defines `note` well ('one sentence on what you will do') and context implies `message_id` is the addressed message, but `message_id` gets no explicit definition or format guidance and the defaulted empty `note` behavior is unexplained.

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 object — acknowledging that you are taking an addressed message/task — and makes the state change explicit ('TAKING'). It does not distinguish itself from closely named siblings such as `ack`, `claim`, and `release`, which an agent could easily confuse with `accept`.

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 a clear, actionable trigger: do this now, BEFORE the work, and repeats that the hook will nag until you do. That is strong timing guidance, though it never names an alternative tool or an exclusion case (e.g., when to `release` or when `ack` would be the right call instead).

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 full behavioral burden. It hints that active leases require a valid token, but says nothing about idempotency, what state transitions ack triggers, whether it's destructive, or what happens on a failed/expired lease.

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 compact sentence with the core action front-loaded and no filler. It is efficient, though brevity comes at the cost of substance rather than through careful editing.

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, but for a state-changing acknowledgment tool with zero annotations and fully undocumented parameters, the description leaves critical call-time details (valid states, token requirement, error handling) unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema description coverage is 0% across 4 parameters. The description obliquely references state ("confirm the state") and lease_token ("the right token") but never explains valid state values, the message_id target, or the purpose of the error field, so it fails to compensate for the coverage gap.

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?

"Confirm the state of your own delivery" conveys the resource (a delivery/message) and the act of acknowledging it, but the verb is fuzzy and it never states what an acknowledgment actually does or how it differs from siblings like accept, claim, or release.

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 clause "an active lease needs the right token" implies a precondition for one scenario, but there is no guidance on when to use ack versus accept, claim, release, retry, or cancel, and no statement of 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?

With no annotations, the description carries the full burden and does disclose one real behavioral trait: 'its history is kept,' signalling the record isn't purged. It omits permission requirements, whether cancellation is reversible, what happens to the recipient's state, and whether retry afterward is possible.

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 short sentence that front-loads the action and appends the important side effect. Nothing is wasted and no clause needs rereading.

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 mutation tool with no annotations and two undocumented parameters, the description is thin: it covers the key 'history kept' fact but not authorization, reversibility, or the meaning of its arguments.

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% for both required parameters, and the description explains neither 'message_id' nor 'recipient'. It does not clarify whether recipient identifies the sender, the destination, or the actor whose delivery is cancelled — a gap the schema leaves entirely open.

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 ('Cancel an unfinished delivery') and scopes it to unfinished ones, which separates it from a plain status change. However, it never differentiates itself from plausible siblings like 'release', 'retry', or 'ack', which an agent must choose between.

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 'unfinished delivery' implies a precondition (only in-flight deliveries are cancellable), giving implied usage context. It offers no explicit when-to-use, when-not-to-use, or alternative (e.g. release vs cancel) guidance, so routing between siblings is left 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?

No annotations are provided, so the description carries the full burden and does so well: it discloses atomic all-or-nothing acquisition, that failures return the current holder and remaining duration, that leases self-expire preventing deadlock from crashed agents, and that a directory lease covers its entire subtree. This is exactly the behavioral context an agent needs before calling.

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 core action and atomicity guarantee are front-loaded in the first line. The blocked-case advice reads slightly informally ('wait, take other work, or ask via say/send') but each sentence adds usable information with little waste.

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 elaboration, and the description still usefully previews the failure payload. For a 3-parameter mutation-style tool it is nearly complete, missing only guidance on purpose/ttl usage and a pointer to release for giving a lease back.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema description coverage is 0%, so the description must compensate. It explains `paths` thoroughly (files or directories, directories cover everything beneath) and hints at `ttl_seconds` via lease expiry, but never explains `purpose` or how a caller sets/extends the lease duration.

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: 'Lease the files or directories you are about to change.' An agent can immediately distinguish this from siblings like release, say, or send, and the all-or-nothing semantics sharpen the identity further.

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 use ('reserve ahead — typically before running a script that touches several files') and names alternatives for a blocked case (say/send to ask the holder). It also explains that editing a free file auto-claims via a hook, so explicit claiming is not always needed. The natural counterpart tool, release, is never mentioned, which is the one gap.

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 are absent, so the description carries the full behavioral burden. It does disclose the categories of events returned (lease, refusal, blocked edit), which is genuine content-level transparency, and the phrasing implies a read-only inspection. But it never states that this is non-mutating, whether it requires permissions, or how results are bounded/paginated despite there being a limit parameter.

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 no filler; the summary of what history returns is front-loaded ahead of the usage trigger. The quoted example intent is slightly informal but earns its place by grounding the trigger condition.

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-value formatting needn't be explained, and the description does cover purpose and trigger. The gap is behavioral and parameter detail: with no annotations and 0% schema coverage, an agent still lacks guidance on what path/limit do and whether the call is safe and bounded. Adequate but incomplete for a 2-param lookup 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?

Schema description coverage is 0% across two parameters (path, limit), and the description adds no semantics for either — it never explains that path scopes the history to a specific file or that limit caps result count. With low coverage the description is expected to compensate, and it does not.

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 (edit/lease history) and the content of the result set — who touched what and how it ended (lease, refusal, blocked edit) — which is far more specific than the bare name 'history'. It distinguishes itself from siblings like owner, claim, and release by framing the tool as a retrospective audit rather than a state-changing action. However, the action verb is only implied ('Ask this') rather than stated as a retrieval 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?

Explicit trigger is given: 'Ask this after a collision' with a quoted user intent ('why was my edit blocked and who was there'). That tells the agent exactly when to reach for this tool. It stops short of 5 because no alternative or exclusion is named — the agent is not told what to use instead when it wants current state rather than history.

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 discloses the filtering behavior and the cursor contract, but says nothing about whether reading the inbox consumes/marks messages as read, ordering, or pagination — a critical omission for an inbox-shaped tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two terse sentences with zero waste and the filter condition front-loaded. It is efficient, though the extreme brevity is part of why other dimensions are thin.

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. However, with no annotations and an undocumented `limit`, the description leaves the read-vs-consume semantics and cursor mechanics too ambiguous for an agent to invoke this confidently.

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. It partially explains `since_id` (messages strictly newer than this cursor) but leaves `limit` (default 50) completely undefined, and does not state whether `since_id` is inclusive or where the next cursor comes from.

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 identifies the resource (messages) and a filter condition (newer than `since_id`), but supplies no verb — it is unclear whether this lists, consumes, or marks messages as read. It also does nothing to distinguish it from sibling `history`, which plausibly returns messages too.

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?

'Keep the cursor between calls' is a useful operational hint about statefulness, but there is no guidance on when to use this over `history`, `room`, or `next_task`, nor any prerequisites. The one hint is procedural, not selection-oriented.

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 behavioral burden. It does disclose one useful trait, the implicit filter to items the caller sent or received, but says nothing about whether the call is a safe read, pagination behavior (limit defaults to 50), ordering, or how delivery state is represented. This is thin for an unannotated 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?

A single tight sentence with no filler, and the scoping clause is placed where it is immediately visible. It is appropriately sized, though the brevity comes at the cost of completeness rather than being purely efficient.

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, but with zero annotation coverage and zero parameter documentation the description leaves the agent guessing about read semantics, result volume, and the meaning of its two inputs. For a 2-parameter query tool this is under-specified.

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% and both parameters (limit, recipient) are undocumented. The description's 'only those you sent or received' loosely gestures at recipient scoping but does not explain what the recipient parameter accepts or how limit interacts with the result set, so it fails to compensate for the coverage gap.

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 identifies the resource ('addressed items') and a key attribute ('delivery state'), and scopes it to items the caller sent or received. However, it is a bare noun phrase with no verb, so it is unclear whether the tool lists, retrieves, or inspects jobs, and it does not distinguish itself from siblings like inbox or history that plausibly return similar data.

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 when-to-use guidance is given and no alternative is named, despite a crowded sibling set (inbox, history, next_task) that overlaps in subject matter. The parenthetical scope note hints at filtering but does not tell the agent when to choose this tool over those.

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

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

With no annotations, the description carries the full burden, and it does add real value: it discloses that the acquisition is atomic and that the task payload is untrusted input from another agent. It omits lease semantics (what happens on expiry, whether claiming blocks, what the lease bounds), which is significant for a lease-based tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences: the operation is front-loaded and the safety warning is a deliberate, earned addition. The security caveat is slightly verbose for a warning but is not 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?

An output schema exists, so return values need no explanation, and the description covers the core action plus the security posture. For a lease-based, unannotated tool it still leaves lease behavior and its relationship to claim/release/ack unexplained.

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 single parameter lease_seconds has 0% schema description coverage and is never mentioned in the description, so nothing explains its units, default behavior, or expiry consequence. The description does not compensate for the schema gap.

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: 'atomically take the oldest ready task addressed to this agent,' which is far more precise than the bare name next_task. It does not, however, differentiate itself from the sibling 'claim', which sounds like an alternative way to acquire a task.

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?

There is no statement of when to call this versus sibling tools such as claim, inbox, accept, or ack, nor any prerequisites (e.g., must the agent be registered?). The warning paragraph is about how to treat task content, not about when to select this tool.

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 behavioral burden. It does disclose a non-obvious domain trait — ownership can be inherited from a directory lease above the path — which the schema cannot express. However, it never states that this is a read-only lookup, nor what happens when no owner exists.

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 with zero waste, and the parenthetical carries real semantic weight. Phrasing it as a question rather than an imperative statement slightly reduces actionability.

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-value explanation is not needed, and the tool is structurally simple (one required string param). What remains missing is routing against the lease-management siblings and error/empty-result behavior, leaving the definition adequate but thin.

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% for the single 'path' parameter, so the description must compensate. It does add meaning by explaining that the path's owner may be resolved through an ancestor directory lease, which clarifies how the path is interpreted. It still omits path format (absolute/relative) and whether the path must already exist.

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 is phrased as a question ('Who holds this path...') rather than a verb+resource statement, but the resource (path ownership) and the retrieval intent are inferable. It distinguishes itself from siblings like claim/release by being a query, though it never explicitly says it returns the current holder.

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?

There is no guidance on when to use this versus claim, release, accept, or ack, all of which plausibly touch the same lease/path domain. The agent must infer usage entirely from the one-line question.

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 the key behavioral fact: omitting `paths` releases everything you hold, not just one lease. It also explains the consequence (blocking the other agent), which is meaningful concurrency context. It omits error behavior (releasing a lease you don't hold) and idempotency, so it is not fully transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded imperative followed by the scope rule and a short rationale; every sentence carries information. The closing warning is slightly editorial, but it justifies the guidance rather than padding it.

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 one optional parameter's default behavior is covered. What is missing for a lease-mutation tool is failure semantics (unknown/expired lease) and idempotency, leaving a small but real gap.

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% and the schema only declares `paths` as a string array or null with no meaning attached. The description compensates by explaining that the parameter acts as a filter and that its absence means 'everything you hold', which is exactly the semantic the schema lacks.

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 ('Return leases') that is unambiguously the inverse of the sibling 'claim'. It also pins down scope ('Without `paths` returns everything you hold'), so an agent knows exactly what this does. It stops short of naming a sibling alternative explicitly, so it is not 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?

Gives an explicit when-to-use ('as soon as you are done') and an anti-pattern to avoid (holding a lease 'just in case'). That is real conditional guidance. It does not, however, mention adjacent siblings such as `cancel`, `retry`, or `ack` and when to prefer them.

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 does disclose a meaningful side effect: unstarted tasks move to the next agent in the fallback chain after a short grace period, and the sender is notified. However, it omits permission requirements, what happens to in-flight tasks, reversibility, and how the handoff interacts with other tools.

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?

It is short and front-loads the trigger question, followed by consequences and the `minutes` definition. The formatting is compact and readable, though the causal description of the fallback handoff could be sharper.

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 two-parameter tool with an output schema, it covers the trigger, handoff behavior, and one parameter. It still lacks guidance on the `reason` parameter, the distinction from siblings, and operational details like grace-period duration or any required permissions.

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. It explains `minutes` as 'estimate until reset' and leaves `reason` undocumented, which is the weaker of the two parameters. The description adds real meaning for one of two params but does not fully cover the schema gap.

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 frames the tool as reporting that the agent is out of quota/rate limit, with a call-to-action 'Call THIS before you stop.' It implies the tool signals a limit condition, but it never states the action plainly (e.g., 'report that you have hit a rate limit and hand off unstarted tasks'). Compared to siblings like release/retry/cancel, the specifics of what report_limit actually does are only inferable.

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 a clear trigger ('Running out of quota/rate limit?') and urgency framing ('Call THIS before you stop'). It does not mention alternatives such as retry or release, nor when not to use it, so it falls 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses the state transition (failed states → pending queue), but says nothing about permissions, whether the original attempt is preserved or duplicated, rate limits, or side effects — significant gaps for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single tight sentence, front-loaded with the verb and target state. Nothing is wasted, though it is terse enough to leave real questions unanswered rather than being a model of completeness.

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. However, for a state-changing 3-parameter tool with 0% schema coverage, the undocumented not_before parameter and the lack of any authorization or side-effect context leave it only minimally 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 description coverage is 0% and the description never mentions message_id, recipient, or the not_before delay parameter. At 0% coverage the description should compensate, but it adds no meaning beyond the parameter names, leaving not_before (default 0) entirely unexplained.

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 gives a specific verb ('put back into the pending queue') and resource ('delivery'), and even enumerates the eligible source states (failed/needs_review/dead_letter), so the operation is unambiguous. It does not, however, differentiate itself from similar siblings like release or cancel.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the enumerated precondition states — an agent can infer it applies only to deliveries in failed/needs_review/dead_letter. There is no explicit when-not guidance or comparison against the sibling tools that also manipulate delivery state.

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 exist, so the description carries the full burden. It does disclose one meaningful non-obvious trait: passing `status` broadcasts what the caller is working on to other agents, making this not a purely passive read. It omits other behavioral facts such as whether omitting status is side-effect free, idempotency, and any concurrency/permission constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core value in a single colon-delimited clause, then the invocation timing, then the rationale for `status`. Tight overall, though the closing clause 'so the other agent does not have to guess' restates the announce behavior already implied.

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 values need no explanation, and the single optional parameter is addressed. The description covers purpose, timing, and the status side effect, leaving only minor gaps around default/empty behavior for a tool of this simplicity.

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 lone `status` parameter has no schema description, so the description must compensate. It does add meaning by explaining that `status` announces current work rather than merely recording state, but it gives no format, length, or empty-value guidance for the parameter.

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 defines the otherwise cryptic name 'room' as a state snapshot with three concrete components: who is here, what is held, what is new. That is a specific verb+resource, not a restatement of the name. It does not explicitly distinguish itself from adjacent siblings like inbox, history, or owner, which prevents 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?

'Call it when you start and after each step' gives an explicit, actionable trigger for invocation. However, it names no alternatives and gives no when-not-to-use condition (e.g., vs inbox or history), so it stops 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?

With no annotations at all, the description carries the full burden and does disclose a genuinely non-obvious behavioral trait: delivery is pull-based and replies are not immediate. That is real value beyond any structured field. It omits auth/permission expectations and whether sending can fail, 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 short units, front-loaded with the action and audience, then the crucial caveat. No filler sentences, and the warning is exactly the piece an agent most needs.

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 one-param messaging tool the async delivery caveat covers the main risk of misuse. Minor gaps remain around peer differentiation ('send') and message content expectations.

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 is one parameter, 'text', with 0% schema description coverage, so the schema contributes nothing. The description does not clarify what 'text' should contain (plain text, formatting, length, whether addressee is needed), but the parameter is nearly self-evident from its name. A baseline 3 fits a single obvious param.

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-plus-resource ('Message to the room') and names the audience ('the other agents and the human'), which is enough to distinguish it from read-side siblings like room/inbox. It does not, however, explain how it differs from the sibling 'send', which an agent may reasonably see as an overlapping write path.

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 sets an important expectation ('Not a live chat... do not expect an immediate reply'), which shapes when an agent should prefer this versus a synchronous exchange. It stops short of naming alternatives (send, inbox, room) or stating when a message is warranted at all, so usage is inferred rather than specified.

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 behavioral burden. It discloses one important trait — a chat does not start work by itself — but says nothing about delivery guarantees, whether sending is idempotent, how `dedupe_key` affects retries, error semantics, or what happens on success. For a side-effecting send tool with zero annotation coverage and no schema descriptions, this is a substantial gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The text is a single compact fragment with no filler, so there is no verbosity to trim. However, it is undersized for a five-parameter tool rather than genuinely concise, and the key behavioral nuance is tacked on after a semicolon rather than 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?

The presence of an output schema means return values need not be described, which helps slightly. But with no annotations and 0% parameter description coverage across five params, the definition leaves the agent without enough context to call `send` confidently regarding reply threading, dedupe behavior, or the chat/task choice.

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% for 5 parameters. The description loosely maps to `to` ('Addressed'), `text`, and `kind` (chat vs task), but leaves `reply_to` and `dedupe_key` completely unexplained, and never lists the valid values for `kind`. It does not compensate for the coverage gap.

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 (an addressed chat message or durable task) but never states the verb in plain terms and reads as a sentence fragment, so the agent leans on the name 'send' to infer the action. It also does not differentiate itself from the plausible sibling 'say', which likely overlaps with the chat case. The distinction that a `chat` starts no work is useful but is behavioral, not identificational.

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?

There is no explicit when-to-use guidance, no statement of prerequisites, and no routing to alternatives among the many siblings (say, ack, accept, claim). The only implicit signal is that choosing `kind` selects chat vs task behavior, which the agent must reverse-engineer. No exclusions are stated.

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