Give it company websites, get back named decision-makers with job titles, plus emails, phones and LinkedIn — junk addresses filtered out. $15.00 per 1,000 companies.
| Name | Required | Description | Default |
|---|---|---|---|
| websites | Yes | Company websites or domains (max 25). | |
| onlyWithEmail | No | Skip sites where no email was found. | |
| maxPagesPerSite | No | Pages to read per site (max 12). |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden condensed into one sentence. It discloses the output fields, says junk addresses are filtered, and states the $15.00 per 1,000 companies cost, but it omits caveats like response format, failure modes, or data freshness.
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 a single dense sentence that efficiently conveys input, output, data quality, and pricing. Every element serves a purpose and nothing is redundant or padded.
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?
The description communicates the core domain (website-to-contact enrichment), output fields, and cost, which is enough for basic tool selection. However, it does not explain response shape, potential empty results, or how the two optional parameters affect outcomes, leaving some uncertainty for an autonomous agent.
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% for all three parameters, so the baseline is 3. The description adds context about pricing and output contents, but it does not explain how onlyWithEmail or maxPagesPerSite affect the behavior beyond what the schema already states.
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 clearly states the tool's function: given company websites, return named decision-makers with job titles, emails, phones, and LinkedIn. This is specific and immediately understandable. It does not explicitly contrast with sibling tools, so it stops short of a perfect score.
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 phrase 'Give it company websites' makes the input requirement and primary use case clear: use this when you have a list of company websites and want contact details. However, it does not mention alternatives or exclusions relative to its siblings like leads_verify_domains or leads_find_businesses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.