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

Annotations only declare readOnlyHint=true. The description goes far beyond that: it discloses the parallel fan-out mechanism (ThreadPoolExecutor, max 20 concurrent), the cost model (1 Sliq credit per found=True, free for found=False), soft-failure behavior on insufficient credits, the per-user 24h cache, dedup behavior, and that results are saved to canonical company entities. No contradiction with readOnlyHint—enrichment is a lookup/read operation that stores results for the user's workspace but does not modify external state in a way that violates a read-only hint. This is rich behavioral transparency that annotations alone would never provide.

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?

The description is front-loaded with the core usage rule in the very first sentence, then layers details in a logical order: batching, endpoint, cost, caching, dedup, persistence. Every paragraph earns its place. It is long, but the length is justified by the behavioral and cost details an agent needs to avoid misuse. A 4 rather than 5 because the <returns> block is quite verbose and could be trimmed without losing essential guidance—some of the funding-stage formatting detail could live in the schema or output schema instead.

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?

Given the tool's complexity—costing, caching, dedup, batched parallel execution, and two distinct output shapes—the description covers everything an agent needs to call it correctly and interpret results. It even explains how missing funding data affects downstream matching (matches_icp includes-on-null). There is no output schema, so the description properly carries the burden of explaining the return structure. The only minor gap is a lack of an explicit 'when not to use' list beyond person enrichment, but it names the key sibling and the coverage is otherwise complete.

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%—the single 'domains' parameter is fully described in the schema, including order preservation and duplicate collapsing. The description reinforces the batch usage ('Pass all candidate domains at once') and adds the canonicalization detail, but it doesn't need to add much beyond what the schema already states. Baseline 3 is appropriate for full schema coverage with minor descriptive reinforcement.

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?

The description states a specific verb and resource: 'Enrich multiple company domains in a single call.' It clearly distinguishes this tool from siblings like find_email and enrich_linkedin_profiles by specifying org-only enrichment (company domains, not people). The phrase 'Enrich multiple company domains in a single call' is specific and action-oriented, leaving no ambiguity about what the tool does.

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?

The description explicitly tells the agent when to use this tool: pass all candidate domains at once, one call with the full list, not one call per domain. It also names an alternative—'For person enrichment (work email, LinkedIn URL), use find_email instead'—and identifies the sibling tool by name. This gives the agent both a positive usage rule and an explicit exclusion, which is exactly what the dimension asks for.

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