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

With no annotations, the description carries the burden of disclosing side effects. It indicates a check (likely read-only) and staleness info, but does not explicitly state that it makes no modifications or whether it requires any permissions. It is minimal but not misleading.

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

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

A single sentence with no filler. The key information (what it checks and the staleness info) is front-loaded, making it easy to parse quickly.

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

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

The description omits return value details (e.g., whether it returns a boolean, staleness threshold, or timestamps) and does not explain how it differs from sibling tools with similar names. For an agent choosing among six continuation tools, this is incomplete.

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 schema's parameter description covers the meaning and default of `stale_threshold_hours` (100% coverage). The tool description adds no extra detail about the parameter, so a baseline of 3 is appropriate.

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

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

The description states a specific verb ('check') and resource ('continuation note at handoff location'), plus a distinguishing feature ('with staleness info'). It is clear but does not differentiate from siblings like `continuation_read_with_staleness`, which likely overlaps in purpose.

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

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

No guidance is given on when to use this tool versus its many siblings (e.g., `continuation_read_with_staleness`, `continuation_check_handoff`). The description does not mention any conditions or alternatives.

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 fully carries the burden and excellently discloses destructiveness ('this is destructive and the note is the only copy') and the recommended safety practice ('READ IT FIRST'). It warns of data loss risk clearly.

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

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

The description is compact yet information-dense. The critical warning is front-loaded, and each sentence adds value without redundancy.

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 zero-parameter destructive tool, the description covers all essential aspects: purpose, safety warning, and alternatives. No output schema exists, but the tool likely returns simple confirmation, which is not critical to note.

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

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

There are zero parameters, so the baseline is 4. The description adds no parameter details because none exist; the schema is empty and coverage is 100%, so nothing is missing.

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 explicitly states 'Delete an old continuation note' with a specific verb and resource, and differentiates from siblings by noting when it's not needed. It clearly identifies the tool's function and scope.

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?

Explicitly says 'Normally you do not need this at all' and names two alternatives (continuation_write and continuation_read_and_cleanup) with their appropriate use cases, providing clear when-to-use and when-not-to-use 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?

Since annotations are absent, the description carries the full burden. It does add the key behavioral insight that absence and staleness look identical, which is crucial context. However, it does not disclose what the tool returns (e.g., list of note IDs, timestamps, or contents), error behavior on invalid project paths, or whether stale notes are included. It gives reasoning but not complete behavioral specification.

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 with no fluff. The first sentence states the core action, and the second provides the essential usage rationale. The warning is front-loaded after the action, making it easy for an agent to parse quickly. Every word 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?

Given a simple listing tool with two params and no output schema, the description adequately explains the purpose and the critical use case. It does not describe the return format or ordering, but these are likely inferable from the context (listing notes). The description is complete enough for an agent to select the tool correctly and understand the primary caveat.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema. The description adds no new parameter-level meaning beyond what the schema provides. The baseline of 3 applies as the description does not detract or add.

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 action ('List'), a specific resource ('continuation notes'), and a scope ('for one project'). It clearly distinguishes itself from the sibling tools by focusing on listing existing notes, while siblings handle writing, cleanup, or staleness-based reads. The verb+resource+scope 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?

Explicitly states when to use: 'Use it when you are not sure a note exists'. It also explains the critical distinction between absent and stale notes, and why acting on a stale one is dangerous. This gives clear conditional guidance without referencing alternatives, which is sufficient because the condition itself is the differentiator.

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 must carry behavioral weight. It states the read-and-delete actions and the deprecation status, which is central. However, it does not explain side effects of the deletion, error behavior, or why it's deprecated beyond staleness. Still, for a deprecated tool, the key disclosure (don't use it) is present.

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

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

One sentence plus a compact parenthetical. Every word earns its place: the action, the resource, the deprecation, and the alternative. Perfectly front-loaded and zero 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?

Given the tool is deprecated, the only essential context is that it should not be used and what to use instead. The description provides both. No output schema is needed because the agent is directed away; for a deprecated tool this is fully 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?

There are zero parameters, so schema coverage is trivially 100% and the description adds no parameter-specific value. Per the rubric, 0 parameters yields a baseline of 4. The description gives no extra parameter context, but none is needed.

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

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

