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

Even though readOnlyHint and idempotentHint are already declared, the description adds substantial beyond-annotation context: verified-claim behavior, failure non-charging, a free prompt-injection scan, and concrete pricing/rail (x402, eip155:8453, $0.01 USDC per successful call). This is exactly the kind of behavioral and commercial context an agent needs before invoking.

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 first sentence is front-loaded and strong, but the description becomes a dense run-on mixing verification, pricing, failure policy, and a bundled scan. Every clause is relevant, but the lack of structure and sentence separation makes it harder to parse than it needs to be.

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 single-parameter read-only scraper with no output schema, the description covers what is returned, evidence grounding, failure policy, cost, and a bundled scan. The main gap is that it doesn't describe the return shape in more detail (e.g., whether technology platforms are a list with names and evidence URLs), though the description gives enough to call it correctly.

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 coverage is 100% and the schema already specifies 'Bare domain, no scheme or path, e.g. mailchimp.com' with a maxLength. The description adds no new parameter-syntax information beyond what the schema provides, so baseline 3 is appropriate.

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 ('Given a business website domain, returns...'), enumerates the outputs (business name, contact surface, technology platforms with evidence), and distinguishes it from a sibling via 'Faster, cheaper tier than /enrich.' It does not, however, explicitly name the sibling enrich_business that an agent would actually choose between.

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?

It gives an explicit comparative substitution ('Faster, cheaper tier than /enrich') and a failure-cost condition ('Not charged if the page cannot be used'), which is real selection guidance. It lacks an explicit when-not-to-use statement or a direct reference to the actual sibling tool name enrich_business.

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