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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description usefully discloses the returned fields, but says nothing about pagination, whether the list is scoped to a target, or any filtering 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?

Front-loaded with the [READ] marker and one-line purpose, followed by a minimal Args block. Every line earns its place 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 single-optional-parameter list tool with no output schema, the definition covers the action, the return fields, and the parameter's default behavior. It is sufficient, though the missing distinction from backup_object_list is a residual gap.

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

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

Schema coverage is 0%, so the description must compensate, and it does: it explains that target is a Veeam target name drawn from config and that omitting it uses the default. That adds real meaning beyond the bare anyOf string/null 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?

States a specific verb (List) and resource (stored backups) and enumerates the returned fields (id, name, type, creationTime). However, it does not differentiate from the sibling backup_object_list, leaving the agent to infer whether 'backups' and 'backup objects' are distinct concepts.

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 [READ] prefix implies it is a non-mutating query, but there is no explicit when-to-use guidance, no prerequisites, and no mention of when to prefer backup_object_list. The only usage hint is on the target arg.

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?

readOnlyHint=true already tells the agent this is a safe read, and the '[READ]' tag merely repeats that. The description does add value by specifying what is returned (VMs/agents inside a stored backup), but says nothing about pagination, ordering, empty-backup behavior, or errors for an invalid backup_id.

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 stating scope, followed by a compact two-entry Args block. No filler, no restating of the tool name, and the return entity is named immediately.

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

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

For a simple read-only list tool with no output schema, the description identifies the returned entities and both inputs, which is close to sufficient. It omits any mention of result shape or volume (e.g., whether all objects are returned at once), leaving a small gap.

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

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

Schema description coverage is 0%, so the description must carry the load, and it documents both parameters: backup_id as a Veeam backup id sourced from backup_list, and target as a Veeam target name from config. It lacks format/example details and doesn't clarify what happens when target is omitted (default null), so it stops short of full coverage.

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

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

States a specific verb and resource ('List the protected objects (VMs/agents) inside a stored backup'), and the phrase 'inside a stored backup' distinguishes it from the sibling backup_list, which enumerates backups rather than their contents. An agent can pick between the two without opening either schema.

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

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

The description points to backup_list as the source of backup_id ('see backup_list'), which implies the tool is used after listing backups to drill into one. However, it never states when to use this versus backup_object_storage_usage or backup_storage_ranking, nor any exclusions or prerequisites.

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 readOnlyHint already supplied, the description goes well beyond annotations: it discloses the VBR 12.3+ requirement, that shared files are excluded from storedBytes, that caveats flag upper bounds on block-clone repositories, and that found=false returns candidates rather than guessing. This is unusually rich behavioral context for a read 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?

Front-loads purpose, then semantics, then caveats, then an Args block, so it is well structured. It is on the long side, but nearly every sentence carries distinct information about accounting behavior, so little is wasted.

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

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

There is no output schema, so the description must describe the return shape, and it does: repository, restore-point count, full vs incremental bytes, GFS files, job retention, change rate, sharedStoredBytes, caveats, and found. An agent has everything needed to interpret the result and avoid misuse.

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 carries the full burden and does: it explains that name is matched case-insensitively but exactly as Veeam shows it, and that target is a Veeam target name from config which defaults when omitted. Both parameters are fully clarified 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?

States a specific verb and resource: reads the backup storage one VM/agent consumes, per backup, as showback input. It is clearly distinguishable from siblings like backup_storage_ranking and backup_object_list, and the [READ] prefix signals the operation class immediately.

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?

Frames the use case explicitly ('Read before charging', showback input) and gives the operational condition that storage must not be double-counted. It does not name sibling alternatives or state when not to use it, so it stops short of an explicit routing rule.

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 only readOnlyHint available, the description carries rich behavioral detail well beyond annotations: a concrete cost profile ('a 123-backup VBR 13.1 estate took 21 minutes'), parallel-read risk that can push past the timeout, the config.yaml timeout remedy instead of retrying, the meaning of `scoped`/`backupsTruncated` as non-estate-wide results, and the VBR 12.3+ requirement.

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?

