Enrich Prospect

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds material behavioral context beyond those annotations: it discloses the monetary cost ($0.50 USDC on Base) and hints at the paid, two-call payment flow via the _payment param description. This adds genuine value for an agent deciding whether to invoke a paid tool. Slightly room for more (e.g., what the email pattern looks like), but solid.

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?

Three concise sentences: the main capability, the use cases, and the cost. All front-loaded with the core purpose first. The description is efficient with no wasted words. The one minor deduction is that cost and payment could be positioned more prominently since it's a paid tool, but the current structure is clean and every sentence earns its place.

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 tool whose output is a rich prospect profile (seniority, persona, decision-maker probability, etc.), the description front-loads the output surface clearly. The output schema exists, so return format is covered by structured data. The paid/payment-flow nuance is addressed. What's missing: any caveats about accuracy, turnaround time, or cases where enrichment might fail (e.g., unknown domain). Given good annotations and output schema, this is reasonably 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 coverage is 100%, so the schema documents all 5 parameters. The description adds meaning beyond this by explaining the output relationship (name + domain as the two required inputs that drive the enrichment). The _payment parameter, in particular, gets valuable supplementary detail in the description about signing locally with @x402/evm/@x402/fetch and the 'first call without _payment, then retry' flow — context the schema alone doesn't convey. Baseline 3 elevated for the _payment guidance.

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 uses a specific verb ('turn... into') plus a precise resource ('a sales-ready prospect profile') and enumerates the concrete outputs: seniority, buyer persona, decision-maker probability, company intel, email pattern, and cold-email opener. This clearly differentiates it from sibling tools (qr.generate, dns.lookup, email.validate, document.parse), which are unrelated domains, and it names the use cases (AI SDRs, lead enrichment, outbound personalisation).

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 states clear contexts for use: AI SDRs, lead enrichment, and outbound personalisation. It also flags the $0.50 cost, which is important usage context. It doesn't explicitly state when NOT to use it or name alternative enrichment tools among the siblings, but the siblings are all unrelated (QR, DNS, OCR, screenshots), so there's no competing tool to disambiguate. The 'use for' phrasing gives strong guidance.

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