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

Goes well beyond the annotations by disclosing the exact cost ($390 in USDC or USDT), the payment rails (x402 or MPP), validation-before-charge ('Bad input is refused before any charge'), and the unusual return contract (it returns a request spec plus schema and example rather than the data). The only soft spot is that whether invoking the tool itself moves funds is implied by the two-step flow rather than stated outright.

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 key facts are front-loaded, but the text repeats itself: '200 contacts' twice, '$390' twice, and x402/MPP three times across the same paragraph. Trimming the restatement would sharpen it without losing information.

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 no output schema, the description usefully explains what is returned (the paid x402 request, response schema, and an example) and how to consume it, which an agent needs. The remaining gaps are parameter semantics and any differentiation from the other buy_* tools in the catalog.

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 67%, and the description adds essentially nothing about the six inputs (profile, keywords, regions, countries, exclude_domains, email). The only param-like mention ('email required') refers to the separate /buy/leads/check endpoint, not this tool's optional email field, which could actively mislead.

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 ('buy' a 'Verified B2B contact list, 200 contacts') plus the price and payment rail, so an agent immediately knows what is being obtained. It does not, however, differentiate itself from the many sibling buy_* tools (buy_brandwatch, buy_market_report, buy_discovery_listing), relying on the resource name alone.

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?

Provides concrete workflow context: run the free check first ('POST the same body to /buy/leads/check (email required)') before paying, and explains the two-step pattern of obtaining the request then POSTing it yourself. It gives no explicit routing versus sibling tools, so it is clear context without exclusions rather than a full when/when-not map.

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