Purpose and the 'largest first' ranking are front-loaded, and most sentences pay for themselves with operational detail. The middle block on ownerlessStoredBytes/unmatchedOwnerStoredBytes/unmatchedOwners is dense and heavily nested, but since there is no output schema it is load-bearing rather than 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 slow, estate-wide aggregation tool with 0% schema coverage and no output schema, the description supplies the missing pieces: output field semantics, attribution rules, truncation flags, performance expectations and scoping caveats. An agent has everything needed to call it and interpret the result 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 and does document all six parameters with meaning beyond the bare types: ranges and defaults for limit/max_backups/concurrency, 'raise for full coverage,' 'by id or name' for backups/repository, and target's config-derived lookup with default fallback.

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?

Opens with a specific verb+resource+ordering: 'Protected objects ranked by backup storage consumed, largest first,' plus a plain-language framing ('which machines are the most expensive to protect'). An agent can immediately tell this is a ranking/aggregation tool rather than a per-object usage lookup, even though it does not explicitly name the nearby backup_object_storage_usage sibling.

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

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

Gives explicit selection context: 'scope it with `backups` or `repository` when the question is about part of the estate.' It also states the decision rule for billing ('Judge whether these numbers can be billed on `unmatchedOwnerFiles` being 0'). However, it never names an alternative tool for cases where a scoped or cheaper answer would be preferable, so it falls short of a full when/when-not/alternatives statement.

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 destructiveHint=true and readOnlyHint=false, and the description adds real value beyond them: the '[WRITE]' tag, the explanation that disabling skips scheduled runs, and the dry_run preview affordance. It still doesn't spell out whether the job must be stopped first or confirm reversibility beyond naming job_enable.

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?

Front-loaded with the '[WRITE]' tag and core purpose, with a tidy Args block. Slight redundancy in stating the dry_run behavior twice (once inline, once in Args), but nothing wasteful otherwise.

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 three-parameter write tool with no output schema, the description covers purpose, effect, inverse, preview mode, and every parameter. It is essentially complete, missing only edge-case behavior such as what happens on an already-disabled job.

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 carries the full burden and documents all three parameters (job_id as Veeam job id, dry_run semantics, target from config). This compensates well for the empty schema, though it adds no format/validation detail for job_id.

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 precise verb+resource ('Disable a backup job') and clarifies the consequence ('skips scheduled runs'). It also names its inverse (job_enable), so an agent can distinguish it from job_stop/job_start/job_enable without opening the schema.

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

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

Gives the inverse relationship with job_enable and the dry_run preview workflow, which supplies clear usage context. It stops short of an explicit when-to-use-this-vs-alternatives rule (e.g. disable vs stop), so it is clear but not fully prescriptive.

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=false, idempotentHint=false, and destructiveHint=true, so safety profile is covered. The description adds real context by explaining the state change ('clears the disabled flag') and the dry_run preview. However it never explains why the operation is marked destructive (e.g., enabling triggers scheduled backups) nor the non-idempotent behavior, leaving notable behavioral 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?

Front-loaded with the [WRITE] tag and core action, then inverse, then preview hint, then args. Efficient and scannable with no filler, though the Args block slightly duplicates the schema titles.

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?

No output schema exists, so return values need not be explained, and all three parameters plus the key behavioral trait are covered. A mutation tool with annotation coverage is adequately described, with only minor gaps around error/already-enabled handling.

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 carry the burden, and it does: job_id (Veeam job id), dry_run (preview without enabling), and target (Veeam target name from config) are all documented. The explanations are terse but sufficient for correct invocation.

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 the exact verb and resource ('Enable a backup job') and clarifies the mechanism ('clears the disabled flag'). It also names the inverse sibling job_disable, letting an agent distinguish it from job_disable without opening either schema.

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

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

Explicitly names the inverse tool (job_disable) and points to dry_run=True for preview before committing. This gives clear routing and safety guidance, though it doesn't spell out preconditions (e.g., job already enabled, required config state).

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 declare readOnlyHint=true; the description goes well beyond that, disclosing the multi-step behavior (pull newest sessions, fetch failing logs, categorize by cause worst-first), the possible cause categories, the citation format, and the sessionsTruncated=true truncation signal. This is exactly the kind of behavioral context annotations cannot carry.

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?

Front-loaded with a [READ] tag and the core action, then structured detail and an Args block. Every sentence earns its place, though the Args section duplicates the schema — defensible here since schema coverage is 0%.

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?

There is no output schema, so the description carries the return-value burden and does: it describes cited findings with session result and matched error substring, and the sessionsTruncated flag. For a read-only diagnostic tool with three optional params, an agent has everything needed to call and interpret it.

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: limit is the newest-N sessions analysed with range 1-1000 and default 100, since_hours restricts to sessions created in the last N hours, and target is a Veeam target name from config to be omitted for the default. Each parameter's meaning and interaction (limit vs. time window) is explained.

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

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

