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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), and the description layers on genuine output behavior: ties are reported as ties rather than resolved, budget is reported as a range derived from supplied ACVs, and sector notes are conditional on supported sector inputs. That is real disclosure about how results are produced, though return format/pagination remains unstated.

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?

Purpose is front-loaded in the first sentence, with a second sentence of caveats of genuine value. Slightly dense packing of three behaviors into one sentence, but no filler.

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 read-only analysis tool with no output schema and all-optional parameters, the description covers what the analysis returns (patterns per dimension, tie handling, ACV-range budget, sector notes) and notes that business_model can be inferred from other inputs. Good enough that an agent could call it correctly; only the output shape stays unspecified.

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%, so the baseline is 3. The description adds interpretive meaning beyond the schema — that 'budget' means the ACV range observed in your customers, and sector notes appear only for inputs naming a supported sector — but it doesn't clarify most individual parameters.

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 (Analyze) plus resource (customer data) and an enumerated list of the ICP dimensions it detects (industry, size, deal size, sales cycle, tech stack, triggers, champion roles). That distinguishes it reasonably from siblings like icp_gap_analysis or icp_scoring_model, though it never names which sibling to prefer.

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?

Usage is only implied: you feed it customer data and it surfaces ICP patterns, with 'customer_descriptions' as an alternative input mode. There is no explicit when-to-use/when-not guidance and with eight ICP-related siblings, the agent gets no routing help.

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