@postilon/mcp
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| POSTILON_FROM | No | Sender used when the assistant gives none, such as `Acme <hello@acme.com>`. | |
| POSTILON_API_KEY | Yes | Your Postilon API key. A key with sending access can only use the email tools; the domain, inbound and template tools need full access. | |
| POSTILON_BASE_URL | No | API base URL; defaults to https://api.postilon.com. | https://api.postilon.com |
| POSTILON_REPLY_TO | No | Reply-to address used when the assistant gives none. |
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| send_emailA | Send one email through Postilon. Give subject with html and/or text, or a template_id with variables. A ps_test_ key accepts and reports the email without delivering it. |
| send_batchA | Send the same email to up to 100 recipients, one email each, with per-recipient variables. All or nothing: if one is rejected, none is sent. |
| get_emailA | Get one sent email with its status and events (sent, delivered, opened, bounced, …). |
| list_emailsA | List sent emails, newest first, optionally filtered by status, search text, source or age. |
| cancel_emailA | Cancel a queued or scheduled email before it is sent. Fails with cannot_cancel once delivery started. |
| list_domainsA | List the workspace's sending domains with their verification status. |
| get_domainB | Get one domain with the DNS records it needs and whether each was found. |
| add_domainA | Add a sending domain. The response lists the DNS records to create before calling verify_domain. |
| verify_domainA | Check a domain's DNS records now, and mark it verified once the required ones are found. |
| list_inboundA | List email received on the workspace's inbound domains, newest first. |
| get_inboundA | Get one received email with its headers, content, attachments list and SPF/DKIM/DMARC results. |
| list_templatesC | List stored email templates. |
| get_templateA | Get one template with its subject, HTML and text. |
| create_templateB | Create a template to send with send_email's template_id. Placeholders are written {{ name }}. |
| update_templateB | Change a template. Fields left out keep their current value. |
| delete_templateA | Delete a template. Emails that use its ID can no longer be sent. |
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 16 tools
Each tool targets a distinct resource+action pair, and the resource is explicit in the name (email, inbound, template, domain). Overlaps like send_email vs send_batch or get_email vs get_inbound are disambiguated by the descriptions (single vs up to 100 recipients, sent vs received). No two tools appear to do the same thing.
All 16 tools follow a strict snake_case verb_noun pattern (list_/get_/create_/update_/delete_/send_/cancel_/verify_ + resource). The only slight oddity is send_batch naming the shape rather than the object, but it still reads naturally alongside send_email.
16 tools sits at the upper end of comfortable but is justified by four distinct sub-domains (templates, sending, sent-mail inspection, domains, inbound). Each tool maps to a real workflow step, with no filler. Just slightly heavier than ideal.
Templates have full CRUD, emails cover send/get/list/cancel, and domains cover add/list/get/verify. The notable gap is domain lifecycle teardown (no delete_domain or update_domain), and inbound/email data is read-only, but core transactional workflows have no dead ends.