States a specific verb and resource (triage recent backup-job sessions, flag Failed/Warning runs) plus the full pipeline it executes (fetch failing log records, categorize likely cause). It is clearly distinguishable from siblings like session_list, session_log, and repository_capacity_rca, which only list or fetch raw records.

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

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

Gives an explicit when-to-use rule: pass since_hours=24 for 'what failed last night' so the window is a time span rather than whatever fits in the newest limit sessions of every type. It also flags that an omitted target uses the default. It stops short of naming alternative sibling tools or stating when not to use it.

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

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

The "[READ]" prefix is consistent with readOnlyHint=true, so there is no contradiction and the safety profile is already carried by annotations. Beyond that the description adds no behavioral context — nothing about error handling for an unknown job_id, pagination, or what detail is returned. With annotations covering the safety side, this is a minimum-viable disclosure.

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 lead sentence states the action and scope first, followed by a compact Args block. Every line earns its place with no redundant restatement of the schema.

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 get tool with no output schema, the description should hint at what "detail" comprises or the shape of the response; it does not. Combined with the absence of any failure-mode guidance for an invalid job_id, it is adequate but leaves real 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 0%, so the description must carry the parameter burden, and it does: job_id is identified as a Veeam job id sourced from job_list, and target as a Veeam target name from config. It still does not say whether target defaults to the configured target when omitted, which would have made it a 5.

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?

"Return detail for a single backup job by id" gives a specific verb (return detail), resource (backup job), and scope (single, by id). This implicitly separates it from job_list, and the "(see job_list)" cross-reference reinforces the relationship, though it never states the contrast explicitly.

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

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

The description only tells the agent where to obtain the job_id; it gives no guidance on when to retrieve job detail versus using job_failure_rca, job_list, or session_get. The "[READ]" tag implies a read context but no when/when-not conditions or prerequisites are 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?

The readOnlyHint annotation already establishes this is a safe read. The '[READ]' tag and the enumerated summary fields add useful context (this returns summaries, not full detail), but nothing is said about pagination, limits, or failure behavior of listing.

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?

Short and front-loaded: verb-resource-fields first, sibling routing second, argument note last. No wasted sentences, though the 'Args:' block is slightly formal overhead for a single optional parameter.

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 compensates by naming the returned fields, and it resolves the one ambiguous parameter. For a simple one-param read tool this is essentially complete.

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

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

Schema coverage is 0% and the schema only labels the param 'Target' with a null default, so the description carries the semantic load: it states it is a Veeam target name from config and that omitting it uses the default. That is the key operational detail an agent needs and is not available elsewhere.

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

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

States a specific verb and resource ('List backup jobs') and enumerates the returned fields (id, name, type, status, lastResult), which distinguishes it from job_get explicitly. An agent can differentiate it from the sibling list tools without opening a schema.

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

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

Explicitly routes deep single-job inspection to job_get, and explains the target argument's default behavior. It does not say when to prefer this over other list tools such as backup_list or session_list, but the context is otherwise clear.

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=false, destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description adds genuinely new behavior: execution is asynchronous and must be polled via session tools, retry scope is limited to failed objects, and dry_run previews without retrying. It does not mention permissions or what state is overwritten, so it falls short of a 5.

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

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

Front-loads the operation type and purpose, then async/polling guidance, then alternatives, then args — a sensible order with no filler sentences. The Args block partially restates names already in the schema, but given 0% schema description coverage that restatement earns its place.

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

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

For a mutation tool with no output schema and three undocumented-in-schema params, the description covers what the tool does, how it executes, how to poll it, and how to preview it safely. The only gap is how the agent obtains the session identifier to poll with, which is left implicit.

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 carry the parameter burden, and it does — all three args are described (job_id, dry_run semantics, and target as a config-sourced Veeam target name). The notes are terse and don't specify ID format, but they fully cover the parameter set.

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

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

States a specific verb and resource ('Retry a failed backup job') plus a scope qualifier ('re-runs failed objects only'), which separates it from job_start and job_get. It also names the inverse sibling (job_stop), so an agent can place it correctly among the job_* family without opening a schema.

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

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

