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

No annotations are provided, so the description carries the full burden. The '[READ]' prefix is a good explicit cue that this is safe and non-destructive, and the note about target being optional/defaulted adds some behavioral context. However, it does not disclose pagination, error handling, permissions, or the exact structure of the response, which is a notable gap for a list operation.

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 highly concise, consisting of two short sections. It front-loads the purpose in the first sentence and immediately follows with an Args block that explains the parameter. Every word earns its place, and it maintains a clean, scannable structure 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 simple tool with one optional parameter and no output schema, the description covers the essentials: what it lists, the returned fields, and how to use the optional target. It stops short of explicitly stating the return format (e.g., an array of objects) or pagination, but given the low complexity, the information provided is sufficient for an agent to select and invoke the tool correctly. A little more detail would make it comprehensive.

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 provides no description for the 'target' parameter (0% coverage), but the description compensates by explaining it as 'Veeam target name from config; omit to use the default.' This adds meaning beyond the schema's bare title and type, making the single parameter fully understandable. The description effectively bridges the schema gap.

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

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

The description clearly states the action ('List'), the resource ('stored backups'), and the returned fields (id, name, type, creationTime). The '[READ]' prefix reinforces its non-mutating nature, distinguishing it from sibling tools like backup_object_list or restore_list_points that operate on different scopes.

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 usage through its explicit purpose and explains the optional target parameter, but it does not explicitly compare this tool with alternatives or state when not to use it. For example, it does not mention backup_object_list as a more detailed option or restore_list_points for restore-specific views. This reliance on inference for tool selection results in a mid-range score.

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 that this is a READ operation, which is a key behavioral trait. However, it does not mention potential errors, permissions, or any side effects. For a read-only list, this level of transparency is adequate but not exceptional.

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 concise and front-loaded with '[READ]' and a single clear sentence describing the tool's purpose. The Args section is broken down neatly, and every line earns its place without unnecessary verbiage.

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 list tool with two parameters and no output schema, the description covers the purpose and parameter meanings. It does not describe the return format or behavior on invalid input, but that is acceptable for a simple list operation. The description is self-contained and sufficient for selecting and invoking the tool.

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

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

Schema description coverage is 0%, so the description must compensate. It does so effectively: 'backup_id: Veeam backup id (see backup_list)' and 'target: Veeam target name from config.' Both parameters are explained beyond their names, and the reference to backup_list adds useful context.

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 tool's function: 'List the protected objects (VMs/agents) inside a stored backup.' This uses a specific verb ('List') and resource ('protected objects inside a stored backup'), distinguishing it from sibling tools like backup_list (which lists backups) and restore_list_points (which lists restore points).

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 provides a cross-reference for the backup_id parameter ('see backup_list'), implying that users must first obtain a backup id from backup_list. This gives contextual usage guidance. However, it does not explicitly state when to choose this tool over alternatives or when not to use it, leaving some ambiguity.

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 burden. It discloses the write nature via '[WRITE]', the effect on scheduled runs, and the dry_run preview option. It does not mention permissions, reversibility beyond the inverse hint, or side effects on currently running jobs, leaving some 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 compact and well-structured: action, inverse, dry_run tip, then a parameter list. Every sentence adds value, with no redundancy or 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?