The description clearly states the action ('Read continuation note from handoff location and delete it') with a specific resource and two operations. It also explicitly marks the tool as deprecated, which removes any ambiguity about its role. This distinguishes it from siblings like continuation_read_with_staleness.

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 instruction 'deprecated - use continuation_read_with_staleness' explicitly tells the agent when not to use this tool and names the preferred alternative. This is the strongest possible usage guidance—an explicit exclusion and a direct pointer.

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 fully owns behavioral disclosure. It warns notes are claims about code, can be out of date, and advises verification. It states 'without deleting' which implies read-only, but does not explicitly mention other side effects. It is transparent about the main caveat (staleness) which is critical.

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

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

The description is front-loaded with the action, then adds a crucial warning and a recommendation. All sentences carry weight; it is slightly verbose due to the extended caution, but that is necessary context.

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 read tool with two well-documented parameters and no output schema, the description covers purpose, usage, and a key caveat. It does not describe the output format, but that is likely self-evident from the domain. The recommendation and warning make it fairly 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 coverage is 100% for both parameters, so the description adds no additional parameter-specific meaning beyond what the schema provides. Baseline of 3 is appropriate.

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

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

States a specific verb and resource: 'Read one continuation note without deleting it.' This clearly distinguishes it from the sibling continuation_read_and_cleanup, which would delete. No ambiguity.

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?

Explicitly directs users to prefer continuation_read_with_staleness for staleness information, and gives a strong condition ('CHECK ITS DATE AGAINST THE ACTUAL REPO') for when this tool is appropriate. This is excellent guidance for tool selection.

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 provided, the description carries the burden of behavioral disclosure. It usefully states that the tool does not delete until a new note is written, which signals a non-destructive operation. However, it does not explain whether reading updates staleness state, what side effects may occur, or what 'new note written' actually triggers.

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

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

The description is a single sentence with the key behavioral distinction front-loaded in a parenthetical. It contains no filler, redundant phrasing, or unnecessary detail.

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

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

For a low-complexity tool with one optional parameter, the description is mostly adequate. However, there is no output schema and no explanation of what 'staleness detection' returns, and the description does not explicitly disambiguate among the many similar continuation sibling tools.

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

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

The input schema has 100% coverage for the only parameter, stale_threshold_hours, including a default and description. The tool description adds no extra meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description clearly names the verb 'Read' and the resource 'continuation note,' and the parenthetical 'does not delete until new note written' distinguishes it from cleanup-oriented siblings. However, 'staleness detection' is left vague, so it does not fully explain what the tool actually does beyond the name.

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 a non-destructive read use case, especially in contrast to a tool like continuation_read_and_cleanup, but it never explicitly states when to use this tool versus its siblings. There is no direct guidance on which alternative to choose for deletion or cleanup scenarios.

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 provided, the description carries the full behavioral disclosure burden. It does disclose a key failure mode (silent failure when project_path is missing) and advises content priorities (unfinished work and hard-won lessons). However, it does not mention whether the operation overwrites or appends, any side effects, or what the tool returns on success or failure. This is adequate but has notable 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?

The description is relatively compact and front-loaded with the core purpose. Sentences are purposeful, though the phrasing 'Write it BEFORE context runs out, not when you notice it is running out' is slightly redundant. Overall it avoids verbosity and delivers value in a few lines.

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

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

Given the tool has 11 parameters and no annotations or output schema, the description gives essential context: what to write, when to write, and a key pitfall. It does not explain the relationship between parameters or expected return behavior, but for a write operation the description is reasonably sufficient. It could be more complete about the write behavior and any preconditions, so a 3 is appropriate.

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 schema has 100% description coverage for all parameters, so the baseline is 3. The description adds emphasis on project_path being required and gives content-quality guidance, but does not provide additional semantics for the other parameters. It adds marginal value over 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 starts with 'Write the handoff note for the NEXT session' which is a specific action on a specific resource, clearly distinct from the sibling read/cleanup/check/list tools. It also states the project context and the intent to persist state, making it unambiguous what the tool does.

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 provides explicit timing guidance ('Write it BEFORE context runs out, not when you notice it is running out') and stresses the criticality of project_path. It implies when to use (when writing a handoff) but does not explicitly contrast with the sibling tools, so it lacks an explicit 'when not to use' or named alternatives.

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