Loading ToolBench
Hunter.io MCP — wraps the Hunter.io email finder & verification API (hunter.io)
Hunter.io MCP has well-structured tool definitions with complete input schemas and clear descriptions. All three tools (domain_search, email_finder, email_verifier) follow verb_noun naming and include parameter type definitions. However, output schemas are not documented, LLMs cannot predict response structure for planning downstream calls. Error handling returns structured objects but lacks recovery guidance. The _apiKey parameter violates secret-injection pattern by exposing it as a tool parameter, though the code comment acknowledges dual-key design. Parameter descriptions are adequate (50-150 chars) but lack constraint details (e.g., domain format, confidence score range). No tool annotations (readOnlyHint, idempotentHint) despite all being read-only operations.
Find email addresses for a domain on Hunter.io. Returns the email pattern plus a list of professional/work emails with names, positions, departments, and confidence scores. Example: domain_search({ domain: "stripe.com" })
Find the most likely professional/work email address for a specific person at a domain on Hunter.io. Returns the email, a confidence score, position, and the number of corroborating sources. Example: email_finder({ domain: "stripe.com", first_name: "Patrick", last_name: "Collison" })
Verify an email address with Hunter.io email verification. Checks deliverability, MX records, SMTP, and whether the address is disposable or webmail. Returns a status, result, and confidence score. Example: email_verifier({ email: "[email protected]" })
Output schemas not documented. LLMs cannot predict response structure (e.g., domain_search returns {domain, organization, pattern, emails[]} but this is invisible to callers). Forces agents to guess field names for downstream operations.
_apiKey exposed as tool parameter violates secret-injection pattern. API keys should never appear in tool parameters, they end up in agent logs and traces. Use server-side injection via environment variables instead.
No tool annotations despite all tools being read-only. Missing readOnlyHint annotation prevents agents from understanding safety properties and planning accordingly.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Error handling returns {error, message} but lacks recovery guidance. When api_key_required error occurs, LLM has no actionable next step. Should suggest 'Provide your Hunter.io API key or contact admin for shared key access.'
Parameter descriptions lack constraint details. 'limit' accepts 1-100 but description only says 'default 10, max 100', no minimum stated. 'type' enum values are documented but 'department' has no examples or valid values list.