Gives clear operational context: it runs as an async session, must be polled with session_list/session_get, and supports dry_run=True for preview. It also names the alternative relationship (job_stop cancels the in-flight retry), but never states an explicit when-not condition or contrasts it against job_start.

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=false, destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description adds context the annotations cannot: the operation is asynchronous, progress is observed through session tools, and it must not be re-issued (concretely explaining the non-idempotent behavior). Auth requirements and failure modes remain unstated.

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?

Front-loaded with the [WRITE] marker and the core action, followed by behavior, inverse, polling guidance, and a compact Args block in three short lines. No sentence is filler and the agent-critical constraints appear before the parameter list.

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 correctly substitutes by telling the agent how results are observed (session_list/session_get) and that polling rather than re-issuing is the pattern. Combined with annotation-covered safety, it is nearly complete for a 3-param async start tool; only error/conflict behavior is unaddressed.

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

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

Schema description coverage is 0%, so the description carries the full burden and does document all three parameters: job_id as the Veeam job id, dry_run as a preview toggle, and target as a Veeam target name from config. The explanations are terse but sufficient to disambiguate each parameter, which is a large improvement over the bare schema titles.

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

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

States a specific verb+resource ('Start a backup job') and immediately distinguishes itself from siblings by naming job_stop as its inverse and pointing to session_list/session_get for progress. An agent can pick this over job_retry or job_start-adjacent tools without opening any schema.

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

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

Gives real operational guidance: it runs as an async session, progress must be polled via session_list/session_get, and it must not be re-issued. It also offers dry_run=True as a preview path and names job_stop as the inverse. It does not, however, clarify when to choose this over job_retry, which is the most plausible adjacent alternative.

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=false and destructiveHint=true, so safety is covered by structured data; the "[WRITE]" tag merely restates it. The description does add one genuinely useful behavioral fact — that dry_run previews without stopping — but says nothing about permissions, whether the stop is graceful, or reversibility.

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 operation is front-loaded in the first sentence, followed by the sibling relation and the preview hint; the Args block is compact and nothing is wasted.

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

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

For a simple, non-idempotent write with annotations covering the safety profile and no output schema, the description covers purpose, parameters, and the dry-run path. It could note prerequisites (job must be running) or that a job_id from job_list is required, but nothing essential is missing.

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

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

Schema description coverage is 0%, so the description must carry the load, and it documents all three parameters, including the non-obvious target ("from config") and the effect of dry_run. Descriptions are terse ("Veeam job id") but sufficient to call correctly.

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 precise verb and resource ("Stop a running backup job") and immediately names the inverse sibling (job_start), so an agent can place it against job_start/job_retry/job_disable without opening any schema.

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

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

The inverse relationship with job_start gives clear positioning, and "Pass dry_run=True to preview" tells the agent how to use it safely. There are no explicit when-not conditions (e.g. vs job_disable or job_retry), 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?

readOnlyHint=true already tells the agent this is a safe read, so the '[READ]' prefix is redundant. The description does add useful value by enumerating the returned fields, which matters since there is no output schema, but says nothing about volume, pagination, or error 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?

Two short segments with the purpose front-loaded and no filler. The bracketed '[READ]' tag and the 'Args:' block are slightly mechanical but cost almost nothing.

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 single optional-parameter list tool with no output schema, the description covers the resource, the return fields, and the sole argument's semantics and default. Only the absence of any sibling-routing guidance keeps it from being fully complete.

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

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

Schema description coverage is 0%, so the description must carry the load — and it does: 'target' is defined as a Veeam target name sourced from config, with the explicit default behavior when omitted. This is exactly the clarification the bare schema lacks.

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

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

States a specific verb and resource ('List managed servers') plus the fields returned (id, name, type, description), so the agent knows exactly what comes back. It does not differentiate itself from the many sibling list tools (proxy_list, repository_list, job_list), but the resource noun is distinct enough to route on.

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

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

There is no when-to-use guidance relative to alternatives such as proxy_list or repository_list, nor any prerequisite or exclusion noted. The only usage-like instruction ('omit to use the default') concerns the target argument, not tool selection.

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

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

readOnlyHint=true already tells the agent this is a safe read, and the '[READ]' tag reinforces it. The description adds value beyond annotations by disclosing the actual payload of the summary (job results, capacity warnings, active sessions), which matters since there is no output schema. It does not cover scoping/limits of the aggregate, so not a 5.

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

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

Front-loaded purpose, then a one-line usage directive, then a compact Args block. Every sentence earns its place and there is no repetition of schema content.

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

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

