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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds one piece of behavior beyond that by disclosing a second return field, the last modification time, but says nothing about scope (tenant-wide vs current user), freshness, or cost of the call, leaving the meaningful gaps unfilled.

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

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

A single short sentence that front-loads the primary return value and appends the secondary one. Nothing is wasted, though the terseness contributes to the missing scope information.

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

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

For a zero-parameter, read-only counter with no output schema, the description conveys what comes back, which is the minimum an agent needs. What is missing is the scope of the count and how it relates to the several near-identical counting siblings, and with no output schema the return shape is only partly described.

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 tool takes zero parameters, so there is no parameter semantics to explain; the baseline of 4 applies. The description does not need to say anything more about inputs and doesn't confuse the reader with any.

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

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

The description names a specific verb and resource ('Returns count of active alerts') plus a secondary return field ('last modification time'), so the purpose is decipherable. But among siblings like acronis_fetch_alert_counters, acronis_fetch_alert_counts_per_customer, and acronis_fetch_all_alerts, nothing here explains what scope of alerts this count covers or why it is distinct from the counters 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?

There is no when-to-use guidance, no mention of alternatives, and no stated preconditions or scope. An agent has to guess whether this is the right tool versus acronis_fetch_alert_counters or acronis_fetch_all_alerts.

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=true, so the safety profile is covered, but the description adds nothing further — no note on behavior for an unknown ID (error vs empty), no indication of what the returned agent object contains, and no mention of required permissions. For a read-by-ID tool this is behaviorally thin.

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

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

A single short sentence with the verb and selector front-loaded and zero filler. It is appropriately sized for a one-parameter lookup, with no redundant or wasted clauses.

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

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

The tool is simple, the sole parameter is documented in the schema, and annotations cover the read-only safety profile, so much of the burden is already met. However, with no output schema, the description gives no sense of the returned agent fields or failure behavior, leaving a meaningful gap for an agent deciding whether this call answers its question.

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

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

There is a single required parameter whose nested agent_id is fully documented in the schema at 100% coverage, so the baseline of 3 applies. The description adds only the phrase "by ID", which aligns with but does not extend the schema's "The registered agent 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 specific verb ("Gets") and resource ("Acronis agent") with a clear cardinality and selector ("one ... by ID"), which implicitly separates it from the list-style sibling acronis_fetch_agents. It does not name the sibling or explicitly contrast with it, so it stops short of full differentiation.

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, no mention of prerequisites such as needing a registered agent ID, and no reference to the alternative acronis_fetch_agents for listing or discovery. The only hint is the phrase "by ID", leaving the agent to infer that a known identifier is required.

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=true, so the description owes little on safety, but it adds essentially nothing beyond that — no mention of paged results, default unlimited return when limit is omitted, or the tenant-header fallback behavior that materially affects results. The single sentence carries no 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?

One front-loaded sentence with no filler or redundancy. It is not padded, though its brevity borders on under-specification rather than tightness.

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 16 nested filter/paging parameters, nested objects, no output schema, and many sibling fetch tools, the description is too thin — it omits result shape, pagination expectations, and how filters like online/unsupported interact with tenant scoping. An agent must read the whole schema to call this 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 100% and the nested query object documents filtering, paging, and ordering in detail, so the schema does all the work. The description mentions only the tenant scoping implicitly and adds no parameter meaning beyond the schema, warranting the baseline 3.

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?

Specific verb ('Lists') and resource ('Acronis agents') with scope ('installed on machines in a tenant'), so an agent can tell this is a listing tool. It does not explicitly contrast itself with the sibling 'acronis_fetch_agent' (singular), but the plural/list framing 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?

No when-to-use or when-not-to-use guidance. Nothing tells the agent to pick this over 'acronis_fetch_agent' for a single record, or over 'acronis_search', and no prerequisites (e.g., tenant context) are mentioned.

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=true, so the safety profile is covered, but the description adds nothing beyond that: it does not say whether dismissed alerts are excluded from the response by default, what fields come back, or what an invalid/unknown ID yields. For a single-record retrieval where the default visibility of dismissed alerts is a meaningful behavior, this is a real gap.

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

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

A single short sentence with the resource and lookup key front-loaded and no redundant wording. It is efficient, though the brevity borders on under-specification rather than true conciseness.

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?

This is a simple single-record fetch with a fully documented nested schema and no output schema, so it does not need extensive prose. Still, given many sibling alert tools, the definition would benefit from a sentence on when to use it and on default exclusion of dismissed alerts.

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

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

Schema description coverage is 100% and the UUID pattern plus the show_deleted description are already documented in the schema. The phrase "by ID" merely restates the required path parameter, adding no semantics beyond the structured fields, so the baseline of 3 applies.

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

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

The description names a specific verb and resource ("Fetches the information about the alert") and scopes it to a single record via "by ID," which distinguishes it in intent from acronis_fetch_all_alerts or acronis_fetch_alerts_grouped_by_scope. However, it never names those siblings explicitly, so the differentiation is left implicit.

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?

"By ID" implies the precondition that an alert ID is already known, which is some usage signal. But there is no statement of when to prefer this over acronis_fetch_all_alerts or acronis_search, and no mention of what happens if the ID is unknown or the alert is dismissed.

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 description needed to add context about what is counted, scope, or filtering behavior. Instead it adds nothing beyond restating that grouping is possible, which the schema documents in far more detail. No mention of what the counters represent or how aggregation changes the result shape.

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

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

A single short sentence with the action front-loaded and no filler. It is efficient, though its brevity borders on under-specification rather than genuine tightness.

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

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

