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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered; the description adds real value by disclosing conditional behavior (bid and minimum-budget figures are only returned when objective is supplied) and a built-in threshold warning at LinkedIn's 300-member minimum. It does not mention latency, API quota cost, or whether zero/suppressed results are returned as an error, which keeps it from a 5.

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?

A single front-loaded sentence naming the primary output first, then the warning, then the conditional bid/budget, with two tight parentheticals that carry real information. Nothing is redundant with the title or restates the tool name.

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 an 11-parameter tool with a nested targeting object and no output schema, the description does the essential work of naming the three return values (audience size, minimum-size warning, bid and minimum daily budget). It leaves account/currency resolution and the targeting_criteria escape hatch entirely to the schema, which is acceptable given 91% coverage but leaves a small gap for a read-only estimator whose results feed budget decisions.

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 91%, so the schema already carries nearly all parameter meaning, including the targeting facet list, language rules, and bid_strategy enum effects. The description reinforces the two mutually exclusive input paths (targeting spec vs. campaign) and the objective-gated bid output, but adds little parameter detail the schema does not already state, so baseline 3 applies.

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 concrete verb+resource pair ('Audience size for a targeting spec') and adds the two secondary outputs it returns: the 300-member warning and the recommended bid / minimum daily budget. The 'LinkedIn' framing plus the specified outputs make it distinguishable from generic reach tools and from linkedin_targeting_search, which supplies the URNs this tool consumes.

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 clear usage context: it accepts either an ad-hoc targeting spec or an existing campaign's targeting, and the bid/budget portion only appears 'when objective is given'. What's missing is any explicit exclusion or prerequisite routing, e.g. that targeting URNs must first be resolved via linkedin_targeting_search, or when to skip estimation and go straight to campaign creation.

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