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

With no annotations, the description bears full behavioral burden. It usefully discloses that cancellation stops further recovery attempts, but omits whether cancellation is reversible, what task state results, whether it applies to running vs interrupted tasks, and what permissions or error conditions apply.

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. Every phrase contributes either the core action or a behavioral consequence.

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 mutation tool with no annotations, no output schema, and 0% parameter documentation, the description is too thin. It should clarify the resulting task state, reversibility, and the role of the reason parameter to be complete enough for reliable invocation.

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

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

Schema description coverage is 0%, and the description says nothing about either parameter. It does not explain the required taskId or clarify the optional reason parameter, including whether the reason is recorded or affects behavior.

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 ('Cancel a task') and adds a distinguishing behavioral detail ('stop any further recovery attempts'), which separates it from siblings like mark_completed and report_interruption. However, it does not explicitly name or contrast those siblings.

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

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

The description gives no indication of when to prefer cancel_task over mark_completed, report_interruption, or other lifecycle siblings, nor does it state prerequisites or exclusions. Usage is only implied by the verb 'Cancel'.

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 usefully discloses the returned content, including recovery attempts and recent events, and the includeEvents parameter implies an event log. However, it never states that the call is read-only with no side effects, nor anything about cost, pagination, or 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?

A single front-loaded sentence with a colon-delimited field list; zero filler and every phrase conveys information. Ideal density for a simple retrieval tool.

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 no output schema, the description's enumeration of returned fields is valuable, and no annotations mean behavior must be inferred from 'Get'. But the required taskId and the includeEvents toggle are left unexplained, so an agent cannot fully understand the call contract from the text alone.

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

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

Schema coverage is 50%: includeEvents has a description and a default, but taskId is undocumented in both schema and description. The description mentions neither parameter, so it adds no meaning over the structured fields and fails to compensate for the undocumented required taskId.

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

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

States a specific verb ('Get') and resource ('task status'), then enumerates the fields returned (state, progress, checkpoint, recovery attempts, recent events). This clearly distinguishes it from the sibling tools, which are all mutation/reporting operations (register_task, report_progress, save_checkpoint, etc.), though it never names them.

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 only implied: the agent can infer this is the read-only status lookup among write-oriented siblings, but the description never says when to call it, whether polling is expected, or what alternatives exist. Minimum viable guidance, no 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. It discloses a useful behavioral rule (completion requires evidence, never inferred from exit codes) but says nothing about irreversibility, resulting task state, permissions, or whether the task can be reopened.

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, both front-loaded with the action and the constraint; nothing is wasted or 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?

A two-parameter mutation tool with no output schema is adequately covered: the agent knows what it needs and the key gating rule. Missing only the post-completion effects (state transition, reversibility).

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

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

Schema coverage is 50%: the 'verification' parameter is documented in the schema, while 'taskId' is undocumented anywhere. The description reinforces that verification is mandatory but adds no format or identifier guidance beyond the schema.

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

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

The description names a specific verb and resource ('mark a task completed') and adds a precondition that no other sibling performs. It is not confused with report_progress or cancel_task, though it never names 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?

'After verifying the final state' states the trigger condition, and 'completion is never inferred from process exit' rules out a tempting wrong usage. It still lacks explicit routing against alternatives such as cancel_task when work is abandoned rather than finished.

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 registration enrolls the task in watchdog monitoring and recovery, but omits key traits: whether registering an existing taskId fails or overwrites, idempotency, and whether registration implies any process ownership. These gaps matter for a stateful registration call.

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 sentences, zero padding, with the action and its monitoring purpose front-loaded before the call-site guidance. Nothing is restated redundantly.

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 an 8-parameter, no-annotation, no-output-schema registration tool, the description covers purpose and trigger but leaves out duplicate-registration behavior and what a caller gets back (task id, status, error). Adequate but with clear gaps.

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

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

