vaemail
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| VAEMAIL_API_KEY | Yes | Account API key. Created from the dashboard, under « Clés API ». | |
| VAEMAIL_BASE_URL | No | API base URL. Defaults to https://app.vaemail.fr. | https://app.vaemail.fr |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| vaemail_capabilitiesA | Return what VaEmail supports: interfaces, capabilities, limits, scopes and region. No API key needed. Call this first when deciding whether VaEmail fits a need. |
| vaemail_send_emailA | 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. |
| vaemail_validate_emailA | 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. |
| vaemail_get_messageA | 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. |
| vaemail_list_messagesA | List messages newest first, filtered by status, tag or recipient. Paginate with the returned next_cursor. |
| vaemail_list_domainsA | List the sending domains of the account with the live state of their SPF, DKIM and DMARC records. |
| vaemail_create_domainA | 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. |
| vaemail_verify_domainA | 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. |
| vaemail_dns_requirementsA | Return the DNS records a declared domain needs, record by record, with the role of each. |
| vaemail_diagnose_deliverabilityA | 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. |
| vaemail_list_bouncesA | 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. |
| vaemail_get_usageA | 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. |
| vaemail_get_audit_logA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 13 tools
Most tools target a distinct resource and action: send, validate, get message, list messages, bounces, usage, audit, domains. The only mild overlap is between vaemail_dns_requirements and vaemail_create_domain, since both return DNS records, but they are separated by stage: one is a general reference and the other acts on a specific newly declared domain.
All tools share the vaemail_ prefix and most follow a clear verb_noun pattern such as list_domains, send_email, get_message, create_domain. Two tools, vaemail_capabilities and vaemail_dns_requirements, are noun-only rather than verb_noun, which is a minor deviation but does not create confusion.
13 tools is well within the ideal range and appropriate for a transactional email service. Each tool covers a meaningful part of the workflow: capabilities, domain setup, sending, delivery tracking, bounce management, validation, usage, and diagnostics.
The tool surface covers the main transactional email lifecycle: send, validate, track, list, diagnose deliverability, manage domain verification, and review bounces. Minor gaps exist such as no domain removal or bounce management beyond listing, but agents can complete core workflows without dead ends.