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

With annotations providing only broad flags, the description adds meaningful behavioral detail: it records state in a bounded session and recommends rather than executes actions. This clarifies side effects and scope without contradicting the annotations.

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

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

A single, tightly worded sentence front-loads the core verb and object, then packs in two meaningful behavioral outcomes. There is no filler or 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 tool with seven optional but fully documented parameters and no output schema, the description conveys the essential flow: analyze, record, and recommend. It stops short of describing the exact shape of the recommendation output, but it is sufficiently complete for an agent to understand the tool's role.

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 the input schema already documents each parameter, so the tool description does not need to repeat parameter details. The description adds no parameter-specific meaning beyond the schema, so the 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 names a specific verb ('Analyze') and resource ('an error or failed operation'), and adds two concrete outcomes: recording in bounded session state and recommending safe next actions. It is clear about what the tool does, though it does not explicitly differentiate it from sibling tools like retry or fix_me.

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

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

The phrase 'Analyze an error or failed operation' implies the intended trigger, and 'recommend safe next actions' positions it as an advisory step before acting. However, it gives no explicit guidance on when not to use it or how it compares to sibling 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?

Annotations already tell the agent the operation is not read-only, not idempotent, and not destructive. The description adds valuable behavioral context beyond those annotations by explicitly stating that no commands are executed, meaning the tool only produces guidance/planning content. This helps the agent set expectations about side effects.

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

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

The description is a single, front-loaded sentence with no filler. It states the action, the inputs, the output, and a key behavioral constraint ('without executing commands') in under 15 words. Every phrase 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 the 8-parameter schema with full coverage, annotations, and no output schema, the description provides enough context: it defines the output as a concise recovery plan and clarifies the non-execution behavior. It does not detail the plan's format or how to handle partially supplied inputs, but the required task parameter and well-described optional parameters make the tool usable.

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%, so all eight parameters already have descriptions. The tool description adds conceptual meaning by mapping the plan components to diagnosis, focus, stimulation, and retry guidance, but it does not explain how specific parameters map to those components. Baseline 3 is appropriate because the schema carries the parameter-documentation burden.

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

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

The description uses a specific verb ('Combine') and resource ('diagnosis, focus, stimulation, and retry guidance into a concise recovery plan'), so an agent knows what the tool produces. It also distinguishes itself from the sibling tools diagnose, focus, stimulate, and retry by framing those as components rather than the tool's own action. The phrase 'without executing commands' further differentiates it from the more action-oriented 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 clearly conveys that this tool is for synthesizing a recovery plan rather than executing recovery actions, which gives the agent a clear decision context. It does not explicitly enumerate exclusions or say 'use X when...', but naming the component tools implies when this orchestrator is appropriate.

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

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

Annotations provide no positive behavioral hints (all false), so the description itself must convey behavior. It does state the transformation and output nature, but it does not disclose aspects like whether actions are executed, how sessions affect behavior, or any side effects. This is adequate but not richly transparent.

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

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

A single, front-loaded sentence with no wasted words. It efficiently conveys the core purpose and expected output 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?

With no output schema, the description does indicate the return shape ('sequence of concrete, verifiable next actions'), which helps. However, it lacks guidance on how the tool relates to the provided sessionId/context and does not address when it should be preferred over sibling tools, leaving some practical 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%, so the input schema fully documents all four parameters. The description adds no parameter-specific meaning beyond the schema, hitting the baseline expected when the schema carries the load.

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 ('reduce') and resource ('a complicated task') and states the output: 'a short, prioritized sequence of concrete, verifiable next actions.' This clearly communicates the tool's purpose, though it does not explicitly contrast it with siblings like diagnose or retry.

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 the tool should be used when a task is complicated and needs to be broken into manageable next actions. However, it gives no explicit when-to-use vs. alternative guidance and does not mention any exclusions or sibling tools.

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

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

