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

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description discloses key behaviors: disabled destinations are included, secret access keys are omitted from item.data, and pagination works via next_page_start with a null cursor marking the end. These are non-obvious traits that materially affect how an agent consumes the 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?

Four sentences, each earning its place: purpose, security behavior, downstream usage of ids, and pagination. The most important scoping detail ('including disabled destinations') is front-loaded, and there is no repetition of schema or annotation 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?

With an output schema present, an explicit pagination contract, and annotation-provided safety profile, the description covers everything needed to invoke the tool correctly. The two optional parameters are fully documented in the schema, and the description clarifies the pagination flow and secret handling.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds a small nuance by stating that a null cursor marks the last page, reinforcing the schema's pagination guidance, but it does not meaningfully extend parameter meaning beyond what the schema already documents.

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

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

The description uses a specific verb ('Lists') and resource ('storage destinations'), with a clear scope ('the organization's') and an important differentiator ('including disabled destinations'). This cleanly distinguishes it from sibling tools like get_storage_destination, create_storage_destination, and the list tools for other resources.

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 makes the list operation's purpose obvious and adds context about including disabled destinations, which implies when this is the right tool. It also tells how to use returned ids in image or template requests. However, it does not explicitly contrast with alternatives like get_storage_destination for a single destination, so it stops short of a fully explicit when/when-not statement.

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