The tool is a simple read with annotations covering safety and a fully documented schema, so the description does not need to explain parameters or return values. However, given the many adjacent alert-counting siblings, the missing scoping and differentiation leaves the definition only minimally 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?

Schema description coverage is 100% and the nested query object fully documents embed_types, embed_tenants, embed_categories, embed_severities, including mutual exclusivity. The description's "grouped by optional parameters" adds no meaning beyond that, so the baseline of 3 applies.

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

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

The description states a verb and resource ("Fetches the alert counters"), which is better than a tautology, but the scope is vague: it never says whose counters, over what time window, or how it differs from siblings such as acronis_fetch_active_alert_count or acronis_fetch_alert_counts_per_customer. An agent cannot confidently choose it over those siblings from this text alone.

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 and no mention of alternatives, despite several closely related counting tools in the sibling list. The only guidance-like phrase, "may be grouped by optional parameters," describes a schema detail rather than a usage condition.

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 tells the agent this is a safe read, so the description owes context beyond that — and supplies none: no indication of the response shape (customer-id → count mapping?), whether zero-count customers appear, whether the rich alert filters in the schema actually affect the counts, or any pagination/limit 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?

A single short sentence with no wasted words, but it is under-specified rather than efficient — there is no front-loaded detail an agent could act on beyond the tool name. Brevity here reflects a thin definition, not disciplined editing.

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

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

The tool takes a nested query object with ~17 filter fields and has no output schema, so the description must explain what comes back and how filters affect the grouping — it does neither. For an aggregation tool surrounded by look-alike siblings, this leaves an agent unable to predict results or choose 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 100%, with the nested `query` object's fields documented in detail, so the schema carries the parameter burden and the baseline of 3 applies. The description adds nothing about how those filters interact with the per-customer aggregation, which is the one piece of semantics the schema cannot express.

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?

"Fetches count of alerts per customer" states a specific verb (fetch), resource (alerts) and aggregation scope (count per customer), which is clearer than a bare name restatement. It does not, however, distinguish itself from close siblings such as acronis_fetch_alert_counters, acronis_fetch_active_alert_count, or acronis_fetch_alerts_grouped_per_customer, which sound like near-duplicates of the same aggregation.

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

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

There is no guidance on when to choose this tool over the several sibling aggregation tools (alert counters, active alert count, alerts grouped per customer, alerts grouped by scope). No prerequisites, no mention of whether it supports filtering or which tenant scope it assumes.

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 that this is a safe read, so the description's job is to add behavioral detail. It does contribute the important aggregation semantics: one alert per group, selected as the most recent among the most severe, which is real behavior beyond the annotations. It omits pagination limits, result-size caps, and ordering of the returned groups.

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

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

A single front-loaded sentence with no filler, and the grouping behavior is stated up front. It is slightly dense and the nested superlative construction takes a moment to parse, but 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 read-only aggregation tool with a fully documented nested schema and no output schema, the description should still say what a group looks like and how many alerts are returned per group. It implies one alert per group but leaves the response shape and any result caps entirely unspecified.

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

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

Schema description coverage is 100%, and the nested query object documents scope_key and scope_value in detail, including the or() operator for grouping multiple values. The description adds no parameter-level information beyond 'the scope you choose', so the baseline 3 is appropriate when the schema carries the explanation.

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

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

The description names a specific verb 'Gets' and a resource 'alerts', and it distinguishes the variant by its aggregation behavior: one representative alert per group chosen by scope. That implicitly separates it from acronis_fetch_all_alerts and acronis_fetch_alerts_grouped_per_customer, though it never names those siblings directly. The phrase 'most recent of the most severe' is slightly awkward but still conveys the selection rule.

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 explicit when-to-use guidance, no stated prerequisites, and no named alternatives. The only usage signal is the phrase 'the scope you choose', which hints that the caller selects a grouping key but does not clarify when this tool is preferable to acronis_fetch_all_alerts, acronis_fetch_alert_counters, or acronis_fetch_resources_with_top_severity_alerts.

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=true, so the safe-read profile is covered and the description owes no contradiction. It adds no behavioral context whatsoever though: nothing about how alerts are grouped or ordered in the response, how many customers can be passed at once, or how dismissed alerts behave by default despite show_deleted flags existing.

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

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

A single short sentence with no wasted words, but its brevity comes at the cost of meaning rather than from efficiency. It is front-loaded with the verb but never gets to the grouping behavior that the name promises.

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

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

The tool takes a nested query object with roughly eighteen filter fields, has no output schema, and returns customer-grouped results, yet the description explains neither the grouping shape nor defaults. For a tool of this complexity, one sentence that echoes the name is not enough for an agent to call it confidently.

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

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

Schema description coverage is 100% and the nested query object documents all filters (id, type, severity, created_at operators, show_deleted, etc.), so the schema carries the semantics. The description contributes nothing about the required customer_id array being the grouping key, so baseline 3 applies.

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

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

States the verb and resource ("Fetches alerts") and the scoping ("of the specified customers"), but omits the defining trait in the tool name: that results are grouped per customer. Siblings like acronis_fetch_all_alerts, acronis_fetch_alerts_grouped_by_scope, and acronis_fetch_alert_counts_per_customer are not distinguished, so the agent cannot tell from the text what makes this fetch different.

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 guidance and no named alternative. The agent is not told to prefer this over acronis_fetch_all_alerts when a per-customer breakdown is needed, nor when the other grouped-scope tool is more appropriate. Only implicit usage can be inferred from the tool 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?

