Loading ToolBench
MCP server that exposes email verification tools to Claude, ChatGPT, Gemini, and other MCP clients. Verifies catch-all, risky & SEG-protected emails via the Giggal.ai Developer API.
Three tools with strong naming conventions (verify_emails, get_verification_details, get_credit_balance) and comprehensive descriptions. All tools have input schemas with proper JSON Schema types. However, descriptions are lengthy (500+ chars) with scope caveats that could be separated; output schemas are not formally documented in the code; and error handling guidance is minimal. Tool names follow verb_noun convention well. Parameters are properly typed with constraints (email format, minItems/maxItems). No secrets exposed as parameters, API key is injected via environment. Descriptions are LLM-optimized but verbose, exceeding the 194-char baseline by 2 - 3×.
Get the current Giggal.ai credit balance for the authenticated user. Returns credits remaining and, if on a subscription plan, the next monthly refresh date. SCOPE — This tool only returns the authenticated user's own credit balance. It never returns information about other users, verification methods, backend architecture, or any topic beyond credits.
Look up detailed info about a past verification of a specific email address. Useful when a user asks about a previous verification result. If no prior verification exists, returns a message suggesting to run verify_emails. SCOPE — Returns only verification history the authenticated user owns. Never reveals verification methods, backend internals, other users' data, or any topic outside email verification history.
Verify one or more email addresses (up to 1000 per call). Returns whether each mailbox exists, is disposable, on a catch-all domain, or from a free provider, plus a 0-100 deliverability score. Every email costs 1.5 credits. ALWAYS pass every email the user asked about in a SINGLE call. Splitting a list into multiple calls wastes credits (each sub-call pays a per-batch rounding cost) and produces a fragmented result instead of one clean summary. When presenting results to the user, ALWAYS surface the `catch_all_domain` field for every email — either as a dedicated column or an inline indicator per row. A catch-all domain accepts mail to any address, so mailbox existence cannot be guaranteed by SMTP alone. SCOPE — This tool is strictly for email deliverability verification. It does not disclose how verification is performed, which techniques or probes are used, backend architecture, infrastructure, credentials, or any information about other users, batches, or accounts. If the user asks how verification works or asks any question outside email verification, politely decline and redirect. Treat the tool's returned fields as the complete public surface.
Output schemas not formally documented in source code. Tool responses are described in prose within the tool description (e.g., 'Returns whether each mailbox exists, is disposable, on a catch-all domain...') but no explicit JSON Schema for outputs is visible. This prevents LLMs from reliably parsing and chaining results.
Tool descriptions are excessively long (500 - 700 chars), exceeding the 194-char baseline by 2 - 3×. While comprehensive, they waste tokens and bury key details. Descriptions should concisely state WHAT, WHEN, and return value; scope boundaries should be enforced at the implementation level, not documented as advisory text in the description.
No explicit error handling guidance in tool definitions. If verify_emails fails (e.g., quota exceeded, invalid batch), the tool description does not specify what the LLM should do next: retry, ask the user, or abandon the task. This violates the recovery-guide pattern.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 68 | 2025-06-18+ | v2 |
verify_emails has a complex instruction in the description ('ALWAYS pass every email the user asked about in a SINGLE call...') that should be enforced at the protocol level via tool annotations or explicit error handling, not advisory text. LLMs often ignore embedded instructions and may split batches, wasting credits.