Loading ToolBench
MCP Server for Tomba.io API integration - provides tools for email finding, verification, enrichment, and domain research
The Tomba MCP Server defines 26 tools with complete input schemas and descriptions. Naming follows verb_noun convention consistently (domain_search, email_finder, etc.). However, descriptions are often too brief (10-50 chars), parameter descriptions lack detail about constraints and formats, and output schemas are not documented. Tool definitions are explicitly registered in toolsHandler.ts with Zod validation schemas, making them visible and verifiable. Error handling is generic (returns JSON stringified results without recovery guidance). The server demonstrates good structural foundation but lacks LLM-optimization for descriptions and output documentation.
Find email addresses of article authors
Autocomplete domain names or company names as you type
Combine email and company enrichment in a single request
Search for companies using natural language queries with advanced filters
Enrich company data with information from domain
Create a new flag to organize leads and email addresses
Tool descriptions are too brief (mostly 30-60 characters) and lack LLM-optimization. Descriptions should explain WHAT the tool does, WHEN to use it, and prerequisites. Current descriptions like 'Search emails based on domain name' omit context for tool selection vs similar tools.
Output schemas are not documented. Tools return JSON.stringify results but callers cannot know what fields to expect, forcing LLMs to infer structure and increasing downstream tool call errors.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 59 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 51 | - | v1 |
Create a new lead with email and optional additional information
Search emails based on domain name
Check the delivery status of a domain and associated email addresses
Get the total number of email addresses for a domain
Enrich email with additional data
Find email address from domain, first name and last name
Predict the email format for a domain based on known patterns
Get email sources and sources types for a domain
Verify email address deliverability
Get API logs for account usage and monitoring
Find email addresses from LinkedIn URLs
List all flags in the account
List all API keys for the account
List all leads in the account
Get location and geo-IP information for email addresses or domains
Enrich person data with information from email address
Search phone numbers based on email, domain, or LinkedIn
Validate phone numbers and check carrier information
Find similar domains based on a specific domain
Instantly reveal the technology stack of any website
Parameter descriptions lack constraint details (format, range, enum values). For example, 'domain' parameters lack explanation of expected format, valid characters, or examples. 'country' parameters describe purpose but not ISO 3166-1 alpha-2 requirement clearly in descriptions (only in schema enum).
list_* and search_* tools lack explicit pagination documentation. While domain_search accepts 'limit' and 'page' parameters, descriptions do not state whether results are capped at API limits or how to handle large datasets. Missing guidance on max result counts and whether total count is returned.
Error handling is generic. The handleToolCall function catches errors but returns only JSON stringification of results. No guidance provided to LLMs on retryability, user-fixable errors, or recovery steps.
create_flag and create_lead are marked WRITE operations but lack confirmation/dry-run patterns and no idempotency guarantees documented. LLMs cannot distinguish between safe retries and duplicate-creating retries.
Multiple similar tools exist without clear disambiguation. email_finder, email_enrichment, and person_enrichment all work with emails but have unclear distinctions. email_search (domain_search) vs email_finder vs companies_search create LLM selection ambiguity.