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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower, but the description adds real interpretive context: assignment does not imply a successful inbound test or customer coverage, and forwarding is an optional customer route. That prevents a common misreading of the results, which is behavior beyond what structured fields convey.

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 short sentences, front-loaded with what the tool returns, followed by caveats and the alternative tool. No filler, though the forwarding sentence is somewhat tangential and could be trimmed without losing selection value.

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 one-parameter read-only list with an output schema, the description covers scope, the key interpretive caveat about assignment versus readiness, and routing to the sibling that answers readiness questions. Nothing essential for correct invocation is 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?

There is a single optional parameter with 100% schema description coverage ('Business ID to filter by (optional)'), so the schema already carries the semantics. The description does not clarify filtering behavior or defaults when business_id is omitted, so it adds nothing beyond the baseline.

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 opening sentence names a specific verb and resource ('List phone numbers') and scopes it to 'assigned to the accessible business(es), with capability and compliance flags', so an agent knows exactly what comes back. It also distinguishes itself from get_activation_status by flagging that assignment is not proof of readiness.

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?

It gives clear context and redirects for a specific adjacent need: 'get_activation_status reports current readiness and private-test proof' tells the agent which sibling to use when the question is about readiness rather than inventory. It stops short of an explicit 'use this when / do not use this when' statement for the list itself, so usage remains partly inferred.

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