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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered; the description adds useful behavior beyond that by disclosing the return shape ('each company's tier and score, plus totals') and the 50-item cap, which matters for batching decisions. It does not say how companies with sparse fields are handled or what happens above the limit.

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?

Two sentences, no wasted clauses, and the usage trigger leads. The opening fragment 'Before outreach, choosing where to spend time:' is slightly clipped and awkward in isolation but does its routing job fast.

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?

With no output schema, the description correctly summarizes return values (tier, score, totals), and the single required parameter is fully specified by the schema. For a read-only scoring tool this is nearly sufficient; only edge-case behavior (missing inputs, overflow past 50) is unstated.

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% and every field of the nested company object is documented, so the baseline is high. The description adds a real constraint not encoded in the schema prose depth — the 'max 50' ceiling — though it repeats the same limit already present on the array's own description.

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 ('score or rank [companies] against their ICP') and quantifies batch scope ('up to 50 at once'), which separates it from the single-company sibling get_icp_fit_score. It does not explicitly name that sibling, so the differentiation is implicit rather than stated.

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 clear situational trigger ('Before outreach, choosing where to spend time... when the person has a list of companies'), which tells the agent exactly what context selects this tool. It never names an alternative or an exclusion, so the agent must infer that a single company should go to get_icp_fit_score instead.

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