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

Annotations already cover read-only/idempotent/destructive, and the description still adds real behavior: each component reports score, weight and basis for audit, severe properties cap the total rather than being averaged away, unmeasurable components return 'unavailable with reasons, never estimated', and trademark data is flagged 'measured: false means nothing was searched'. It also scopes the trademark field to the top 5 results and states it is a signal, not clearance — exactly the caveats an agent needs before repeating output to a user.

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 and trigger are front-loaded in the first two sentences, and the subsequent sentences are dense with caveats rather than filler. Minor waste: 'Read-only. Cannot spend money.' is fully redundant with readOnlyHint=true, and the clearance disclaimer is effectively stated twice ('not legal clearance' then 'a signal, never a clearance').

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 an output schema and full annotation coverage, the description only needs to carry semantics and limits, which it does well (capping rule, unavailability handling, trademark caveat, explicit non-goals). The one gap is that both parameters are optional yet the description never says what the tool does when called with neither, or how domain and domains interact.

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 both parameters (domain, domains with 'up to 10, ranked best-first') are documented there. The description adds no parameter-level meaning — it never explains the single-domain vs batch relationship, nor what happens when neither optional parameter is supplied. Baseline 3 is appropriate for fully documented schema.

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 — 'Grades candidate names on measurable properties of the string' — then enumerates the properties (length, syllables, radio test, word list, brand edit distance, hyphens/digits, TLD perception). It actively differentiates from neighbors: 'It does not check availability', 'Not a search-ranking prediction', and 'brand_collision is string similarity, not legal clearance', which separates it from check_live, recommend_name/suggest_names and any ranking tool.

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?

'For when the user is choosing between names or asks whether one is any good' gives a clear triggering condition, and 'It does not check availability' rules out one class of misuse. It stops short of naming the sibling to use instead (check_live / recommend_name), so the routing is implied rather than explicit.

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