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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's '[read]' tag is largely redundant. It does add value by naming the returned fields (assigned assistant, active flag), but says nothing about whether all numbers are returned or how pagination behaves, which the annotations cannot cover.

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 efficient, though the terseness is partly the cause of the missing pagination and return-shape detail.

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 listing tool with full annotation coverage and no output schema, the description covers the core return content. However, with 0% parameter coverage and no output schema, it should at least explain paging behavior and clarify that the listing is unfiltered (or how to filter).

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%, so the description must compensate for the two parameters (page, per_page) – and it does not mention them at all. Defaults of 1 and 50 are visible in the schema, but the description gives no hint about page size limits, iteration, or total counts.

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 the resource (phone numbers) and the two data points returned: the answering assistant and the on/off state. That distinguishes it reasonably well from siblings like list_voip_accounts or list_voip_calls, though it never explicitly names a sibling or uses a clear 'list all numbers' verb.

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 versus list_voip_assistants, list_voip_accounts, or list_voip_calls, and no prerequisites or exclusions. The agent must infer usage entirely from the tool name and the sibling list.

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