With no output schema, the description compensates by naming the three summary sections it returns, and it explains the single parameter. It stops short of describing granularity or limits of the aggregate, but it is complete enough to call correctly.

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

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

Schema description coverage is 0%, so the description must carry the param, and it does: 'target: Veeam target name from config; omit to use the default' explains origin and default behavior. It does not describe accepted formats or errors for an unknown target, leaving a small gap.

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

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

States a specific verb+resource ('one-shot health summary') and enumerates exactly what it summarizes: jobs by last result, repos near full, running sessions. This clearly distinguishes it from the drill-down siblings (job_get, repository_get, session_get).

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

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

Explicitly says 'Call this first to triage a Veeam environment before drilling into a specific job, repository, or session,' which gives both the ordering ('first') and the alternative path (per-entity drill-down tools). Nothing is left to inference.

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

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

The '[READ]' tag duplicates the readOnlyHint annotation rather than extending it, and the description otherwise adds only the default-target behavior. With annotations already declaring the safety profile for a simple list operation, this is adequate but not rich.

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?

Tight and front-loaded: one sentence for purpose plus a one-line arg note. The only waste is the redundant '[READ]' marker already supplied by annotations.

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, listing the returned fields (id, name, type, server) is exactly the right compensation for a single-parameter, read-only listing tool. Nothing needed to call it correctly is missing.

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

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

Schema coverage is 0% and the only parameter has a bare 'Target' title, so the description carries the burden. It does explain the semantics well: the value is a Veeam target name from config and omitting it selects the default, which meaningfully exceeds 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?

States a specific verb and resource ('List backup proxies') and enumerates the returned fields (id, name, type, server). This is enough to distinguish it from sibling listings such as repository_list or managed_server_list without opening any schema.

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

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

Usage is only implied: it is a read-only enumeration of proxies. There is no explicit statement of when to prefer this over siblings like managed_server_list or repository_list, though the guidance on omitting 'target' to fall back to the default is useful.

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 declare readOnlyHint=true; the description goes well beyond that by disclosing the output shape (per-repository capacity state, worst-first ordering), the threshold semantics (<15% warn, <10% critical), the cited measurements (free%, free bytes), and the recommended action. It omits pagination/rate/auth details, keeping it short of a 5.

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

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

The [READ] tag and one-line purpose statement are front-loaded, followed by tightly scoped detail, and the Args block is minimal. The line-wrapped presentation is slightly longer than needed but no sentence is 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?

With no output schema, the description must describe returns — and it does, covering ordering, cited metrics, and the remediation action per finding. The only shortfall is the lack of explicit routing guidance versus the overlapping repository_state sibling.

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

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

Schema description coverage is 0% and the 'target' property carries no description, but the Args block compensates by explaining that target is a Veeam target name from config and that omitting it falls back to the default. That is exactly the missing semantics the schema lacks.

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

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

States a specific verb and resource — flagging backup repositories running low on free space — and immediately elaborates the exact analysis (worst-first capacity findings with warn/critical thresholds). This differentiates it from the plain-listing siblings repository_list and repository_state.

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

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

Usage is strongly implied by the capacity-finding purpose and the threshold description, so an agent knows roughly when this applies. However, it never names an alternative (e.g., repository_state) or states an exclusion, leaving the agent to infer routing against an overlapping sibling.

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?

readOnlyHint=true already tells the agent this is a safe read, so the "[READ]" prefix is partly redundant. The description does add one genuine behavioral detail — capacity/free/used are returned "when known", implying fields may be absent — but says nothing about how a missing repository or unknown target is handled.

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?

Front-loads the one-line purpose before the Args block, and each parameter line adds information rather than restating the schema title. Slightly padded by the redundant [READ] marker.

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

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

For a low-risk two-parameter read with a readOnlyHint and no output schema, the description covers purpose, id provenance, and the shape of the returned capacity figures. The main omission is any hint of overlap with repository_state or failure behavior.

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

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

Schema description coverage is 0%, so the description carries the burden and mostly succeeds: it identifies repository_id as a Veeam repository id obtainable via repository_list, and explains that target is a Veeam target name sourced from config rather than something the caller invents.

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

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

States a specific verb+resource ("Detail for one repository") and marks it [READ], which separates it from repository_list. It does not, however, distinguish itself from the sibling repository_state or repository_capacity_rca, both of which sound like they touch repository detail.

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

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

