Loading ToolBench
This server provides email verification services using AtData's SafeToSend API. The SafeToSend API verifies email addresses to filter out invalid and high-risk ones, which results in higher open rates, clicks, and conversions.
The server defines 2 tools with clear verb-based names and good docstrings. However, critical issues undermine production readiness: (1) API key is exposed as an optional parameter despite being a sensitive credential, this violates the secret-injection pattern and risks leaking credentials into logs; (2) output schemas are not formally documented in the tool definitions, the docstrings describe expected return fields but JSON Schema is absent; (3) parameter descriptions are minimal and lack validation guidance; (4) error handling returns dictionary responses without structured classification or recovery hints; (5) batch_verify_emails lacks pagination despite accepting potentially unbounded lists. The verify_email tool makes an actual API call with verify=False (SSL bypass), a security anti-pattern. Both tools accept email as human-friendly input (good), but the batch tool lacks limits on array size.
Verify multiple email addresses using AtData's SafeToSend API. This tool allows you to verify multiple email addresses in batch, processing each one individually through the SafeToSend API.
Verify an email address using AtData's SafeToSend API. This tool verifies email addresses to filter out invalid and high-risk ones, which results in higher open rates, clicks, and conversions.
API key exposed as optional tool parameter instead of server-side secret injection. Credentials in tool parameters are logged in agent traces, LLM prompts, and audit trails. This is a critical security breach vector.
Output schemas not formally documented in JSON Schema format. Docstrings describe expected fields (verification_result, success, error, etc.) but the MCP tool definition has no structured schema declaration. LLMs cannot reliably parse or plan on undocumented output.
batch_verify_emails accepts unbounded array without size limits or pagination. An LLM could pass 10,000+ emails, causing memory/API quota exhaustion, timeout, or DOS. No guidance on chunking or retry strategy.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 57 | - | v1 |
Error responses are unstructured dictionaries with inconsistent fields. Some include status_code, some don't. No error classification (retryable vs user-fixable vs fatal). Lacks recovery guidance.
SSL certificate verification disabled (verify=False in requests.get). This allows man-in-the-middle attacks and should never ship in production. Credentials and email data transit unverified.
Parameter descriptions lack validation rules. Email param has no regex pattern or format hint. Batch API key description does not mention environment variable fallback, LLM may not realize it's optional.
No dry-run or confirmation for verification (low severity for read-only tool, but noted for completeness). Batch tool could accidentally verify thousands of internal test emails.