Find publicly available business email addresses for a company domain.
Wraps nexgendata/company-email-finder. Returns probable role-based
emails (info@, sales@, support@, etc.) plus any verified contacts
discovered by crawling the homepage and common contact pages.
Args: domain: Company domain (e.g. "stripe.com" — with or without scheme)
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations (readOnlyHint, openWorldHint) by stating it wraps a specific data source and returns role-based emails plus verified contacts from crawling. This helps the agent understand the nature of results and method. No contradictions.
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 concise with no wasted words. It is front-loaded with the main action, then provides additional details in a logical order: purpose, data source, output types, and parameter specification.
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 simple tool with one parameter and no output schema, the description covers the essential aspects: what it does, what it returns, and how the parameter should be provided. It is missing explicit return format but is sufficient given the read-only and open-world hints.
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?
With 0% schema description coverage, the description compensates by explaining the 'domain' parameter format and example. It adds meaning beyond the bare schema by specifying that the domain can be with or without scheme.
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 'Find' and resource 'company emails'. It clearly explains the output (probable role-based and verified contacts) and distinguishes from sibling tools like 'enrich_company' or 'find_b2b_leads'. No ambiguity.
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 provides clear context for when to use the tool (when needing publicly available email addresses for a company domain). It does not explicitly mention alternatives or when not to use, but the context is sufficiently clear given the sibling tools are distinct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct sales intelligence function: from company profiling, tech detection, hiring signals, to lead finding and enrichment. Even the two enrichment tools (enrich_company vs. aggregate_company_profile) are clearly differentiated by depth and features.
All tools follow a consistent verb_noun snake_case pattern (e.g., aggregate_company_profile, detect_tech_stack, find_b2b_leads). No mixing of conventions or vague verbs.
10 tools is well-scoped for a sales intelligence server, covering the full pipeline from prospecting to enrichment and signal detection. It's neither too sparse nor overwhelming.
The tool set covers end-to-end sales research: lead generation, company enrichment, tech stack detection, hiring signals, email finding, YC directory, job search, and funding tracking. No obvious gaps for the intended domain.