Annotations already declare readOnlyHint=true, so the safety profile is covered externally, but the description adds essentially no behavioral context of its own: no default result size or pagination behavior (despite a limit parameter), no indication of how dismissed/deleted alerts are treated by default, and no sense of result volume. The claim 'all alerts' sits slightly awkwardly with an available limit filter.

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 single sentence is front-loaded and free of padding, but for a tool wrapping a nested object with roughly twenty filter fields it is trimmed past the point of usefulness. Concise, yes; adequately sized for the complexity, no.

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 could reasonably say something about what a fetch returns, and the dense nested filter schema plus a large family of alert-related siblings makes the one-liner thin. Because the input schema is fully self-documenting, the agent can still call the tool correctly, which keeps this from dropping lower.

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

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

Schema description coverage is 100% and the nested query object documents every filter in detail, so the schema carries the parameter semantics. The description only characterizes the entire parameter set as 'optional filtering parameters', which adds no meaning beyond the structured field documentation — baseline 3 applies.

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

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

The description names a specific verb and resource ('Fetches all alerts') and adds the qualifying scope ('by optional filtering parameters'), so an agent knows this is the unfiltered-or-filtered bulk list endpoint. It does not differentiate itself from close siblings such as acronis_fetch_alert, acronis_fetch_alert_counters, or acronis_fetch_alerts_grouped_by_scope, which is the main remaining 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?

There is no when-to-use or when-not-to-use guidance and no named alternative. The word 'optional' implies filters can be omitted, but nothing tells the agent when to prefer this over the single-alert or grouped-alert siblings, leaving selection to inference from names alone.

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 description is not the sole behavioral source. Yet the single sentence adds nothing beyond the name: no indication of whether results are paginated, whether the list is static/tenant-scoped, or how the nested query filters interact with the claim of fetching 'all' types.

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 short, front-loaded sentence with no filler. It is efficient, though its brevity is closer to under-specification than to disciplined concision.

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

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

The rich nested query schema and the readOnlyHint carry most of the load, so an agent can call this correctly. Still, the description never acknowledges that the 'all alert types' result set can be filtered by OS and category, leaving a mild mismatch between the stated scope and the actual capability.

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

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

Schema description coverage is 100%, with the nested order, os_type, and category fields fully documented including operators and examples. The description adds no parameter meaning of its own, which is acceptable at full coverage but is baseline-level value.

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 gives a specific verb and resource ('Fetches all registered alert types'), which is clearer than the title-less name alone. It does not, however, distinguish itself from look-alike siblings such as acronis_fetch_categories or acronis_fetch_all_alerts, so an agent must infer the difference.

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, no mention of prerequisites, and no pointer to alternatives. With siblings like acronis_fetch_categories and acronis_fetch_alert_counters in the same namespace, the description should state whether this is the lookup used to resolve category/os_type filter values.

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, so the description's only job is added context — and it supplies none. It does not say what grouping dimension is used, whether counts are aggregated across all policies or only filtered ones, or how the links_and_issues query option affects results.

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

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

A single eight-word sentence with zero padding and the key concept front-loaded. It is efficient, but for a tool with a nested query object and aggregation semantics it is arguably undersized rather than appropriately sized.

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, the parameters are nested, and the tool performs aggregation, yet the description never explains the shape of the returned statistics or what counts as an issue. An agent can guess it is a read-only count query but not what it will receive.

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

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

Schema description coverage is 100% and the nested query object documents policy_id, context_id, and links_and_issues in detail, so the baseline of 3 applies. The description adds no filtering semantics of its own, leaving all parameter meaning to the schema.

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

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