Schema description coverage is 100% and all eight parameters carry inline descriptions, so the schema already does the work. The description adds no additional meaning about required fields, defaults, or how sessionId/processPid affect recovery behavior, so the baseline of 3 applies.

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

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

The description names a specific verb ('Register') and resource ('a coding-agent task') and adds the purpose ('for monitoring and automatic recovery'), which clearly separates it from siblings like report_progress or save_checkpoint. It stops short of explicitly naming an alternative tool, but the intent 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?

It states the trigger ('The agent (or its launcher) calls this when starting a task') and the rationale (so the watchdog can resume it after interruptions), which is a clear use context. It does not cover when-not-to-use, re-registration semantics, or whether a launcher should call it instead of the agent.

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 a watchdog verifies the report and schedules recovery, but it omits key mutation behavior such as idempotency, permissions, task status changes, and what the caller should expect after submission.

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 one behavioral detail. There is no filler or repetition.

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

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

For a reporting/mutation tool with no annotations and no output schema, the description is too thin. It does not explain what 'verifies and schedules recovery' means operationally, whether the task is retried or cancelled, or what response the caller receives.

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 moderate at 67%: error and exitCode are documented in the schema, while taskId is self-explanatory. The description loosely maps to the 'error' parameter but adds no meaning beyond the schema and says nothing about exitCode or taskId usage.

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 ('Report') and resource ('error or interruption for a task'), making the tool's core purpose clear. It does not explicitly distinguish itself from siblings such as report_progress, cancel_task, or mark_completed.

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 purpose: report when a task has an error or interruption. However, the description gives no explicit when-to-use/when-not guidance, no prerequisites, and does not name alternatives such as report_progress or cancel_task.

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 the important non-obvious behavior that the call resets a stale-task watchdog. It says nothing about how often to call, whether progress overwrites or appends, or what happens if the task is already completed or cancelled.

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 compact clauses with the heartbeat semantics front-loaded right after the purpose. No filler; the parenthetical is slightly awkward but 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?

For a simple two-param tool with no output schema, purpose plus heartbeat semantics is the essential core. Missing cadence guidance and the undocumented taskId leave real gaps for what is meant to be a periodic keepalive 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 only 50%: progress is documented in the schema while taskId is undocumented in both places, and the description adds no meaning for either parameter. With a coverage gap, the description should compensate and 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?

States a specific verb and resource (report task progress) and adds the key framing that it acts as a heartbeat. It is not explicitly contrasted with siblings like save_checkpoint or get_task_status, but the purpose is unambiguous on its own.

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 watchdog sentence implies when to call (periodically, to avoid being marked stale), but there is no explicit when-not, no suggested cadence, and no routing away from save_checkpoint or report_interruption, which an agent could easily confuse with 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?

No annotations, so the description carries the burden. It does disclose a real behavioral trait — the checkpoint survives a restart and is meant for a fresh session — which is genuinely useful context. It omits whether saves overwrite a prior checkpoint, whether 'verified' gates anything, and what the call returns, which are material for a persistence 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?

Three short sentences, each earning its place: the purpose first, then content requirements, then a single prohibition. Nothing redundant.

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 4-parameter write with no output schema, the description covers intent, content shape, and a key content exclusion, which is enough to call it correctly. The missing piece is how checkpoints relate to existing ones and to the progress-reporting siblings.

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 75%, so the schema already documents summary, details, and verified. The description adds the useful negative constraint ('do not paste raw last output') and enumerates the content expected inside details, but says nothing about taskId or the semantics of the verified flag beyond what the schema states.

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

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

States a specific verb and resource (persist verified progress) plus the reason it exists: letting a new session continue after a restart. It does not explicitly distinguish itself from the sibling report_progress, which is the nearest confusable tool, 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 purpose sentence implies the trigger (end of a work segment, before a restart) but never states when to use this versus report_progress or report_interruption. The remaining sentences are content guidance ('include concrete details', 'do not paste raw last output') rather than usage routing.

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