For a simple tool with no annotations and no output schema, the description covers the essential purpose and parameters. It lacks return value details and error conditions, which are relevant but not critical for a disable action.

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%, but the description explains each parameter: job_id as Veeam job id, dry_run as preview behavior, and target as Veeam target name from config. This adds meaningful value beyond the schema, though target could be more precise.

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 'Disable a backup job' with the effect 'skips scheduled runs', and differentiates from sibling tools by noting 'Inverse: job_enable'. This provides a specific verb+resource+outcome.

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 clear context for use (disabling scheduled runs) and references the inverse tool job_enable, which helps distinguish from alternatives. However, it does not explicitly exclude job_stop or other related tools, so it falls short of a full when-to-use/not guide.

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 bears the full burden of behavioral disclosure. It explains the core action (clears the disabled flag) and dry_run preview mode, but omits details such as idempotency, error handling, or required permissions, which would be useful for an agent to fully understand the tool's behavior.

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 and well-structured: a [WRITE] marker, a one-sentence purpose, an inverse note, a dry_run tip, and a clean Args list. Every sentence adds value with no 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 relatively simple tool, the description covers purpose, parameters, and a preview mode effectively. It could be more complete by addressing edge cases like what happens if the job is already enabled or is not found, but given the basic nature of the operation and no output schema, the essential 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 Args section provides meaningful explanations for all three parameters (job_id, dry_run, target), going beyond the schema's type/default information. This is especially valuable given that the schema description coverage is 0% and the tool relies entirely on the description for parameter semantics.

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 'Enable a backup job (clears the disabled flag)', using a specific verb and resource. It also distinguishes itself from the sibling tool job_disable by explicitly labeling it as the inverse, removing ambiguity about its function.

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 provides clear context for when to use this tool (to enable a disabled job) and mentions the inverse relationship with job_disable. However, it does not explicitly contrast with job_start or job_stop, which could be relevant alternatives depending on the user's intent.

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 burden and does well: it discloses the read-only nature (via '[READ]'), the steps involved (pulling sessions, fetching log records), and the output behavior (categorizing worst-first with cited reasons). It doesn't mention potential side effects (none expected) or prerequisites, but those are less critical for a read-only 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?

The description is well-structured and efficient: it opens with the core purpose, then outlines the process and output, and ends with an Args section. Every sentence adds value, 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?

Even without an output schema, the description explains what the tool returns: categorized findings with session results and matched error substrings. It could be slightly more explicit about the exact return structure (e.g., a list of findings), but overall it's complete for the tool's complexity.

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%, but the description fully explains the only parameter 'target': 'Veeam target name from config; omit to use the default.' This adds meaningful semantics beyond the schema, which only shows nullable string with default null.

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 tool's purpose with a specific verb and resource: 'Triage recent backup-job sessions: flag every Failed/Warning run.' It also details the RCA categorization, distinguishing it from sibling tools like session_list and session_log.

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 provides clear context for when to use the tool (investigating failed/warning backup jobs) and implies it is read-only with the '[READ]' prefix. However, it does not explicitly mention alternatives or when not to use it, so it stops short of a 5.

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 includes a '[READ]' prefix indicating read-only behavior, which is behavioral context. However, with no annotations provided, it lacks details on permissions, rate limits, or side effects. The description adds value beyond the schema but could be more comprehensive.

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 highly concise with two lines of purpose and a brief args list. It is well-structured with a clear [READ] prefix and front-loads the essential purpose. Every sentence is necessary and efficient.

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

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

Given the tool's simplicity (2 params, no output schema, no annotations), the description adequately covers purpose and parameter sources. It is missing details about return value structure, but that is acceptable for a straightforward retrieval tool.

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

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

Schema description coverage is 0%, so the description compensates by providing meaningful explanations for parameters: job_id is described as 'Veeam job id (see job_list)' and target as 'Veeam target name from config'. This adds context beyond the schema's type-only definitions.

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 'Return detail for a single backup job by id', specifying the verb (return detail), resource (single backup job), and identifier (by id). It distinguishes from sibling tools like job_list which returns a list.

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 provides clear context by referencing job_list for obtaining job_id and config for target name. It implies usage context but does not include explicit when-not-to-use or alternative comparisons.

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 [READ] tag explicitly signals a read-only operation, compensating for the lack of annotations. However, it does not disclose possible performance implications or authentication requirements, but for a list tool this is acceptable.

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 extremely concise—two sentences plus a parameter list—with no fluff. The [READ] tag is front-loaded, and every sentence serves a purpose.

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 list tool with one optional parameter and no output schema, the description covers the returned fields and provides a link to a more detailed tool. It does not mention pagination or ordering, but that is acceptable for this tool's complexity.

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 provides only the parameter name and type with no description. The description explains target as 'Veeam target name from config; omit to use the default', adding essential 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 clearly states the tool lists backup jobs with specific fields (id, name, type, status, lastResult) and distinguishes itself from job_get for full detail. This provides a specific verb and resource, with clear differentiation from a sibling tool.

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 explicitly tells when to use job_get instead for full detail, but does not cover other usage exclusions or alternatives like filtering. It gives clear context for the target parameter.

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?

