Lists Acronis protection policies (protection plans) with pagination, search, and filters by type, tenant, OS, status, and applicability so you can find and inspect the right policies.
Lists protection policies (called protection plans in the Acronis console).
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Query parameters |
Changes observed during successful MCP inspections.
v0.0.0-semantically-releasedDoes 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.