The parenthetical "(see repository_list)" usefully routes the agent to the sibling that produces the required id, which is real usage guidance. Beyond that there is no when-to-use vs. when-not-to-use statement and no guidance on choosing between this and repository_state.

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 readOnlyHint annotation already establishes this is a safe read, and the '[READ]' tag merely restates it. The description does add the concrete shape of the result (id, name, type, path), which is behavioral value annotations do not cover, but says nothing about pagination or filtering behavior on a potentially large repository list.

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?

Very short and front-loaded: the verb, resource, and return fields come first, and the parameter note is second. The 'Args:' block is slightly mechanical but nothing is wasted or redundant.

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

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

For a zero-required-parameter read-only list with no output schema, the description covers what the tool does, the one parameter's fallback semantics, and the returned fields. It is close to complete for this complexity level, lacking only pagination/scale hints.

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 carries the parameter burden, and it does: it explains that target is a 'Veeam target name from config' and that omitting it falls back to the default. That is meaningfully more than the bare untyped string/null schema provides, though it doesn't give format examples.

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

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

States a specific verb and resource ('List backup repositories') and even enumerates the returned fields (id, name, type, path), so the agent knows exactly what it gets. It does not explicitly distinguish itself from sibling repository_get, but 'List' vs 'get' plus the returned field set makes the distinction reasonably inferable.

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 only guidance is the optionality note on target ('omit to use the default'), which is useful for invocation but not for tool selection. There is no statement of when to prefer this over repository_get, repository_state, or repository_capacity_rca, leaving usage implied by the name.

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 readOnlyHint annotation already declares the safe-read profile, and the '[READ]' prefix merely restates it. The description does add useful scope context ('for every repository') and names the returned metrics, but no auth, rate-limit, or freshness behavior is disclosed.

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?

Very short and front-loaded: the capability summary comes first, followed by an 'Args' block. The '[READ]' tag is mildly redundant with the annotation but harmless; nothing is wasted.

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

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

With no output schema, the description conveniently enumerates the returned fields (capacity/free/used/used%), which is enough for a single-parameter read tool. Only the routing versus the capacity-RCA sibling remains unaddressed.

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

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

Schema coverage is 0%, so the description must carry the parameter alone, and it does: 'target: Veeam target name from config; omit to use the default' explains both the source of valid values and the default behavior. Only the exact expected format (e.g., name vs. ID) is left unspecified.

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

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

States a specific resource (repository) and a concrete output ('capacity summary' with capacity/free/used/used%), which distinguishes it from repository_list and repository_get. It does not, however, explicitly distinguish itself from the sibling repository_capacity_rca, so sibling differentiation is only partial.

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

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

Usage is only implied: an agent can infer this is the read-only aggregate view of repository capacity, but there is no explicit statement of when to choose it over repository_get or repository_capacity_rca. The sentence about omitting target to use the default is parameter guidance rather than when-to-use guidance.

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

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

With readOnlyHint already covering safety, the description adds substantial non-obvious behavior: the exact return envelope, truncation semantics ('do not read a short list as that is all there is'), and a filter-integrity guarantee ('a server that ignores the filter is refused, not trusted'). This is context an agent cannot get from 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?

Front-loads the resource and ordering, then the return shape, then the critical truncation warning, then args. Every block earns its place; the enabled-by-default output envelope is justified by the absence of an output schema.

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 supplies the return shape and truncation semantics itself, and it fully documents the three undocumented parameters including default target behavior. Nothing needed to call it correctly is missing.

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

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

Schema coverage is 0% (only titles/defaults), so the description carries the load and documents all three: backup_id purpose and source, limit range 1-1000 with default, and target as a named config with a default fallback. The 1-1000 bound is not in the schema at all.

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

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

States a specific verb+resource (list newest restore points) and enumerates the returned fields (id, name, creationTime, type) plus ordering. It does not explicitly contrast itself with a sibling restore tool, but none exists in the sibling list, so an agent can identify it easily.

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

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

Gives explicit operating guidance: when truncated=true, raise limit or filter by backup_id; and it points to backup_list for obtaining backup ids. It lacks an explicit when-to-use vs. a named alternative, but there is no competing restore-point 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?

readOnlyHint=true already declares this as a safe read, so the "[READ]" tag is largely redundant. The description does add that this is a polling tool for tracking progress over time, which is useful behavioral context, but it does not disclose return format or pagination 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?