Given no annotations, the description discloses it's a write operation, async behavior, dry_run preview, and that it only retries failed objects. This is good coverage, though it could mention idempotency or 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 very concise yet informative, with a clear structure: purpose line, async note, inverse mention, dry_run hint, and parameter list. Every sentence adds value.

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 it explains async behavior and polling, it does not explicitly state what the tool returns (e.g., session ID, status). The mention of polling with session_list/session_get implies no direct result, but the return format 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?

With 0% schema description coverage, the description adds meaning for all three parameters: job_id (Veeam job id), dry_run (preview), target (Veeam target from config). This compensates well for the lack of schema descriptions.

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 'Retry a failed backup job (re-runs failed objects only)', which specifies the action and scope. It also distinguishes from sibling tools by mentioning 'Inverse: job_stop'.

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 explains async nature with polling instructions and provides a dry_run option. It mentions the inverse tool job_stop, offering guidance on when to use each. However, it does not explicitly state when not to use this tool.

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

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

With no annotations, the description carries the full burden. It discloses that the tool runs as an async session, has an inverse relation, and supports dry-run preview. It doesn't cover failure modes or return values, but the async and polling notes are significant behavioral context.

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 concise and well-structured, front-loaded with the core action. Every sentence earns its place: async note, inverse, polling guidance, and dry-run preview. The Args section is clean and directly follows the behavioral notes.

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 output schema and no annotations, the description covers the essential context: start behavior, async execution, polling with session tools, and dry-run. It could mention what a successful start returns, but the session polling reference implies session handling, which is sufficient.

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 compensates by giving one-line semantics for each parameter: job_id as 'Veeam job id', dry_run as 'preview without starting', and target as 'Veeam target name from config'. This adds meaning beyond the schema's bare type definitions.

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?

