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

Annotations only cover the read-only safety profile, so the description carries the rest and does well: it discloses what comes back (configMode, WhatsApp routes, editable prompt) and, importantly, the non-obvious semantic that effectiveText is the WhatsApp LiveKit prompt while providerHostedEffectiveText is the unchanged provider-phone prompt. It stops short of mentioning permission or lookup-failure behavior.

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?

Front-loads the core action and ID provenance before the detail sentences, and every sentence carries real information. The middle section on prompt sources and appliesTo values is dense and could be trimmed since much of it is return-value detail, but nothing is padding.

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?

An output schema exists, so return values are technically already documented, yet the description still supplies the interpretive context (source=library|embedded|default, the effectiveText vs providerHostedEffectiveText distinction) that makes the output usable. ID provenance and sibling routing are both covered; only failure/error behavior is unaddressed.

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 coverage is 0% and the single assistantId parameter has no description in the schema. The description compensates by stating the ID must originate from list_inbound_assistants or list_whatsapp_accounts.callAgent, which is the key semantic an agent needs; it does not add type or format details.

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?

Specific verb+resource ('Get one inbound voice assistant') with the exact provenance of the identifier ('by an ID returned by list_inbound_assistants or list_whatsapp_accounts.callAgent'). It also distinguishes itself from the near-name sibling get_whatsapp_agent, so an agent can route without opening either schema.

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?

Gives explicit context for when the tool applies ('This is for calls; use get_whatsapp_agent for text chat') and tells the agent where a valid assistantId comes from. It lacks any when-not guidance such as behavior on an unknown ID, but the alternative route is clearly named.

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