Front-loads the read tag and purpose, then usage guidance, then an Args block. The structure is clean and the content is tight, with mild redundancy between the [READ] tag and the readOnlyHint annotation.

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

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

For a simple two-parameter polling tool with no output schema, the description covers purpose, usage, and both parameters. The main omission is what the poll returns and whether the session can fail, but that is a minor gap given the tool's narrow 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?

Schema coverage is 0%, so the description must carry the burden, and it does document both parameters: session_id as a Veeam session id (pointing to session_list) and target as a Veeam target name from config. This meaningfully compensates for the empty 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?

States a specific verb (poll/get) and resource (one session by id) plus the intent (check job/restore progress). The singular "one session by id" cleanly distinguishes it from session_list, which the description also cross-references for id lookup.

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

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

Explicitly says to use it after job_start or start_vm_restore to follow the operation rather than re-issuing it, naming the relevant sibling operations. It gives clear triggering context but no explicit exclusion of alternatives such as session_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?

Annotations only supply readOnlyHint=true; the description goes further by documenting the return envelope keys, the ordering guarantee, and the meaning of truncated=true. This is real behavioral context that the annotation cannot carry, though it says nothing about auth, rate limits, or target-resolution failures.

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?

Front-loaded with a [READ] tag, then return shape, then args, in three tight blocks with no filler. Minor redundancy in 'newest sessions ... newest first' keeps it just short of ideal.

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 two-parameter read-only list with no output schema, the description supplies the return keys, truncation semantics, ordering, and parameter bounds — everything an agent needs to call and interpret it correctly.

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

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

Schema coverage is 0%, so the description carries the full burden and largely does: limit is bounded (1-1000, default 100) and target's origin and default behavior are explained. Both parameters get meaning beyond the bare integer/string types in 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?

States a specific verb and resource ('the newest sessions') plus the fields returned and the ordering ('newest first'), which separates it from single-session tools like session_get or session_log. It doesn't explicitly name a sibling, but the list scope is unambiguous.

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

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

No when-to-use or when-not-to-use guidance. The agent is not told to reach for session_get to inspect one session or session_log for logs, nor is any filtering/precondition context given. Usage is only implied by the list-shaped description.

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?

Beyond the readOnlyHint annotation it discloses the full return envelope ({records, returned, totalRecords, truncated}), the meaning of truncated=true vs null, the fact that the endpoint cannot be paged, and the correct inferential caveat. That is substantial behavioral context an agent cannot get from annotations or schema.

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?

Front-loaded with the [READ] marker and purpose, then the return contract, then the caveat, then args – a sensible ordering with little waste. The Args block partially duplicates schema field names, keeping it just below maximally tight.

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 fully specifies the return shape and truncation semantics, and the read-only safety profile is covered by annotations. Nothing needed to call it correctly or interpret its result is missing.

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

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

Schema description coverage is 0%, so the description carries the burden and does document both parameters: session_id as a Veeam session id with a pointer to session_list, and target as a Veeam target name from config. It adds provenance but no format/validation details, so a 4 rather than 5.

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 opens with a specific verb and resource: return the log records (events) of one session. The [READ] tag and the phrase 'log records (events)' cleanly separate this tool from sibling metadata readers like session_get or session_list, and it points to session_list for obtaining the session_id.

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

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

It gives a concrete usage scenario ('see why a session failed instead of re-running the job blind') and a caution about misinterpreting truncated results, plus a pointer to session_list for the id. It stops short of naming explicit alternatives such as session_get or job_failure_rca for broader diagnosis.

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 destructiveHint=true, readOnlyHint=false, idempotentHint=false, so the safety profile is covered. The description goes beyond them usefully by disclosing that stopping cancels the underlying operation and is irreversible without re-issuing from the originating job/restore.

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?

Front-loads the [WRITE] tag and the core action, then layers reversibility and arg notes with no filler sentences. The Args block largely restates what the schema titles already convey, which is mild 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 3-param mutation with annotations and no output schema, the description covers action, destructiveness, reversibility, and the dry-run escape hatch. Return value shape and any auth/target-selection requirements are the only notable omissions.

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 carries the full burden and does document all three parameters. session_id points to session_list as the source, dry_run explains the preview behavior, and target is identified as a name from config — terse but adequate compensation.

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

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

States a specific verb+resource ('Stop a running session') and clarifies the effect ('cancels the underlying operation'), plus tags it as [WRITE]. It does not explicitly contrast with the sibling job_stop, so an agent must infer the session-vs-job boundary 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?