Description immediately states '[WRITE] Start a backup job' with a specific verb and resource. It distinguishes from sibling tools by noting 'Inverse: job_stop' and mentions async session, which differentiates from other job-related commands.

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 explicit guidance: 'Inverse: job_stop' names an alternative, and 'Poll progress with session_list / session_get; do not re-issue' provides a clear exclusion (don't re-issue). It also explains the dry_run preview option as a conditional usage.

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 provided, so description must carry full burden. Indicates write operation via '[WRITE]' and describes dry-run preview, but omits consequences of stopping a job (e.g., incomplete state, reversibility, or 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?

Extremely concise: three-line summary plus Args list. Every sentence adds value, no fluff. Front-loaded with main purpose and usage hint.

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?

Covers essential information for a simple tool with 3 parameters and no output schema. Lacks details on return values or behavior after stopping but sufficient for basic usage.

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%, but the description fully documents all three parameters (job_id, dry_run, target) with clear, meaningful explanations beyond type and title.

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 ('Stop a running backup job') and resource, and distinguishes from sibling tool job_start by noting it is the inverse. 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?

Provides guidance on using dry_run parameter and mentions inverse operation, but lacks explicit when-to-use or when-not-to-use context relative to other siblings like job_retry.

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 burden. It explicitly labels the tool as '[READ]' and lists the returned fields, indicating a read-only operation. However, it does not disclose pagination, authentication needs, or rate limits, which are typical behavioral traits. The disclosure is adequate but not comprehensive.

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 extremely concise: two lines with no wasted words. The '[READ]' prefix efficiently sets expectations, and the parameter guidance is front-loaded. Every word serves a purpose.

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's simplicity (one optional parameter, no output schema), the description covers the essential elements: the action, resource, returned fields, and parameter usage. It omits details like sorting or filtering, but for a straightforward list tool this is largely sufficient.

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 coverage is 0%, so the description is the sole source of parameter meaning. It explains 'target' as 'Veeam target name from config; omit to use the default', which adds valuable context beyond the schema's type definition. This clearly guides the agent on valid values and default 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?

The description clearly states 'List managed servers' with the specific fields (id, name, type, description). The '[READ]' prefix further clarifies the action. This distinguishes it from sibling tools like backup_list or job_list.

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 provides guidance on the 'target' parameter, but it does not explicitly state when to use this tool versus alternatives like backup_list or repoistory_list. No when-not or exclusion criteria are given, leaving some ambiguity for 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?

No annotations provided; description carries full burden. It correctly marks the tool as READ-only and lightweight ('one-shot'), but does not disclose other behaviors like potential resource usage or rate limiting.

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 plus a concise Args section. Front-loaded with purpose and usage. Every sentence is essential, no 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?

Given no output schema and one optional param, the description adequately covers purpose, usage, and parameter. Could elaborate on response structure, but not critical for a health summary tool.

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

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

Schema has 0% description coverage, but the description adds meaning to the single 'target' parameter: explains it's a Veeam target name from config and that omitting uses default. Adds value beyond 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?

Description explicitly states it's a READ operation providing a health summary of jobs, repos, and sessions. Differentiates from sibling tools by positioning as a first triage step before drilling into specific entities.

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?

Clear guidance: 'Call this first to triage a Veeam environment before drilling into a specific job, repository, or session.' Implicitly suggests not to use when detailed info is needed, but lacks explicit when-not 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 carries full burden. It includes a [READ] hint and lists returned fields, but does not disclose authorization needs, rate limits, or potential 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?

Two sentences only: one for purpose, one for the parameter. No fluff, front-loaded with the action and resource.

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 list tool, the description is reasonably complete—states data returned and parameter meaning. Missing any filtering options or return format details, but not critical.

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 no descriptions (0% coverage), so the description compensates by explaining the target parameter as a Veeam target name from config and noting the default 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?

The description clearly states it lists backup proxies with specific fields (id, name, type, server), distinguishing it from sibling tools that list backups, jobs, etc.

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 use when needing a proxy list and explains the optional target parameter, but lacks explicit guidance on when to use vs alternatives or when not to use.

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 disclosure burden. It states it pulls per-repository capacity state, reports worst-first, cites free% and free bytes, and suggests an action. The [READ] prefix and 'Pulls' imply read-only. It could add details on permissions or empty-result behavior, but it covers the core behavior well.

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 concise and front-loaded with the main purpose. The three sections (summary, details, args) are each useful with no filler. Every sentence adds value.

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 explains what the output contains (per-repo worst-first findings with free%, free bytes, and action). It is complete for a simple one-param tool, though it doesn't mention edge cases like no repositories under threshold or invalid target.

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?

Only one parameter exists with 0% schema coverage, but the description fully explains it: 'Veeam target name from config; omit to use the default.' This adds meaning beyond the schema's title/default and makes the optional behavior explicit.

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 ('Flag') and resource ('backup repositories running low on free space'), clearly distinguishing it from siblings like repository_list, repository_get, and repository_state. It also states the exact purpose with thresholds and ordering.

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 context is clear: this is a capacity RCA tool that reports worst-first findings. It doesn't explicitly name alternatives or when not to use, but the [READ] marker and specific thresholds imply a monitoring use case that differentiates it from simple listing or state 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?

With no annotations provided, the description carries the safety burden. The '[READ]' tag explicitly signals a non-destructive operation, and 'when known' discloses that capacity/free/used data may be absent or incomplete. This is valuable transparency, though it stops short of detailing response errors or authorization needs.

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 extremely concise, starting with the [READ] flag and then providing a single-sentence summary plus an argument list. Every word earns its place with 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 simple tool with 2 parameters and no output schema, the description is largely sufficient. It explains the purpose, the key data returned (capacity/free/used), and parameter guidance. The lack of an explicit return format or error handling is a minor gap, but overall it is complete enough for an agent to select and invoke 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%, so the description must compensate. It does explain both parameters: repository_id as 'Veeam repository id (see repository_list)' and target as 'Veeam target name from config.' This adds meaning beyond titles, but lacks specifics like value formats or constraints, keeping it at moderate usefulness.

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 'Detail for one repository incl. capacity/free/used when known' with a '[READ]' prefix, clearly indicating a read operation for a specific repository. This distinguishes it from sibling tools like repository_list (list all) and repository_state (state-specific).

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 provides clear context by mentioning 'Veeam repository id (see repository_list)', implying the user should first list repositories to obtain the ID. However, it does not explicitly state when not to use this tool or name alternative tools beyond the hint to repository_list.

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 of disclosing behavioral traits. It includes the '[READ]' prefix, signaling a non-mutating operation, and lists expected output fields. However, it lacks details about authentication requirements, error handling, or pagination, which would enhance transparency.

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 two sentences long, front-loaded with the tool's purpose, and each sentence provides necessary information. There is no redundancy or wasted words.

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 list tool with one optional parameter and no output schema, the description sufficiently covers purpose, output fields, and parameter behavior. It lacks explicit sibling differentiation or caveats, but is otherwise complete for its scope.

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 only notes that 'target' is an optional string with a null default, but the description explains it as a 'Veeam target name from config' and that omitting it uses the default. This adds meaningful context 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 clearly states the action 'List backup repositories' and specifies the output fields (id, name, type, path). This distinguishes it from sibling tools like repository_get and repository_state, which imply single-repository details or status.

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 provides no guidance on when to use this tool versus alternatives such as repository_get or repository_state. It only explains the target parameter, not the selection context.

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 labels it as [READ], indicating a read-only operation, and specifies the output fields. However, it lacks details on error behavior, authentication requirements, or any side effects. Since no annotations exist, the description carries the full burden but does not fully address these aspects.

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 concise, front-loaded with the [READ] tag and the core purpose. The Args section is structured and provides necessary parameter info without redundancy. Every sentence contributes value.

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's simplicity (one optional parameter, no output schema), the description covers the essential aspects: purpose and parameter meaning. It mentions the returned fields, though it could be improved by clarifying whether the output is a list or a single object. Overall, it is 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?

The description explains the 'target' parameter as a Veeam target name from config, with a clear usage instruction to omit for default. This adds significant meaning beyond the schema, which only provides type information. Schema coverage is 0%, so the description compensates well.

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 it returns a capacity summary for every repository, with specific fields (capacity/free/used/used%). This distinguishes it from sibling tools like repository_get and repository_list, though not 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?

No guidance on when to use this tool versus alternatives. The description implies usage for capacity summaries but does not provide context for exclusion or comparison with 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?

The description clearly labels the operation as a read ('[READ]'), which is a key behavioral trait. It also discloses a limitation: server-side filtering via backup_id varies by Veeam version. Since there are no annotations, the description carries the full burden and does a good job at conveying read-only nature and caveats.

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 concise and well-structured. It leads with a clear purpose sentence, then provides parameter documentation in a compact Args block. Every sentence earns its place with no waste 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?

Given the tool's simplicity (2 optional parameters, no output schema), the description is complete. It specifies the output fields, parameter behavior, and default target usage. The mention of backup_list provides helpful cross-context. No critical information is missing for an agent to invoke the tool 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?

With 0% schema description coverage, the description fully compensates by explaining both parameters: backup_id (optional filter, cross-referenced to backup_list) and target (Veeam target name from config, default behavior). This adds meaning well beyond the schema's bare property definitions.

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 tool's function: 'List restore points (id, name, creationTime, type).' The verb 'List' is specific, the resource is unambiguous, and the included fields add precision. There are no sibling tools that overlap with this function, so it effectively differentiates itself.

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 provides explicit context for use: it explains when to pass backup_id to filter, notes the preview feature and server support variability, and clarifies the target parameter's default behavior. It does not explicitly mention when not to use the tool or direct alternatives, but the usage context is clear and sufficient.

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?

Despite no annotations, the description indicates a read-only polling operation. It does not mention potential side effects or rate limits, but for a simple poll, the description is adequate. Slight room for more explicit safety assurances.

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?

Concise and front-loaded with purpose. Uses a clear 'Args' section. Every sentence is necessary and informative, with no fluff.

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?

Lacks output schema and does not describe the response format. However, for a polling tool, the purpose is clear. Could benefit from mentioning what fields are returned, but overall sufficient given sibling tools and parameter guidance.

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?

With 0% schema coverage, the description adds crucial meaning: 'session_id: Veeam session id (see session_list). target: Veeam target name from config.' This tells the agent where to obtain values and the nature of each parameter.

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

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

The description starts with '[READ] Poll one session by id to check job/restore progress.' This clearly specifies the action (poll, check) and the resource (session by id), distinguishing it from siblings like session_list and session_log.

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 after job_start or start_vm_restore to follow the operation instead of re-issuing it.' This provides clear usage context and excludes misuse.

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 includes a '[READ]' prefix, explicitly indicating this is a safe, read-only operation. It also discloses that it returns recent sessions and lists the output fields. Since there are no annotations to convey safety, this is valuable. However, it does not mention potential caveats like pagination, ordering, or limits, which would be useful but not critical for a simple list operation.

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 extremely concise, with no redundant words. It front-loads the core purpose in the first line and then provides the parameter details in a clear, structured format. 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?

Given the tool's simplicity (one optional parameter, no output schema, no annotations), the description is largely sufficient. It states what is listed and the available fields. It stops short of mentioning whether there is a limit on the number of sessions or any ordering, but these are not essential for a basic list 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?

The description fully explains the only parameter: 'target: Veeam target name from config; omit to use the default.' This adds meaning beyond the bare schema, which only defines type (string/null) and default. It clarifies the source of the value and the behavior when omitted, which is essential for correct 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 clearly states the tool's function: 'List recent sessions' with specific fields (id, name, type, state, result). This verb+resource combination is unambiguous and distinguishes it from sibling tools like session_get (retrieves a single session) or session_log (retrieves logs).

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 provides no guidance on when to use this tool versus alternatives like session_get or session_log. It neither mentions exclusions, prerequisites, nor scenarios where this tool is preferred. The reader must infer usage solely from the tool name and the generic 'List' action.

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 burden for behavioral disclosure. It only marks '[READ]' and says 'return the log records', but omits important details such as output format, pagination, potential size/volume of logs, or whether any side effects occur. This is insufficient for a tool with no structured 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?

The description is compact and front-loaded with '[READ]' and a clear purpose. It avoids filler, with two sentences plus a concise args list. Every sentence contributes to understanding the tool's purpose or usage, making it highly efficient.

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

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

For a simple tool with only two parameters and no output schema, the description covers purpose, use case, and parameter meaning. However, it does not describe the return value's structure or any limitations, which could leave an agent uncertain about how to interpret the result. Given the absence of an output schema, a bit more detail on return format would be beneficial, but the tool is simple enough that this is adequate.

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 provides only titles ('Session Id', 'Target') with no descriptions, so the documentation coverage is 0%. The description compensates by explaining both parameters: session_id is a 'Veeam session id (see session_list)' and target is a 'Veeam target name from config'. This adds meaningful context beyond the schema, though it could be more detailed about allowed values or formats.

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 'Return the log records (events) of one session' with a clear verb and resource, explicitly scoped to a single session. This distinguishes it from siblings like session_list (lists sessions) and session_get (presumably returns session details), making the tool's purpose 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 gives an explicit use case ('see why a session failed instead of re-running the job blind') and even suggests an alternative (re-running) to avoid. However, it does not explicitly mention when not to use it or reference sibling tools like job_failure_rca that might also diagnose failures, so it falls short of full alternative 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, description discloses the write/destructive nature ([WRITE]), irreversibility (no undo token, must re-issue), and dry-run option. It does not cover permissions or error handling but covers the critical consequences.

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?

Description is well-structured with a front-loaded first sentence, followed by critical notes and a clear Args list. No filler; every sentence adds value.

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?

Covers purpose, side effects, and parameters adequately for a stop operation. With no output schema, return details are not explained, but behavior and consequences are sufficiently complete for an agent.

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 descriptions carry full burden. All three parameters are explained with context: session_id sourced from session_list, dry_run for preview, target from config. This exceeds basic schema info.

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 clearly it stops a running session and cancels the underlying operation, with a specific verb and resource. It is distinct from siblings like session_list/get/log and job_stop.

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?

Provides clear context for use (stopping a running session) and mentions dry-run preview, but does not explicitly name alternatives or when-not-to-use conditions.

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 discloses that the operation is a write, irreversible, runs as an async session, and may refuse to overwrite the VBR host. Also explains the dry_run preview behavior.

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?

Long but well-structured with a clear opening warning, logical flow, and minimal redundancy. Could be slightly tighter but every sentence adds value.

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?

Covers the operation well: mentions async polling, irreversibility, and parameter semantics. No output schema, but the description indicates how to check results via session tools, which is sufficient.

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 has 0% description coverage, but the description explains all three parameters: restore_point_id (referenced to restore_list_points), dry_run (detailed preview behavior), and target (Veeam target name).

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?

Specifically states 'start a VM restore from a restore point', uses a clear verb-resource pair, and distinguishes from sibling tools by focusing on restore operations and async sessions.

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 to confirm with user due to irreversibility, explains use of dry_run for preview, and provides a safety warning about the VBR host overwrite check. No when-not-to-use stated, but the guidance is comprehensive.

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?

In the absence of annotations, the description discloses important behavioral traits: it is a write operation ([WRITE][risk=medium]), the inverse runs under its own risk tier, dry_run preview is available, and a token can only be applied once. This provides good transparency.

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 concise at 5 sentences plus an Args list, well-structured with a header and parameter explanations. It earns its place without verbosity, though could be slightly more streamlined.

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 no annotations or output schema, the description covers the tool's function, parameters, behavior, and safety notes. It lacks explicit return value details and error conditions, but is largely complete for typical usage.

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?

With 0% schema description coverage, the description fully compensates by explaining each parameter in the Args block: undo_id sourced from undo_list, dry_run for preview, and target passed through. This adds significant meaning beyond the bare 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 clearly states the tool's purpose: 'Apply a recorded undo by dispatching its inverse tool.' It uses specific verb 'apply' and resource 'undo', and distinguishes from sibling undo_list by referencing undo_id from undo_list.

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 explains the mechanism and parameters but does not explicitly state when to use this tool versus alternatives like undo_list. It implies usage context by mentioning the inverse tool and dry_run, but lacks direct comparisons.

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 fully bears the behavioral disclosure burden. It details the return envelope (including truncated field), explains that one extra row is requested to measure truncation, and describes the effectVerified field and its implications. This goes beyond a simple read declaration to cover edge cases and behavioral nuances.

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 long but well-structured. It front-loads the purpose, then explains the envelope, a specific field, and finally the parameters. Each sentence adds value; however, some repetition or extraneous detail could be trimmed while retaining 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?

Given the absence of an output schema, the description thoroughly explains the return format and key fields (truncated, effectVerified). It also covers parameter behaviors and edge cases (capped limit, truncated reads). This makes the tool self-contained and complete for agent use.

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 is minimal (limit and target with defaults). The description adds critical meaning: limit is capped at 500 and has a default of 50, and target is unused (accepted for CLI uniformity). Since schema description coverage is 0%, the description completely compensates, providing constraints and context for each parameter.

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

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

The description begins with '[READ] List recorded, not-yet-applied undo tokens (most recent first).' This clearly identifies the tool as a read operation listing undo tokens, with a distinct verb and resource. The sibling tools include 'undo_apply', which is complementary, and the description explicitly mentions using the undoId with undo_apply, differentiating the two.

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 explains that the tool provides undoId for use with undo_apply, implying it is a prerequisite. It also discusses the envelope format and why truncation is important, guiding the agent on when the tool is needed. However, it does not explicitly state when not to use it or compare to other sibling list tools like job_list.

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