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 usefully discloses the state machine (pending/approved/denied/expired) and the gating semantics of 'approved', but says nothing about whether this is a safe read, expiry timing, or whether polling is expected. Partial but meaningful coverage.

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, tightly worded sentence with the core action front-loaded and the decisive status semantics at the end. 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?

An output schema exists so return values need not be explained, and the description already previews the status set. For a one-parameter read tool this is nearly sufficient; only the approval_id's provenance 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?

Schema description coverage is 0% and the single required parameter 'approval_id' is undocumented in both schema and description. The description adds no meaning about the id's origin or format, so the coverage gap is not compensated.

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 ('Check an approval's status') and enumerates the four possible outcomes. This clearly separates it from sibling writers like dhp_request_approval, dhp_approve and dhp_deny without needing the schema.

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

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

The clause 'Only approved means the action may run' gives important post-check decision guidance, but the description never states when to poll this vs. an alternative like dhp_status, nor any precondition (e.g. that an approval_id must first come from dhp_request_approval). Usage is implied 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?

With no annotations, the description carries full behavioral burden. It implies a state mutation but says nothing about who is authorized, whether approval is idempotent, what happens to the request afterward, or what error occurs if approval_id is not pending. The '(human / policy engine)' parenthetical hints at actor identity but is too terse to be actionable.

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 target, with zero padding. The trailing parenthetical is slightly cryptic and could be dropped or clarified.

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 this is a mutation tool with no annotations and no guidance on permissions, preconditions, or downstream effects. For a state-changing approval action, the description is too 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 description coverage is 0%, so the description must compensate, and it does not explain approval_id format, provenance, or how to obtain one (likely from dhp_request_approval or dhp_approval_status). The parameter is largely self-evident from its name, which keeps this at a minimal 3.

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 (Approve) and resource (a pending approval request), which distinguishes it from dhp_deny and dhp_request_approval by implication. However it never explicitly names those siblings, so an agent must infer the boundary from the sibling list alone.

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 statement, no precondition that the approval must currently be pending, and no pointer to alternatives such as dhp_deny for rejection or dhp_approval_status for checking state. Usage is only implied by the word 'pending'.

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 does not disclose what checkpointing actually does (persist? overwrite previous state? idempotent?), whether it has side effects, or any auth/rate constraints — critical gaps for a state-writing tool with zero annotation coverage.

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, front-loaded sentences with no filler or redundancy. It is efficiently structured, though its extreme brevity borders on under-specification rather than being a model of 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?

While an output schema exists (so return format need not be explained), the description is inadequate for a tool with three required parameters at 0% schema coverage, an opaque nested state object, and no annotations. An agent lacks enough context 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 0% for three required parameters, and the description adds no clarification. The nested, open-ended "state" object (additionalProperties: true) is especially opaque — nothing explains what should go in it, only weakly implied by "worker progress".

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?

"Checkpoint worker progress" gives a specific verb (checkpoint) and resource (worker progress), so the intent of persisting a worker's state is inferable. However, it offers no differentiation from close siblings like dhp_heartbeat, dhp_complete, or dhp_last_checkpoint, leaving the agent to guess how this differs from merely signaling liveness or completion.

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 per chunk of work" provides a cadence/frequency hint that implies when to invoke it. Beyond that there is no explicit when-not guidance, no mention of alternatives (heartbeat vs checkpoint vs complete), and no prerequisites, so usage is only implied.

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 that claiming yields a lease (exclusive ownership) and the last checkpointed state, but says nothing about contention when a handoff is already claimed, lease expiry, or required permissions.

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 zero filler; the action is front-loaded and the return value follows immediately. Nothing could be trimmed without losing content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the description is not obligated to detail return values (though it does, usefully). Against that, there are no annotations, no parameter documentation, and no failure or contention semantics for what is clearly a mutating lease-acquisition call.

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 both handoff_id and worker_id are undocumented in the schema, and the description does not compensate by explaining their formats, relationships, or constraints. The agent gets no help beyond the parameter names themselves.

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 (claim) and resource (handoff) plus the actor (worker), which is enough to distinguish it from dhp_dispatch or dhp_recover in intent. It stops short of explicitly contrasting itself with those siblings, so it is clear but not fully differentiated.

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 claim versus dispatching, recovering, or checking status. The only implied guidance is that a claim precedes work, which the agent must infer from the sibling names and the resume-point mention.

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 full behavioral burden. 'Complete the handoff' implies a terminal state transition, but the description never says whether it requires a claimed handoff, whether it is idempotent/reversible, or what happens on a non-validated result beyond the passing mention of 'schema-validated'.

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

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

A single front-loaded sentence with no filler. It is efficiently sized, though the brevity reflects under-specification rather than economy.

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, but for a mutation-style handoff-completion tool with zero annotations, three undocumented required parameters, and a nested result object, the description is far too thin 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?

Schema description coverage is 0% across three required parameters (handoff_id, worker_id, result), including a nested free-form result object. The description adds no format, identity, or format-of-result guidance, 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 names a specific verb and resource ('Complete the handoff'), making the basic purpose legible. However, it does nothing to differentiate this from completion-adjacent siblings such as dhp_effect_done or dhp_claim, so an agent cannot route confidently without opening schemas.

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

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

There is no indication of when to call this versus alternatives like dhp_effect_done, dhp_checkpoint, or dhp_recover, nor any stated prerequisites such as first claiming a handoff. Usage is left entirely to inference.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not say whether a denial is final or reversible, who is permitted to deny (the parenthetical "human / policy engine" hints at the actor but is ambiguous), whether the requester is notified, or what happens if the request is no longer pending. For a state-changing operation with zero annotation coverage this is a real 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?

Twelve words, one sentence, action front-loaded — nothing redundant. The parenthetical "(human / policy engine)" is too cryptic to immediately earn its place, which keeps this below a 5.

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 that is the only need covered. For a mutation tool with no annotations and an undocumented required identifier, the description should say something about authorization, the finality of the denial, and error conditions such as an already-decided request.

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%: approval_id has no description in the schema and the tool description never mentions it, its format, or where to obtain it (e.g., from dhp_request_approval or dhp_approval_status). The single required parameter is effectively undocumented everywhere.

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 (Deny) and resource (pending approval request), which is far more informative than a bare name. It does not, however, distinguish itself from the obvious siblings dhp_approve, dhp_request_approval, or dhp_approval_status, so the agent gets the what but not the contrast.

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?

"Pending" is an implicit precondition — the agent can infer this tool applies only to requests still awaiting decision. Beyond that there is no when-to-use guidance, no when-not-to-use case, and no mention of dhp_approve as the alternative action. Usage is implied 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?

With no annotations, the description carries the full behavioral burden. It does disclose two meaningful traits beyond the schema: the return of a handoff_id and the durability guarantee that work survives worker death. However, it omits idempotency, retry semantics, auth/permission needs, and error behavior, so substantial gaps remain.

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

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

Three short, front-loaded sentences with zero filler, leading with the action and immediately stating the return value and durability guarantee. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be re-explained beyond the handoff_id callout. But for a three-parameter dispatch tool with no annotations and no schema descriptions, the definition should say more about acceptable task_kind values, payload expectations, and failure behavior; as written it 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% across three required parameters (task_kind, inputs, output_schema), all nested or free-form. The description provides no meaning for any of them — not the valid values of task_kind, the shape of inputs, or the purpose of output_schema — 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?

States a specific verb ('dispatch') and resource ('durable work'), which is clearly distinct from siblings like dhp_claim, dhp_checkpoint, dhp_complete, and dhp_recover. It does not, however, explicitly contrast itself with those siblings in the durable-work lifecycle, leaving the agent to infer where dispatch sits.

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 prerequisites, and no mention of alternative tools such as dhp_claim or dhp_recover. The durable-work framing only implies usage; nothing tells the agent under what circumstances to dispatch versus claim or recover.

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

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

With no annotations, the description carries the burden and does disclose the null-vs-recorded-result semantics and the intended idempotency-check role. It says nothing about permission requirements, whether the check mutates state, or any rate/locking behavior in a concurrent recovery workflow, leaving meaningful gaps.

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

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

Three short sentences, purpose first, return behavior second, usage condition last. No filler and nothing repetitive.

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 output schema covers the returned value so the description need not expand on return format, and it sensibly notes the null case. However, with no annotations and zero parameter documentation, the definition leaves the agent without enough to invoke it confidently on unfamiliar identifiers.

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 neither parameter is described in the schema, yet the description never mentions handoff_id or step_id. It conveys only that the check is scoped to a step, so the two required identifiers remain semantically 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?

States a specific verb and resource: checks whether a side effect already happened, and contrasts implicitly with the recording side of the pattern (dhp_record_effect). An agent can tell it is an idempotency lookup rather than a mutation, though no sibling is named explicitly.

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

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

Gives a concrete trigger condition: 'Call before re-executing a side effect after recovery.' That is actionable context with a clear lifecycle placement, but it does not state when not to use it or name a specific alternative tool such as dhp_record_effect.

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 of behavioral disclosure. It implies a read-only probe but never states that it is non-destructive, requires no auth, or has side effects, and it says nothing about cost or rate limits.

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?

Extremely short and front-loaded: the resource and returned fields appear immediately. It is a sentence fragment rather than a sentence, but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is trivially simple (no params) and has an output schema, so return values need not be explained. Naming 'uptime' and 'store stats' covers the essentials, but with no annotations the description could still say more about when this differs from dhp_status.

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

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

The tool takes zero parameters, so there is nothing to document and the baseline is 4. The description introduces no parameter-related confusion.

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 resource (server) and scope (health) and enumerates what it returns: uptime and store stats. An agent can tell it is a health read, but there is no differentiation from siblings like dhp_status or dhp_heartbeat, which may overlap.

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 when-to-use guidance, no mention of prerequisites, and no reference to which sibling (e.g. dhp_status, dhp_heartbeat) to prefer for related monitoring needs.

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

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

With no annotations, the description carries the burden and does disclose the key behavioral consequence: liveness is inferred and a silent worker is treated as dead. It omits whether the call needs to be from the same process/session holding handoff_id, and whether missed heartbeats trigger recovery.

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 front-loaded sentences, 'Heartbeat: prove the worker is alive' then the operational consequence. Slightly terse for a protocol call, but no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need not be explained, and the liveness semantics are covered. However, required params at 0% coverage and no cadence/auth guidance leave meaningful gaps for a lifecycle-critical call.

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 neither parameter is described in the schema or the description. The description never explains what handoff_id vs worker_id identify or which one scopes the liveness claim, leaving two required params undocumented.

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-effect ('prove the worker is alive') tied to the named resource dhp_heartbeat in a worker/handoff protocol. It is distinguishable from siblings like dhp_status or dhp_health, though it does not name them explicitly.

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

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

Says 'Call frequently' and gives the consequence of not calling (silent worker assumed dead), which implies the when. But it does not specify an interval, threshold, or relationship to other lifecycle calls like dhp_claim/dhp_complete.

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 one useful edge case (returns null when no checkpoint exists), but says nothing about read-only safety, whether it requires an active handoff_id, error behavior, or any access conditions.

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 with no filler, and the key return behavior is front-loaded. It is appropriately sized for a simple getter, though it is arguably too terse to be informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-shape explanation is not required, and the null fallback is covered. Still missing are any parameter meaning and usage context, which for a one-parameter lookup tool leaves a noticeable 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 description never mentions the single required parameter handoff_id. With one undocumented parameter, the description does nothing to explain what identifier the tool expects.

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 fragment 'Last checkpointed state' names the resource being retrieved, and 'or null if none yet' clarifies the return semantics, so the agent can tell it apart from the write-side dhp_checkpoint. However, it is a noun phrase with no verb and gives no hint of the read/fetch nature beyond implication, leaving some inference to the agent.

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 call this versus related siblings such as dhp_status, dhp_recover, or dhp_checkpoint. The agent must guess the workflow context in which the 'last checkpoint' is relevant.

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

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

With no annotations, the description carries the full burden. It does disclose genuinely useful system behavior — repeated digests trigger livelock detection and the handoff gets orphaned as stalled — but is silent on required permissions, idempotency, and what a call returns or changes.

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

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

Two tight sentences with no wasted words, and the core definition of the digest is front-loaded. It stays information-dense without padding.

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. The description covers the digest concept and the supervisor's reaction, but for a 3-required-param reporting tool with zero annotation coverage it omits the meaning of the handoff/worker identifiers and the intended call frequency.

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

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

Schema coverage is 0%, so the description must compensate for all three parameters. It explains only `digest` (hash of tool name + args); `handoff_id` and `worker_id` are left entirely undocumented in both schema and description, leaving two of three required inputs undefined.

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 clear verb+resource ("Report an activity digest") and helpfully defines the digest as a hash of tool name + args. It does not, however, distinguish itself from near-neighbours like dhp_heartbeat or dhp_checkpoint, which an agent could easily confuse with this liveness-reporting role.

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 via the consequence ("supervisor orphans the handoff as stalled if the digest repeats"), which tells the agent why reporting matters but not explicitly when to call this versus dhp_heartbeat or dhp_checkpoint. No call cadence or precondition is stated, so the agent must infer the moment to use it.

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 yet discloses genuinely useful behavior: the currency is USD and over-spend causes the supervisor to fail the handoff closed. It still omits whether calls accumulate, whether an over-budget call errors immediately, idempotency, and any permission requirements.

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

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

Two short sentences, front-loaded with the action and followed by the consequence. No filler, though the breach sentence could be slightly tighter in phrasing.

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, for a 3-required-param mutation tool with zero annotations and 0% schema coverage, the description should say more about accumulation semantics and failure behavior when the budget is breached.

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 and largely does not. It clarifies only that the amount is USD; handoff_id and worker_id are left to the parameter names alone, with no scope or format detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: records spend in USD against a handoff's budget. It is clearly distinguishable from siblings like dhp_note_activity or dhp_record_effect by the budget-spend scope, though it never names or contrasts those siblings explicitly.

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

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

The description implies you call this when spend is incurred, but gives no when/when-not guidance, no prerequisites, and no routing against the many sibling note/record tools. The budget-breach sentence motivates the call but is a consequence, not usage 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 and does disclose the key trait: first-write-wins idempotency and the meaning of the recorded=true/false return. It omits auth/permission needs and where the effect is stored, so it is strong but not exhaustive.

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

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

Two short sentences, front-loaded with the purpose and immediately followed by the idempotency constraint and return contract. 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?

The output schema exists, so return-value explanation is not required, yet the description does correctly summarize the recorded flag. However, with 0% schema coverage and a nested 'result' object, the meaning of three of four inputs is left 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 coverage is 0% with four required parameters, so the description must compensate for all of them. It only explains step_id; handoff_id, worker_id, and the free-form 'result' object are left entirely undocumented.

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 ('Record a side effect by step_id') and its idempotent semantics, which separates it from siblings like dhp_effect_done. It does not explicitly name the sibling it must be distinguished from, so it stops short of a 5.

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

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

The parenthetical 'do NOT re-fire the effect' gives a clear when-not rule and the semantics imply this is the checkpoint-recording step, but no alternative tool (e.g. dhp_effect_done) or prerequisite conditions are named. Usage is implied rather than spelled out.

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

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

With no annotations, the description carries the full burden. It usefully discloses the precondition (orphaned handoff from a dead worker) and the return payload (lease plus last checkpointed state). It does not state the mutation side effects (lease re-assignment, state changes to the handoff record) or authorization requirements.

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

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

Two tight sentences: purpose and precondition front-loaded, return value second. Every clause 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?

An output schema exists, so return values need not be explained (though the description mentions them anyway). Given no annotations and zero parameter coverage, the definition still leaves out mutation semantics and sibling routing, which matter for a lease-mutating recovery operation.

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

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

Schema description coverage is 0% for both handoff_id and worker_id, so the description must compensate. It never mentions either parameter, leaving the agent to infer their meaning from names alone. Two undocumented required params at zero coverage is a real 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 ('Recover an orphaned handoff') with the triggering condition ('worker died'). It does not name or distinguish itself from the closely-related sibling dhp_claim, which is likely the alternative for non-orphaned handoffs.

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 parenthetical '(worker died)' implies the usage condition, so the agent can infer when to reach for this tool. However, it never explicitly contrasts with dhp_claim or dhp_status, nor states any exclusion or prerequisite, leaving the choice between siblings to inference.

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

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

With no annotations, the description carries the full burden and does well: it declares fail-closed semantics, states a return value (approval_id), and imposes a gating rule that prevents premature execution. It omits failure modes, error shapes, and any permission prerequisites, keeping it from a 5.

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

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

Two tight sentences, front-loaded with the trigger and the safety-critical gating constraint. Every clause earns its place; nothing is padding.

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 output schema exists, so return values need not be explained, and the workflow gate is covered. However, with zero annotation coverage and 0% parameter documentation for a call that gates destructive/financial operations, the definition leaves an agent without enough context on inputs or failure 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% and the description says nothing about handoff_id, worker_id, action_class, or the free-form nested details object. With four required but undocumented parameters, the description does not compensate for the schema gap at all.

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 ('Request approval for a destructive/financial action'), which separates it from decision siblings like dhp_approve/dhp_deny. It does not explicitly compare itself to those siblings, so it stops short of a 5.

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

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

Gives a clear trigger condition (destructive or financial actions) and a mandatory follow-up gate ('must NOT run until dhp_await_approval reports approved'). It does not name exclusions or clarify the relationship to dhp_approval_status/dhp_approve, so it is clear but not fully routing-grade.

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 present, the description carries the full burden and does so well: 'fail-closed' declares behavior on a missing grant, and 'Every check is audited' discloses a side effect the agent would otherwise not know about. It leaves open whether failure manifests as an error or a false result, and says nothing about permissions needed to call it.

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 dense sentence front-loads the core semantics (fail-closed capability check) and then adds the usage constraint and audit note. No sentence is filler and nothing important is buried.

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 safety-critical semantics of a guard check. The main remaining gap is the meaning/format of handoff_id and worker_id, plus an explicit statement of the failure surface, which for a fail-closed gate would be useful.

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% with four required parameters, so the description must compensate. It explicitly ties 'domain' and 'resource' to the contract grant, but handoff_id and worker_id are never explained, leaving half the required inputs to be inferred from their names alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: verify that the handoff's contract grants (domain, resource). It is clearly a pre-flight authorization guard, which is distinguishable in spirit from mutation siblings like dhp_claim or dhp_record_effect, though it never names or contrasts those siblings directly.

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 strong ordering rule – call this before touching network, filesystem, or external services – which tells the agent exactly when the check belongs in a workflow. It does not name alternatives or state when this check is unnecessary (i.e., purely local, read-only work), 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?

No annotations are supplied, so the description carries the full burden. It implicitly discloses the read-only nature by describing a pure status read and lists the fields returned, which is useful. However it says nothing about what happens with an unknown or expired handoff_id, whether results are cached, or any permissions required for a completed handoff's result.

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, front-loading the resource and then the returned facets. It is a noun fragment rather than a clause, which slightly weakens the lead, but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so enumerating state/checkpoints/owner/result in the description is partly redundant. With no annotations and an undocumented parameter, the definition leaves the agent to infer error behavior and handoff_id provenance; for a simple one-param read tool this is adequate but not fully rounded out.

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% with one required parameter, and the description never mentions handoff_id — no format (UUID? opaque token?), no source (returned by dhp_dispatch or dhp_claim), no existence requirement. The parameter name is self-explanatory, which is the only thing keeping this above a 1, but the description adds nothing.

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?

It names a specific resource (a handoff) and the read operation (fetching status), and enumerates the facets returned: state, checkpoints, owner, result. That distinguishes it from dhp_last_checkpoint (checkpoint-only) and dhp_health (system-level), though it never names a sibling explicitly. The fragmentary phrasing 'Status of a handoff' lacks a verb but is 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?

There is no when-to-use guidance, no condition selecting this over dhp_last_checkpoint, dhp_health, or dhp_approval_status, and no stated prerequisites (e.g. the handoff must exist). Usage is only implied by the tool name and the returned-fields list.

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