find_emailFind a person's work email address from their first name, last name and company domain (e.g. Jane Doe at acme.com). Tries the common corporate patterns and returns only addresses that pass an SMTP check. Spends one scrape credit per call.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Company domain, for example 'acme.com' | |
| last_name | Yes | Last name | |
| first_name | Yes | First name |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (idempotent, non-destructive, open-world), the description adds concrete operational behavior: it 'tries the common corporate patterns', performs SMTP checks, 'returns only addresses that pass', and costs 'one scrape credit per call'. This is valuable context—especially the credit cost—that the annotations do not convey.
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 three sentences with no filler: purpose plus example, method, and cost. Each sentence earns its place and the most important information is front-loaded.
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 3-parameter, no-output-schema tool, the description covers the purpose, input requirements, verification behavior, and cost. Minor gaps remain (exact return format and behavior when no email is found), but these are not critical for an agent to call the tool 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%: first_name, last_name, and domain each have basic descriptions. The tool description's example 'Jane Doe at acme.com' reinforces the mapping but adds no format constraints or deeper semantics beyond the schema, so the baseline of 3 applies.
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 ('Find'), a clear resource ('a person's work email address'), and the three required inputs (first name, last name, company domain) with a concrete example. It is unambiguous in what it does, but it does not explicitly contrast with sibling tools like verify_email or enrich_lead, so it stops short of full differentiation.
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 implies the usage condition: you can call this when you have a person's first name, last name, and company domain. However, it does not state when it should not be used or mention alternative tools for tasks like verifying an already-known email address, so the guidance is implied rather than explicit.
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.