Loading ToolBench
Email infrastructure for AI agents: MCP server and CLI for VaEmail. Send email, authenticate domains, track delivery, diagnose deliverability.
VaEmail MCP server demonstrates solid definition quality with 14 well-structured tools covering email infrastructure. All tools have clear names following verb_noun patterns (send_email, list_messages, verify_domain, etc.). Most tools include comprehensive descriptions (median ~180 chars) and properly structured JSON schemas with typed parameters. Input validation is explicit (enums for status, format constraints for emails). However, some parameter descriptions lack depth regarding prerequisites and error recovery. Output schemas are implied but not fully documented in the tool definitions. Error handling guidance is present but could be more prescriptive about retry strategies and next steps. The server demonstrates good attention to composition, tools are cleanly separated (send vs validate vs get_message) and support idempotent operations via idempotency_key parameters. French descriptions (for vaemail_envoyer_newsletter) are detailed but may reduce LLM clarity.
Return what VaEmail supports: interfaces, capabilities, limits, scopes and region. No API key needed. Call this first when deciding whether VaEmail fits a need.
Declare a domain and return the DNS records to add at the registrar, each with what it is for. Declaring a domain does not authenticate it: the records must be published, then verified. Adding DNS records is a human step — report them, do not claim the domain is ready.
Diagnose deliverability for the account: authentication of every domain, reputation findings (hard bounces, complaints, where the contacts came from) and recommended actions, each with the endpoint that performs it. Answers "why are my emails from example.com landing badly?" in one call.
Return the DNS records a declared domain needs, record by record, with the role of each.
Envoie ou programme une newsletter à une liste de contacts, en un seul appel. Fait tout seul : retrouve la liste par son nom, crée la campagne, envoie un test si demandé, puis programme à la date donnée ou envoie tout de suite, et rend la date, l'audience abonnée à ce jour, l'étalement prévu par la chauffe du domaine et le lien vers la campagne dans l'admin. Ne fait jamais : envoyer sans « quand » explicite (sans ce champ, la campagne reste en brouillon, rien ne part) ; inventer une liste (si le nom est ambigu, l'outil rend les candidates et vous choisissez avec l'humain). Utilisez-le dès que quelqu'un dit « envoie / programme la newsletter à … ». Exemple : { "sujet": "Votre budget formation 2026 se ferme le 31 décembre", "contenu": "<p>…</p>", "liste": "L'actu BienveNum", "quand": "2026-09-17 10:00", "test_vers": "hugo@agencesw.com" }.
Output schemas not explicitly documented in tool definitions. Tool descriptions state what is returned (e.g., 'return the delivery status... plus events...') but structured output schemas are not visible in source. LLMs cannot plan downstream calls or extract fields with certainty.
Some parameter descriptions lack actionable constraint details. E.g., 'limit' params lack min/max guidance (though JSON schema may enforce); 'cursor' param documentation does not explain pagination behavior or indicate it comes from a prior call.
French-language tool and parameter descriptions (vaemail_envoyer_newsletter) may reduce clarity for non-French-speaking LLMs and mixed-language agent deployments. Consider English-primary descriptions with translations as fallback.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 67 | 2025-06-18+ | v2 |
Return the log of API actions: which key, which operation, which parameters, which result. Message bodies are never stored in it. Use it to report exactly what was done.
Return the delivery status of a message and every event known about it (delivered, opened, clicked, bounced, complained), plus the transport error when it failed.
Return the monthly quota and what is left of it, today's sends, and for the key in use: its scopes, its daily cap and the remaining allowance. Read it before a batch to know whether to stop.
List addresses excluded from sending: hard bounces, complaints and unsubscribes, with the reason for each. Sending to one of them is refused, so read this before retrying a failed recipient.
List the sending domains of the account with the live state of their SPF, DKIM and DMARC records.
List messages newest first, filtered by status, tag or recipient. Paginate with the returned next_cursor.
Queue a transactional email and return its id. The call returns as soon as the message is ACCEPTED, not when it is delivered: use vaemail_get_message to find out what happened to it. Pass idempotency_key when retrying so a network timeout cannot send the same message twice.
Dry run: report whether the email would go out, and name what would block it. Sends nothing. Use it right after setup, before the first real message.
Read SPF, DKIM and DMARC for a domain in the public DNS and report each record. Without SPF and DMARC, large mailbox providers file the mail as spam.
Error recovery guidance is minimal. Tool descriptions (e.g., vaemail_list_messages, vaemail_create_domain) do not explicitly state what to do on failure, which errors are retryable, or what the LLM should try next. Idempotency is mentioned for send operations but not documented as a recovery pattern.
Tool 'vaemail_capabilities' and 'vaemail_get_usage' descriptions do not explain when to call them in relation to other tools. Prerequisites and discovery patterns are implicit, not stated.