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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description still adds real value by enumerating what gets read back (profile, agent count, call volume) and by disclosing a behavioral detail annotations cannot capture: the response may contain a `next_step` pointer to a setup tool.

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?

Three short sentences, front-loaded with what the tool returns before explaining the diagnostic purpose and the forward path. Slightly indirect phrasing ('This shows whether a business number that answers missed calls already exists') costs a little, 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?

Output schema exists and annotations cover the safety profile, so the description needn't explain return values — and it still previews the main fields. With one fully documented optional param, an agent has enough to call this correctly; only the comparison against granular siblings is left implicit.

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 100% and the single optional `business_id` parameter is documented in the schema with its default-to-first-accessible-business behavior. The description says nothing about the parameter, so baseline 3 applies — the structured field carries this dimension entirely.

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?

States a specific verb and resource bundle: reads back profile details, agent count, and recent call volume for a business. That scope distinguishes it from single-purpose siblings like list_agents or get_analytics, though the description never names those alternatives to make the contrast explicit.

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 a concrete decision context — use it to determine whether a business number that answers missed calls already exists — and routes the agent forward when that condition fails via the `next_step` field. It stops short of stating when to prefer this over the granular siblings, so no exclusions are offered.

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