Annotations only say the tool is not read-only, not idempotent, and not destructive. The description adds a real behavioral trait beyond those annotations: retries must be bounded, and unchanged or exhausted retry loops are blocked. This gives the agent useful expectations about side effects and constraints, with no contradiction against the annotations.

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

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

Two sentences with no filler: the first states the core action and required components, the second states the key constraint. It is front-loaded and every phrase earns its place. The description is appropriately sized for what it conveys.

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 schema covers all parameters well and the description gives the core retry constraint, so the tool is basically usable. However, the title mentions 'Plan or record' while the description only explains recording, and there is no output schema or description of what happens when a retry is blocked or succeeds. The exact meaning of 'bounded' and the return behavior remain 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 100%, and each parameter already has a meaningful description, so the baseline is 3. The description only echoes 'change and result' which maps to proposedChange/result, and it does not add operational detail about sessionId, previousFailure, or notes. It does not need to compensate for missing schema docs.

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 action and resource: 'Record a bounded retry with its specific change and result.' It also adds the distinguishing guardrail—'Blocks unchanged or exhausted retry loops'—which separates it from sibling tools like diagnose or fix_me. The title's 'Plan or record' is somewhat broader, but the description still gives a clear, non-tautological 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?

The description implies this is for retrying an operation after a change and warns against unchanged or exhausted retry loops, so there is some embedded when-not guidance. However, it never explicitly states the triggering conditions for using this tool over a sibling, nor does it name alternatives. The usage context remains mostly inferred rather than directly 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds useful output composition details (failures, attempts, facts, successes, unresolved issues) but does not disclose additional behavioral traits such as staleness, scoping caveats, or return formatting.

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 front-loaded sentence states the action, the resource, and the scope with no wasted words. It is appropriately sized for the tool's simplicity.

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

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

For a read-only, side-effect-free retrieval tool with fully documented parameters, the description gives an agent enough to call it and understand the returned content. It could briefly mention when to use it relative to siblings, but the essential invocation context is present.

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

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

The input schema fully documents limit and sessionId with defaults, bounds, and descriptions, so schema coverage is 100%. The description adds no parameter-specific meaning or usage examples, keeping this at the baseline.

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

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

The description uses a specific verb ('Retrieve') and clearly identifies the resource: a compact session summary containing failures, attempts, facts, successes, and unresolved issues. It is unambiguous about what the tool does, though it does not explicitly contrast with sibling tools like diagnose or focus.

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

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

There is no guidance on when to use reuptake versus its siblings such as diagnose, focus, or fix_me. The intended use case is only implied by the title and description, not explicitly stated as a condition or recommendation.

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

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

The description is transparent about the primary behavior: it returns a nudge rather than performing the task, and it specifies the nudge's 'concise, structured' form and themes. With no output schema and annotations that provide no positive safety signal, this is meaningful disclosure, though side effects and session-state behavior are not addressed.

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 that front-loads the action ('Return'), the deliverable ('recovery nudge'), and the key content directives. Every phrase earns its place, with no filler or duplicated schema information.

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

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

The definition is adequate for a simple text-generation tool with fully documented parameters and a clear title. However, it lacks explicit sibling differentiation, usage timing, and an output-format preview, so an agent choosing among the six siblings gets only partial context.

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%, with clear descriptions for task, context, and sessionId, so the baseline of 3 applies. The description's mention of reassessment and changed approaches hints at how context might be used but adds no concrete parameter-level meaning 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 deliverable—a 'concise, structured recovery nudge'—and defines its content emphasis (reassessment, minimal checks, changed approaches), so an agent knows what the tool produces. It does not explicitly distinguish this from sibling tools like diagnose or retry, so it falls 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?

Usage context is implied rather than stated: the title and the task parameter describe an agent that is stuck, and context mentions failed assumptions. However, the description never says when to prefer stimulate over diagnose, reuptake, focus, retry, or fix_me, nor does it offer exclusion conditions.

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