The description names a verb ("counts") and a resource ("problems with applied policies"), which is more than a tautology. But "problems" and "grouped by issue" are never defined, so an agent cannot tell what an issue is or how this differs from siblings like acronis_fetch_application_statuses_by_policy or acronis_fetch_policy_applications.

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, no prerequisites, and no mention of any alternative tool. The agent must infer from the name alone that this is an aggregation view rather than a listing of application results.

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 supply readOnlyHint=true, so the safety profile is covered. Beyond that, the description adds nothing: it does not mention that results are paginated (the schema's before/after/limit cursors imply it), that statuses can be filtered or aggregated, or how large the result set may be. With annotations present, the bar is lower, but this one-sentence description still leaves behavior undisclosed.

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

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

A single, front-loaded sentence with no wasted words. It is concise, though the economy comes at the cost of omitting usage and behavioral context rather than from disciplined structuring.

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

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

The tool is a read-only list query with no output schema and a richly documented but deep nested query object (19 sub-fields). Because output shape is not specified and no sibling routing is given, the description is only minimally sufficient; the schema carries most of the load.

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

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

Schema description coverage is 100%, so the nested query parameters (status filter, policy_id, parent_id, include_aggregate_status, include_validation_issues, pagination cursors) are documented in the schema itself. The description does not add meaning beyond that, which sets the baseline at 3. Its policy-scoping phrase does hint at how policy_id is used, but the schema already says that.

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

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

The description states a specific verb and resource: it 'gets the status of every resource a given policy is applied to'. However, it does not distinguish this tool from close siblings like acronis_fetch_policy_applications, acronis_fetch_policy, or acronis_fetch_resource_protection_status, all of which sound plausibly overlapping. The agent must infer the difference from names alone.

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 explicit when-to-use or when-not-to-use guidance, and no alternatives are named. The phrase 'every resource a given policy is applied to' implies a policy-scoped fan-out query, but nothing tells the agent when to prefer this over fetching policy applications or per-resource protection status.

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=true, so safety is covered. The description adds almost nothing beyond that, and its "turned on" framing actually understates the tool's behavior since the schema exposes an include_disabled option — a conflict the description never reconciles.

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

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

A single short sentence with no wasted words, which is good, but the brevity tips into under-specification rather than tightness — there is no return-shape or scoping detail to anchor it.

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 at least indicate what a "category" contains (id, name, enabled flag) for the agent to use the result, and it does not. Combined with the missing sibling differentiation, it leaves real gaps for a tool sitting among 30+ alert/tenant siblings.

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

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

Schema description coverage is 100%, so include_disabled is already fully documented with its effect. The description does not mention the parameter at all, and its "turned on" wording slightly contradicts the option to include disabled categories, so it adds no 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 gives a verb and resource ("Lists the alert categories") plus a scope qualifier ("turned on"), so the basic operation is inferable. However, it never distinguishes itself from the near-identical sibling acronis_fetch_all_alert_types, and the phrase "turned on" is ambiguous about whether it means enabled categories or categories with active alerts.

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

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

There is no guidance on when to call this versus acronis_fetch_all_alert_types or the other alert-related siblings, and no stated prerequisites or exclusions. The agent must infer the distinction from the tool name alone.

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 that this is a safe read, so the description's only remaining duty is to add context, and it adds essentially none: no mention of what fields are returned, whether results depend on the caller's token scope, or how failures (expired/invalid credentials) surface. With no output schema, this gap matters more, not less.

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

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

A single front-loaded sentence with no filler or redundant restatement of the tool name. It is as short as it can be while still naming the verb, resource, and scope.

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

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

The tool is simple (no parameters, read-only), which lowers the burden, but with no output schema an agent still cannot tell what information comes back or in what shape. Adding one clause about the returned profile/permissions fields would make this 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 tool takes zero parameters and the schema is an empty object, so there is no parameter meaning to convey; the baseline for a 0-param tool is 4. The description correctly implies the user identity comes from the authenticated context rather than an argument.

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

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

The description states a specific verb and resource ("Fetches information about the currently authenticated user"), and the "currently authenticated" qualifier implicitly separates it from the id-based acronis_fetch_user and acronis_fetch_tenant_users siblings. It stops short of explicitly naming that distinction, so the differentiation is inferable rather than stated.

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

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

Usage is implied by the phrase "currently authenticated user" — an agent can infer this is for self-context lookups rather than looking up arbitrary users. However, there is no explicit when-to-use statement, no exclusion of acronis_fetch_user, and no mention of prerequisites such as needing an established session.

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=true, so the safety profile is covered by structured data. The description adds nothing beyond that: it never discloses that activities, detections, and response actions are excluded by default and only included via query flags, which materially changes what an agent gets back. With no output schema, this omission matters.

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

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

A single front-loaded sentence with no filler or ambiguity. It is well formed, though its brevity leaves useful context unstated rather than being maximally informative.

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?

This is a nested-schema fetch with eight optional query parameters that control response composition, and there is no output schema. The description never explains those inclusion flags or the tenant/customer scoping requirement, so an agent must read the schema to avoid getting a stripped-down incident object.

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

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

Schema description coverage is 100%, so every parameter (incident_id, customer_id, updated_since, with_activities, with_detections, with_incident_actions, etc.) is documented in the schema itself. The description adds no meaning beyond the schema, but the baseline of 3 applies when the schema does the heavy lifting.

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 ("Gets") and resource ("details of one EDR security incident") and distinguishes the singular fetch from the sibling list tool acronis_fetch_incidents by emphasizing "one ... by ID." It does not name the sibling explicitly, but the singular/plural contrast makes the purpose clear.

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

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

The phrase "by ID" implies usage (you must already have an incident ID), which is a reasonable implicit signal. However, there is no explicit guidance on when to use this versus acronis_fetch_incidents or acronis_search, and no mention of what to do if the ID is unknown.

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 establishes this is a safe read. The description adds essentially no behavioral context beyond that: no mention of pagination via cursor, the default tenant scoping from the auth token, result limits, or what a listing returns. For an EDR investigation endpoint, that is thin.

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

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

A single front-loaded sentence with zero redundancy. It is efficient, though its brevity borders on under-specification rather than tightness.

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

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

The rich, fully described nested query schema carries most of the burden, so the agent can construct calls. However, for a heavily filterable list endpoint with a singular sibling, the description leaves the selection and pagination story implicit, which is a real gap even if a modest one.

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

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

Schema description coverage is 100%, so every filter (state, severity, verdict, created_at range operators, customer_id scoping, cursor stability rules) is already documented in the schema. The description only says filters are 'optional' and does not explain the operator syntax or the tenant-scoping behavior, so baseline 3 applies.

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

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

The description gives a specific verb ('Lists') and resource ('EDR security incidents') plus the scope note that filters are optional. The plural 'Lists' implicitly contrasts with the singular acronis_fetch_incident sibling, but the description never explicitly names that distinction, so it falls short of a 5.

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

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

Beyond 'with optional filters' there is no when-to-use guidance: nothing says when to choose this over acronis_fetch_incident, acronis_fetch_all_alerts, or acronis_search, and no exclusions or prerequisites are stated. The agent must infer the routing from the tool name alone.

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=true annotation already tells the agent this is a safe read, so the description carries a lower burden, but it still adds essentially no behavioral context beyond the console terminology mapping. It says nothing about pagination being cursor-based (after/before with limit), about defaults such as templates/temporaries being excluded unless flagged, or about the 100-item filter caps that materially affect how the call must be built.

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

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

A single front-loaded sentence with no filler, and the parenthetical terminology mapping earns its place. It is arguably under-sized for a tool with 20+ nested filters, but that is a completeness issue rather than verbosity.

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 tool whose entire behavior is filter selection, the fully documented schema plus the readOnlyHint annotation covers most of what an agent needs. However, with no output schema the description should say at least roughly what a listed policy contains or how paging terminates, and it offers nothing about the heavy mutual-exclusivity surface that governs correct invocation.

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

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

Schema description coverage is 100% across the nested query object, so the baseline of 3 applies; every filter including the SQL-like search syntax, enum values for os_type, and mutual-exclusion notes is documented in the schema itself. The description contributes no additional parameter meaning, but it does not need to.

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 ("Lists protection policies") and helpfully maps the term to the console name "protection plans", which resolves vocabulary mismatch for the agent. It does not distinguish itself from siblings like acronis_fetch_policy (single policy) or acronis_fetch_policy_applications, so an agent must infer the listing-vs-detail split from names alone.

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 guidance is given: nothing says when to call this versus acronis_fetch_policy, when to narrow with policy_id versus tenant_id, or that this is the entry point for enumerating policies before drilling into one. The mutual-exclusivity rules between os_type, applicable_to_context_id and include_applied_context exist only in the schema, not in the 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?

Annotations already declare readOnlyHint=true, so the safety profile is covered and the description need not restate it. The description adds that the policy's settings are part of the result, though this is slightly imprecise since settings depend on the include_settings query flag, and it says nothing about the composite-policy expansion behavior controlled by full_composite.

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

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

A single short sentence with the verb and scope front-loaded and no filler. It is efficient, though arguably under-specified rather than optimally concise.

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 100% schema coverage and a readOnly annotation, most of the burden is carried by structured fields, and no output schema means return values need not be explained. However, the nested path/query structure and the composite-policy semantics are non-trivial, and the one-line description gives an agent no orientation on them.

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

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

Schema coverage is 100%, so all four query options (full_composite, include_settings, links_and_issues, include_applied_context) are already documented in the schema with descriptions. The description contributes only the notion of lookup 'by ID', which maps to the already-documented policy_id, so baseline 3 applies.

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

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

The description names a specific verb and resource ('Gets one protection policy') and scopes it to a single item 'by ID', which implicitly distinguishes it from the sibling list tool acronis_fetch_policies. It does not explicitly name that sibling, so the differentiation is left to inference.

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

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

There is no guidance on when to choose this over acronis_fetch_policies or acronis_fetch_policy_applications, and no mention of prerequisites such as needing a valid policy_id. The only hint is the phrase 'by ID', which implies single-item lookup but is not framed as a usage 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?

readOnlyHint=true already tells the agent this is a safe read, and the description adds no behavior beyond that gloss. It says nothing about pagination defaults, whether soft-deleted or temporary applications appear by default (the schema exposes include_deleted and include_temporaries, so the defaults matter), or the potentially large result sets implied by a limit parameter.

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

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

A single front-loaded sentence with no filler, and the clarifying gloss is worth its space. It is slightly soft ('where policies are applied') when a firmer phrasing of the returned entity would be stronger.

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?

This is a complex tool with roughly 25 filter fields, nested objects, and no output schema, so the description must carry more weight than one sentence provides. It never describes what an 'application' record contains or how the many include_* flags shape the response, leaving the agent to reverse-engineer the payload from parameter names alone.

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

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

Schema description coverage is 100% and every nested query field carries its own explanation, so the schema does the heavy lifting. The description only echoes that filters are optional, adding no syntax, defaults, or interaction rules between filters (for example, how direct_only interacts with context_selection_id), so the baseline 3 is right.

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?

Names a specific verb ('Lists') and resource ('policy applications') and glosses the domain term as 'which resources each policy covers', which an agent could not infer from the name alone. It does not distinguish itself from close siblings such as acronis_fetch_policies or acronis_fetch_application_statuses_by_policy, so it stops short of a 5.

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

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

The only usage signal is 'with optional filters', which says nothing about when to reach for this tool versus acronis_fetch_policies, acronis_fetch_applications_issue_statistics, or acronis_fetch_application_statuses_by_policy. There are no exclusions, no prerequisites, and no indication of which filter combinations matter.

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=true, so safety is covered, but the description adds nothing beyond that. It does not mention that the optional query parameters can expand the payload with attributes or links, nor what happens for an unknown or malformed 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?

A single front-loaded sentence with no filler and the key identifying constraint (by ID) surfaced immediately. It is efficient, though its brevity is part of why other dimensions are thin.

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 could reasonably say what a single-resource fetch returns and why one might request embedded attributes or links. For a simple read-by-ID tool with fully documented parameters this is adequate, but the expansion options and error behavior are left unexplained.

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

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

Schema description coverage is 100%, so the nested path and query parameters, including the mutually exclusive include_attributes / include_attribute_namespaces pair, are documented in the schema itself. The description only echoes the ID requirement, adding no meaning beyond structured fields.

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

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

The description states a specific verb and resource ('Gets one resource ... by ID') and clarifies the resource scope with examples (machine, mailbox, other workload), which separates it from the plural acronis_fetch_resources. It does not explicitly name that sibling, so the differentiation is implicit rather than stated.

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: nothing says to call this when you already have an ID versus acronis_search or acronis_fetch_resources when you do not. The only usage signal is the phrase 'by ID', which an agent must infer as the selection condition.

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=true, so safety is covered; the description adds nothing further. It does not say whether the count includes deleted resources by default, whether counts respect tenant scoping, or what the returned count object looks like.

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

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

A single tight sentence with no wasted words, but its brevity comes at the cost of any routing or return-shape information.

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

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

This is a tool with a deeply nested 17-property filter object and no output schema, so the description should at minimum describe the return value (a count) and typical filter usage. It provides neither, leaving significant gaps for a tool of this 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 100% with detailed nested docs for all 17 filter fields, including mutual-exclusion notes. The description adds nothing beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Fetch a count of all resources') that distinguishes it from the plural listing sibling acronis_fetch_resources by emphasizing a count. However, it never explicitly contrasts with acronis_fetch_resources or acronis_search, leaving the agent to infer the count-vs-list distinction.

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 instead of acronis_fetch_resources or acronis_search, and no prerequisites or exclusions are stated. The only implied cue is 'match filter parameters', which the schema already supplies.

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=true, so the safety profile is covered. Beyond that, the description adds nothing: it does not define what 'protected' means (by policy, by plan, by agent), does not mention pagination despite cursor fields, and does not hint at the response shape.

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 with zero wasted words. It is efficient, though the terseness edges toward under-specification for a tool with a 16-field nested query object.

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 paginated, richly filterable resource-status query with no output schema, the description should at minimum define 'protected' and indicate the returned fields. Neither is present, leaving an agent to infer the tool's semantics from the name alone.

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

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

Schema description coverage is 100%, so the nested query object's fields are fully documented in the schema. The description adds no filtering or sorting meaning beyond that, which is acceptable but provides no extra value.

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 outcome for a specific resource: which resources are protected versus unprotected. The purpose is understandable, but it does not distinguish this tool from close siblings such as acronis_fetch_resources, acronis_fetch_resource, or acronis_fetch_resource_count, so an agent cannot tell from the description alone why it would pick this one.

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, no exclusions, and no named alternative. Given a sibling set containing several resource-listing tools, the description provides no routing signal at all.

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 description only needs to add context — and it adds little. It does not mention cursor-based pagination (after/before/limit exist in the schema), default page size, that deleted resources are excluded unless include_deleted is set, or any permission/tenant-scoping behavior. For a list endpoint with no output schema, these omissions leave real 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?

A single front-loaded sentence with zero padding and no filler. It is efficient, though for a tool with a ~20-property nested query object the sizing is on the thin side rather than optimally balanced.

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

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

The tool is complex (deep nested query object, many mutually exclusive filters, cursor pagination) and has no output schema, yet the description says nothing about what is returned or how paging works. Given only a readOnlyHint annotation, the description should carry more of the burden for a listing tool of this 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 100% and the nested query object documents each filter, including mutual-exclusion rules, so the schema carries the semantic load. The description only restates that filters are optional and adds no meaning about filter interaction or syntax beyond the schema's own documentation. Baseline 3 applies.

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

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

The description gives a specific verb and resource ("Lists resources") and clarifies the domain by naming examples (machines, mailboxes, other workloads), which is more than a tautology. However, it draws no boundary against close siblings such as acronis_fetch_resource (single item), acronis_fetch_resource_count, or acronis_fetch_agents, so the agent must infer that this is the general multi-resource listing call.

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?

"With optional filters" hints that this is a browse/filter operation, but there is no explicit when-to-use guidance, no when-not, and no mention of the alternatives in a sibling set of 33 tools that includes fetch_resource, fetch_resource_count, and fetch_resources_with_top_severity_alerts. The agent receives no routing signal for choosing this tool over those.

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, so the description should add context such as what "highest severity" means (per resource vs. globally), how many alerts per resource drive the selection, or what the response looks like. Instead it restates purpose in an ambiguous way and discloses no behavior beyond the annotation, and it has no output schema to fall back on.

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?

It is a single sentence with no filler, which is good, but the sentence is awkwardly recursive ("...alerts with the highest severity found for the resources") and forces re-reading. Brevity here comes at the cost of clarity rather than being a virtue.

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 and a nested query parameter, the description is the agent's only source for what actually comes back, and it fails to specify whether results are per-resource max-severity alerts or a global ranked list. Combined with the absence of any sibling differentiation, an agent lacks enough to invoke this confidently versus acronis_fetch_all_alerts.

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

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

Schema description coverage is 100%, and the nested query object documents both `id` (including the `or()` operator syntax) and `embed_alert`. The description contributes nothing about either parameter, so the baseline 3 applies — the schema is carrying the full parameter burden adequately.

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

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

The description names a verb ("fetches") and a resource ("resources' statuses") and adds a qualifier about alerts with the highest severity, so the intent is roughly graspable. However, the phrasing "the resources' statuses that contain the alerts with the highest severity found for the resources" is circular and leaves it unclear whether it returns resources, statuses, or alerts. It also does nothing to separate this tool from close siblings like acronis_fetch_resources, acronis_fetch_resource_protection_status, and acronis_fetch_all_alerts.

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 at all — no indication of when an agent should pick this over acronis_fetch_resources or acronis_fetch_all_alerts, and no mention of prerequisites or typical scenarios. The only implied usage is embedded in the purpose statement itself.

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 covers the safety profile, so the bar is lower. The description adds that the action was 'started on an incident', hinting at a prior initiation step, but says nothing about what statuses look like, whether polling is expected, or how long results persist.

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

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

A single sentence, front-loaded with the verb and resource, with the example earning its place by disambiguating 'response action'. No wasted wording, though it is thin enough that structure is not a differentiator.

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 should say something about the returned status values (e.g. pending/succeeded/failed) but does not. For a simple read tool with full schema coverage it is adequate, but the return semantics remain undefined.

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

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

Schema coverage is 100% and both required parameters (incident_id path param, activity_id query param) are documented in the schema. The description adds no meaning beyond that, so the baseline 3 applies; it notably does not emphasize that both IDs are needed to identify the action.

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 ('Gets the status of a response action') and adds a concrete example ('isolating a machine') that clarifies what a response action is. It is distinguishable from siblings like acronis_fetch_incident, though it never names an alternative 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?

Implies the use case: after starting a response action on an incident, poll this for its status. But it gives no explicit when-to-use conditions, prerequisites, or alternatives, and does not warn against using it for the incident itself.

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 tells the agent this is a non-destructive read, and the description adds nothing beyond that. It does not mention that deleted tenants are excluded by default (allow_deleted), nor that the call fails on an unknown or malformed UUID, which would be genuinely useful behavior 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?

A single short, front-loaded sentence with zero filler. It is efficient, though its brevity borders on under-specification for a tool with multiple siblings.

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 lookup with a fully documented schema and no output schema, the description is minimally sufficient to invoke correctly. It still leaves the agent without disambiguation from batch/related tenant tools and without any note on default exclusion of deleted tenants.

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

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

Schema description coverage is 100% — tenant_id's UUID format plus embed_path and allow_deleted are all documented inline. The description adds no meaning beyond the schema, so the baseline of 3 applies.

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

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

"Fetches a tenant by ID" names a specific verb and resource, so the basic purpose is unambiguous. However, it does nothing to distinguish this from siblings like acronis_fetch_tenants_batch, acronis_fetch_tenant_children, or acronis_fetch_tenant_usages, which an agent must differentiate on its own.

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

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

There is no when-to-use guidance at all — no statement about when to fetch a single tenant versus using the batch variant, and no prerequisites or exclusions. The agent must infer selection criteria from the name alone.

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=true, so safety is covered. The description still adds real behavioral information beyond that: the result is IDs only (not full tenant objects) and the scope is direct children only, not a recursive subtree — both material for how an agent plans follow-up calls.

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

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

A single short sentence that front-loads the verb and the key scoping word ('directly'), with no filler. Nothing is wasted and nothing essential is buried.

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, fully documented 2-parameter tool with no output schema, the description covers what the tool returns (IDs) and its depth scope. It stops short of noting pagination behavior, which the schema handles but which an agent would benefit from seeing up front.

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

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

Schema description coverage is 100%, including the tenant_id UUID pattern, the cursor semantics for 'after', ordering options, and allow_deleted. The description adds no parameter meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb ('Lists') and resource ('IDs of the tenants directly under a tenant'), plus a concrete example ('a partner's customers'). The word 'directly' implicitly distinguishes it from whole-subtree or single-tenant siblings like acronis_fetch_tenant, though no sibling is named 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?

Usage is implied by the hierarchy framing — call it when you need the immediate children of a known tenant. There is no explicit when-not guidance, no mention of alternatives such as acronis_fetch_tenants_batch for bulk lookups, and no note that results are paginated.

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 description's main job is to add context — but it only restates the data domain. It says nothing about whether results are tenant-wide or per-user, whether MFA enforcement policy is included, or whether an unconfigured tenant returns an empty versus error response.

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 compact sentence with the primary purpose front-loaded and no filler. It is slightly under-specified rather than verbose, which is the right failure mode for a short definition.

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 one-parameter read tool with readOnly annotated and full schema coverage, this is roughly adequate, but with no output schema the description should have sketched the shape of the response (per-user MFA flags vs. tenant-level status) and it does not.

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 100% schema description coverage and a single documented tenant_id (UUID, with pattern and length constraints), the schema fully carries parameter meaning. The description adds no extra semantics such as whether parent/child tenant IDs are accepted or whether the caller's own tenant can be implicit.

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

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

The description names a specific resource and attribute ('MFA status for tenant') plus a secondary data point ('progress of TOTP enablement by users'), which no sibling tool covers. It is clearly distinguishable from the tenant/user/alert tools, though the phrase 'progress of TOTP enablement' stays abstract about what is actually returned.

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, no stated prerequisites (e.g., needing a tenant administrator context), and no mention of alternatives among the many sibling fetch_tenant_* tools. The agent must infer usage entirely from 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?

Annotations already declare readOnlyHint=true, so the safety profile is covered; the description adds that multiple tenants are returned in one call and that subtree mode means 'everything under it'. It says nothing about pagination, result limits, deleted-tenant handling, or what fields come back, which the schema covers only indirectly.

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

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

A single front-loaded sentence with the core verb and resource first and no wasted preamble. The trailing phrase 'as a tenant and everything under it' is slightly awkward relative to the schema's subtree_root_id terminology.

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

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

A read-only query tool with no output schema and a deeply nested parameter object containing three mutually exclusive selectors plus cursor pagination. The description covers the selection modes but leaves out pagination behavior, the level-of-detail concept, and default scoping, so it is only minimally complete for this schema'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 100%, so the nested parameters are already fully documented, giving a baseline of 3. The description groups uuids, parent_id, and subtree_root_id into three modes, which lightly reinforces their mutual exclusivity but adds no format or constraint detail 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?

States a specific verb and resource ('Gets several tenants at once') and names the three selection modes (UUID batch, parent tenant, subtree). It does not differentiate itself from near-siblings such as acronis_fetch_tenant or acronis_fetch_tenant_children, whose scope overlaps with the parent_id and subtree_root_id modes.

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 sentence enumerates the mutually exclusive selection modes but gives no explicit when-to-use or when-not-to-use guidance, and never names an alternative tool. An agent facing both this tool and acronis_fetch_tenant_children has to infer the difference from the schemas.

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 description could have spent its words on real behavior: what the metrics cover, whether results are paginated, whether they are time-scoped, or what shape the response takes. It adds none of that beyond restating that data is fetched.

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 single sentence contains no filler and is front-loaded, but it is terse to the point of under-specification rather than genuinely tight writing. The sentence count is appropriate; the content is not.

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 is the only place an agent could learn what 'usage metrics' actually contain, and it says nothing. Combined with a nested parameter object and no usage guidance, the definition leaves the agent guessing at both the return content and selection criteria.

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

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

Schema description coverage is 100%, including the tenant_id UUID pattern and both query filters (editions, usage_names), so the schema carries parameter meaning fully. The description adds nothing beyond it, which is the baseline expectation at this coverage level.

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

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

The description names a verb ('fetches') and a resource ('common usage metrics of the tenant'), so the general intent is clear. However, 'common usage metrics' is undefined and there is no differentiation from nearby siblings such as acronis_fetch_tenant, acronis_fetch_tenant_users, or acronis_fetch_tenant_mfa_status, which an agent must distinguish when choosing a tenant-scoped fetch.

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, no mention of when not to use it, and no named alternative among the many tenant-scoped sibling tools. The agent must infer usage entirely from 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?

readOnlyHint=true already covers the safety profile, and the description adds the useful fact that only UUIDs come back rather than full user records. However, it says nothing about pagination, result limits, or how the nested-tenant and hidden/deleted flags affect output scope, which the schema only partially implies.

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

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

A single front-loaded sentence with no filler, and the key distinction (UUIDs only) is placed where it will be read. It is arguably too terse for the tool's scope, but 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?

The tool is a simple read with fully documented parameters and no output schema, so the description is close to sufficient. It still omits sibling differentiation and any notion of response size or pagination behavior, leaving gaps an agent would hit in practice.

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

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

Schema description coverage is 100%, including detailed descriptions for order, allow_deleted, include_hidden, and include_grand_children, so the baseline is 3. The description contributes no additional meaning about how tenant_id or the query flags shape the result.

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 ("Fetches a list of UUIDs of the tenant's users") and adds a meaningful qualifier: only UUIDs are returned, not full user objects. It does not distinguish itself from sibling tools such as acronis_fetch_user or acronis_fetch_users_batch, so an agent must infer the split.

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, no mention of when to prefer acronis_fetch_user / acronis_fetch_users_batch, and no prerequisites. The agent must infer that this is the lightweight bulk-ID lookup versus the detail-fetching siblings.

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=true, so the safety profile is covered. Beyond that, the description says nothing about the allow_deleted behavior, what happens with invalid or nonexistent IDs, or whether deleted users are returned by default – all of which matter for correct invocation.

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 single sentence is front-loaded and free of filler, but it is undersized for a tool with two parameters and several near-neighbor siblings. Being brief is fine, yet here brevity edges into under-specification rather than efficient signal.

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?

This is a simple read tool with full schema coverage, annotations covering safety, and no output schema to explain, so a short description is defensible. Still, the absence of any note on the allow_deleted flag's effect or on sibling disambiguation leaves the agent with gaps it must fill itself.

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

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

Schema description coverage is 100%, so both the user_id UUID and allow_deleted flag are already documented in the schema. The description adds no parameter meaning beyond the schema, which is acceptable at baseline 3 but offers no extra value.

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

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

The description states a specific verb and resource ('Fetches a user by ID'), which is clear and unambiguous. It does not differentiate from sibling tools such as acronis_fetch_users_batch, acronis_fetch_tenant_users, or acronis_fetch_current_user_info, so an agent must infer from the name which path to take.

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, no mention of alternatives (batch fetch, tenant users, current user), and no stated preconditions such as required ID format or permissions. The 'by ID' phrasing weakly implies a lookup, but nothing is explicit.

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=true, so the safety profile is covered elsewhere. The description adds nothing beyond that: no mention of the 100-UUID cap, mutual exclusivity between uuid and tenant filters, cursor pagination, or whether missing UUIDs cause errors rather than partial results.

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

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

A single front-loaded sentence with zero filler, which is structurally clean. However, brevity here is under-specification rather than economy - the sentence stops well short of the information the tool needs.

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?

This tool exposes 15 nested filter parameters, pagination cursors and mutually exclusive filter combinations, with no output schema. Given that complexity, one sentence is inadequate; an agent cannot tell how to pass multiple UUIDs, whether results are ordered, or how paging interacts with filters.

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

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

Schema description coverage is 100% across a deeply nested query object, so the schema carries the full parameter burden. The description adds no supplementary meaning, which is the baseline expectation when the schema is this well documented, but it misses the chance to highlight the uuids filter that motivates a batch call.

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?

"Gets details for several users at once" essentially restates the name acronis_fetch_users_batch - fetch users, batch. It never says what a "user" object contains or what distinguishes this from sibling acronis_fetch_user, other than the implicit plurality.

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 guidance at all. With siblings acronis_fetch_user, acronis_fetch_tenant_users and acronis_fetch_users_batch available, the description never indicates that batch retrieval by UUID list is the reason to pick this one, nor any exclusion 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?

The readOnlyHint annotation already establishes that this is a safe read operation. The description adds only the basic resource type and does not disclose search scope, whether deleted items may appear, result limits, or return shape beyond what the schema already says.

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

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

The description is a single front-loaded sentence with no filler or redundancy. It is perhaps too terse, but its structure is efficient and easy to parse.

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 search tool with a nested query object and no output schema, the description does not explain what results look like, whether tenants and users are returned together, or how the required tenant context inside query affects behavior. It is incomplete given 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 100%, and the nested query parameters are fully documented there, including text, tenant, limit, and allow_deleted. The description adds no parameter meaning beyond that baseline.

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

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

The description states a specific verb and resource: 'Searches for tenants and users.' This distinguishes it from the fetch_* siblings by implying text search rather than direct retrieval, but it does not explicitly name or contrast with acronis_fetch_tenant or acronis_fetch_user.

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

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

The description gives no guidance on when to use this search tool versus the many specific fetch tools for tenants and users. There are no exclusions, prerequisites, or alternative conditions mentioned.

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