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

readOnlyHint=true already tells the agent this is a safe read. The description adds useful domain context — caller IDs carry an approval state that gates broadcasts — which is not in the annotations. It says nothing about ordering, whether unapproved IDs are included, or pagination behavior beyond what the schema states.

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?

Two short sentences, zero filler, with the resource scope front-loaded and the returned fields in a compact parenthetical. Every clause carries 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 no output schema, the description compensates by naming the four returned fields, and paging is covered by the schema. Minor gaps remain (does the list include unapproved IDs, what is the default ordering) but an agent can call this correctly as written.

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%: limit and start are fully documented, including the next_start paging convention. The description adds no parameter meaning and does not need to, so the baseline 3 applies.

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?

Names a specific verb (List) and resource (caller ID phone numbers on the account) and even enumerates the fields returned (id, name, phone, approved). It is unmistakable against siblings like list_contacts or list_groups because the resource noun is unique, though it never explicitly contrasts with them.

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?

"A call broadcast needs an approved caller ID" gives the agent a concrete reason to call this before dialmycalls_send_call, which is real when-to-use context. It stops short of exclusions or of naming send_call as the downstream consumer, so it is clear context without full routing guidance.

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