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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral facts: latency ('takes a few seconds'), higher compute cost than the read tools, the 90-day data window, and that the answer is grounded in the account's own data. It stops short of describing answer length or any rate/cost limits, so it is strong but not exhaustive.

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 sentences, front-loaded with the core purpose before examples and routing. The examples and the alternatives list both earn their place, though the sentence enumerating three sibling tools is dense; slightly tighter phrasing would read better without losing 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?

No output schema exists, yet the description explains the return value ('a written answer grounded in the account's own data'), which is what an agent otherwise would not know. Combined with cost, latency, data scope, and sibling routing, nothing needed to invoke this tool correctly 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?

With a single parameter at 100% schema coverage, the baseline is 3, but the description adds real meaning beyond the schema by giving example question shapes ('Should we worry about Acme's new pricing?', 'What is our biggest exposure right now?') that convey the intended granularity and framing. It does not restate the 3–1000 character bounds, which is fine since the schema handles those.

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 ('ask a free-form question about the competitors this account tracks') and immediately scopes the answer source: the account's positioning, ICP, and the last 90 days of scored signals. It also names the sibling tools it is not (get_briefing, get_competitor, get_momentum), so an agent can distinguish it without opening any 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?

Explicitly routes each common intent to the cheaper alternative: get_briefing for catch-up, get_competitor for a single competitor, get_momentum for comparisons. It then states the exclusion condition that selects this tool — judgment calls the read tools don't answer directly — which is exactly the when/when-not guidance an agent needs.

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