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

With no annotations, the description carries the full behavioral burden. It discloses the HTTP verb (GET) and some return fields (path, path_tr, edges, raw transfers), but omits auth/permission requirements, error behavior, and pagination. The repeated 'Idle $0' hint at a cost model but is cryptic and unexplained.

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?

The description is cluttered with marketing filler ('moat', 'Compounding asset', 'Idle $0' repeated twice, 'No DID sales / no live PSTN'). The useful content (endpoint, return fields) is buried and not front-loaded cleanly.

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 tool with no output schema and no annotations, the description should compensate more. It lists some return fields and the endpoint, but leaves auth, error handling, and usage context unexplained, and the surrounding jargon reduces clarity for an agent trying to invoke it correctly.

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%, so both parameters are already documented in the schema. The embedded example 'stuck_at=310' gives a minor format hint (an extension number), but the description largely repeats rather than extends the schema, matching the baseline 3.

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 conveys that this returns a call handoff/transfer graph ('who→whom→where the promise stuck'), which is a specific resource. However, jargon like 'moat' and 'promise stuck' obscure the purpose, and sibling differentiation is weak — it only vaguely contrasts itself with 'a bot transcript' rather than naming the closer sibling pbx_calls_get.

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?

There is no explicit when-to-use or when-not-to-use guidance relative to alternatives. The phrase 'Compounding asset for search/orchestration' hints at context but doesn't tell an agent when to call this versus pbx_calls_get or pbx_search. 'No DID sales / no live PSTN' is irrelevant to tool selection.

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