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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is largely covered. The description nonetheless adds real behavioral value by disclosing the return shape: each collection's level tree ordered top-first, its address, and both total and published page counts — details an agent needs to decide whether this call answers its question. It stops short of covering result size or pagination.

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 short and information-dense, but it is written as clipped sentence fragments rather than front-loaded prose, and the essential verb ('lists') never appears — the agent must infer it from the title. The dash-heavy aside defining a collection interrupts the flow more than it needs to.

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

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

There is no output schema, so the description must carry the return shape, and it does so with reasonable specificity (levels, address, page counts, published counts). For a one-parameter read tool this is close to complete; only volume/pagination expectations are missing.

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

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

With a single parameter at 100% schema coverage, the schema already explains that 'site' is named the way list_sites names it. The description only echoes this ('named in site', 'On one site of the account') without adding format, accepted aliases, or failure behavior for an unknown site. Baseline 3 is appropriate.

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 conveys the specific resource (every collection on one site) and even defines what a collection is — a tree of pages, each level addressable — and names the sibling get_collection for single-collection retrieval. The opener is a dangling prepositional phrase ('On one site of the account, named in site') rather than a verb+resource statement, which slightly blunts the first impression.

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?

'get_collection gives one's tree' implicitly routes the agent to the singular sibling when only one collection is needed, which is useful. However there is no explicit when-to-use framing, no note on scale (how many collections, whether this is expensive), and no mention of related siblings like create_collection or list_site_pages that an agent might confuse with it.

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