Adds real consequence guidance ('No undo token — a stopped session must be re-issued via the originating job/restore') and the dry_run preview path, which is more than nothing. However, it never states when to use this instead of the adjacent job_stop/job_disable tools or what prerequisites exist.

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 destructive/non-idempotent/non-readonly, and the description adds far more: irreversibility with no undo token, overwrite-or-create semantics, async session polling, and two distinct refusal paths (VBR host name match, unreadable restore point) with an explicit caveat that the name check is a safety net, not a proof.

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?

Front-loaded with the write/irreversible warning and structured prose plus an Args block, so it is easy to scan. Slightly repetitive on the approval theme ("confirm with the user", "read the preview before approving", "not something to approve"), which costs a point.

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?

No output schema exists, but the description covers return-path behavior (async session, poll with session_list/session_get) and preview output content, plus all refusal conditions an agent must handle. Nothing needed to call it correctly is missing.

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

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

Schema description coverage is 0%, so the description carries the burden and does: restore_point_id points to restore_list_points, dry_run's preview resolves the opaque id to vmName/creation time, acknowledge_unresolved's risky meaning is spelled out, and target's from-config sourcing plus the no-target = restore-to-original behavior is explained.

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?

Opens with a specific verb+resource+source ("Start a VM restore from a restore point") and marks the operation class with [WRITE], which cleanly distinguishes it from read-side siblings like restore_list_points and the job_*/session_* tools.

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 dry_run=True for preview, when to set acknowledge_unresolved=True (only after user confirmation in the Veeam console), that the user must confirm before calling, and how to follow up via session_list/session_get. Alternatives and exclusions are all present.

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 destructive=true, idempotent=false, readOnly=false; the description adds that the inverse executes through its own governed tool and risk tier (audit behavior) and that tokens are single-use. Useful beyond the annotations, though it doesn't say what the inverse might mutate.

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 [WRITE][risk=medium] tag front-loads the mode and risk, and the body is tight. The Args block partially restates the schema titles, but each line adds semantics, so little is wasted.

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

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

No output schema, but the description explains the dispatch model, the dry-run preview path, and the one-time token constraint, which covers the essentials for a mutation tool. It could clarify failure behavior (e.g., applying an already-used token) to be fully complete.

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

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

Schema description coverage is 0%, so the description must carry the load, and it documents all three params: undo_id's source, dry_run's preview semantics, and target's pass-through role. The 'target' explanation ('when it accepts a target') is a bit thin but directionally complete.

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

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

States a specific verb ('apply') and resource ('a recorded undo') plus the mechanism (dispatching its inverse tool). This clearly distinguishes it from the sibling undo_list, which only enumerates tokens.

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

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

Gives concrete guidance: undo_id comes from undo_list or an _undo_id in a write result, use dry_run=True to preview, and a token can only be applied once. It stops short of saying when not to use it or when preview is mandatory, but the context is clear.

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 cover the read-only safety profile, and the description goes well beyond by documenting the return envelope, truncation behavior, and the effectVerified=False meaning ('the change it reverses is PROBABLE, not confirmed'). This is rich behavioral context an agent needs to avoid false restore claims.

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?

Front-loaded correctly with [READ] and the core purpose, but it is long and includes design rationale that doesn't serve the caller, e.g. the aside about a 'smaller local model ... tends to report that it has seen every token' and the 'one extra row is requested' justification. Useful signal is diluted by internal commentary.

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?

There is no output schema, so the description must carry the return format, and it does (the undos/returned/limit/truncated envelope plus effectVerified semantics). Both parameters are addressed and the read-only nature is asserted, leaving nothing an agent needs before calling.

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 must compensate, and it does: limit is documented with a default and a 500 cap not present in the schema, and target is explicitly called out as unused. Both params get meaning beyond the bare types, though the 'Args:' docstring block is a slightly awkward vehicle.

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

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

States a specific verb (List) and resource (undo tokens) with scope ('recorded, not-yet-applied') and ordering ('most recent first'). It explicitly routes to the sibling undo_apply, letting an agent distinguish it from that tool without opening either schema.

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

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

Tells the agent to take the undoId and use undo_apply, and gives a specific precautionary condition (effectVerified=False means check live state before applying and don't claim a restore). Clear context, though there is no explicit 'when not to use' or prerequisite beyond this.

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