list_subscriptions

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

With no annotations provided, the description carries the full behavioral burden and does so: it declares the operation read-only, states the RBAC requirement (no role beyond being able to see a subscription), explains what an empty result implies, and defines the `capped` truncation flag. This is exactly the beyond-schema context annotations would otherwise supply.

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 purpose is front-loaded in one clean sentence, followed by progressively finer behavioral detail in short blocks. The parenthetical ARM/RBAC aside and backtick formatting add usable precision, though the phrasing is slightly literary ('as ARM lists them') for an agent-facing description.

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 no-annotation, single-parameter, no-output-schema tool this covers the essentials: read-only nature, auth/RBAC expectations, empty-result meaning, and truncation signal. It stops short of describing the returned item shape beyond noting id and display name are usable as inputs.

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

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

Schema description coverage is 0% and the single `max_pages` parameter is entirely undocumented in the schema. The description alludes to a 'page budget' and a `capped` truncation flag, which lets an agent infer that paging is bounded, but it never names the parameter, its default (null), or what value would avoid truncation.

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 first sentence names the exact resource (Azure subscriptions), the scope (those this credential can see), and the underlying operation (`GET /subscriptions`, i.e. an ARM list). It further distinguishes itself from siblings by identifying itself as the discovery anchor for `vm_backup_status` and `vm_backup_policies`, so an agent can place it without opening any schema.

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

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

Explicitly states the when-to-use path: this is the source of subscription ids or display names that the two backup sibling tools accept. It also gives a diagnostic trigger — an empty list while `auth` works means no Reader role has been granted anywhere. Both an entry point and an alternative-selection rule are present.

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