Skip to main content
Glama
mailgun

Mailgun MCP Server

Official
by mailgun

post--v3-domain_name-messages

Send emails through Mailgun with customizable recipients, content, attachments, templates, and delivery options for automated messaging.

Instructions

Send an email

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
domain_nameYes
fromYesEmail address of the `From` header. Can include a friendly name using the format `"Friendly Name <email@domain.com>"`. Note: not required if sending with a template that has a pre-set From header, but will override the template's From header if provided.
toYesEmail address of the recipient(s). Supports friendly name format. Example: `"Bob <bob@host.com>"`. Use commas to separate multiple recipients. Duplicate addresses are automatically ignored.
ccNoSame as `to` but for carbon copy recipients. Supports friendly name format.
bccNoSame as `to` but for blind carbon copy recipients. Supports friendly name format.
subjectYesMessage subject. Note: not required if sending with a template that has a pre-set Subject header, but it will override it if provided.
textNoBody of the message (text version)
htmlNoBody of the message (HTML version)
amp-htmlNoAMP part of the message. Please follow Google guidelines to compose and send AMP emails
attachmentNoFile attachment. You can post multiple `attachment` values. **Important:** You must use `multipart/form-data` encoding for sending attachments
inlineNoAttachment with `inline` disposition. Can be used to send inline images (see example). You can post multiple `inline` values
templateNoName of a template stored via the Templates API to use to render the email body. See [Templates](https://documentation.mailgun.com/docs/mailgun/user-manual/sending-messages/send-templates) for more information
t_versionNoRender a specific version of the given template instead of the latest version. `template` option must also be provided.
t_textNo
t_variablesNoA valid JSON-encoded dictionary used as the input for template variable expansion. See [Templates](https://documentation.mailgun.com/docs/mailgun/user-manual/sending-messages/send-templates) for more information
o_tagNoTag string. See [Tagging](https://documentation.mailgun.com/docs/mailgun/user-manual/tracking-messages/track-tagging) for more information
o_dkimNo
o_secondary-dkimNoSpecify a second domain key to sign the email with. The value is formatted as `signing_domain/selector`, e.g. `example.com/s1`. This tells Mailgun to sign the message with the signing domain `example.com` using the selector `s1`. Note: the domain key specified must have been previously created and activated.
o_secondary-dkim-publicNoSpecify an alias of the domain key specified in `o:secondary-dkim`. Also formatted as `public_signing_domain/selector`. `o:secondary-dkim` option must also be provided. Mailgun will sign the message with the provided key of the secondary DKIM, but use the public secondary DKIM name and selector. Note: We will perform a DNS check prior to signing the message to ensure the public keys matches the secondary DKIM.
o_deliverytimeNoSpecifies the scheduled delivery time in [RFC-2822 format](https://documentation.mailgun.com/docs/mailgun/api-reference/api-overview#date-format). Depending on your plan, you can schedule messages up to 3 or 7 days in advance. If your domain has a custom message_ttl (time-to-live) setting, this value determines the maximum scheduling duration. Example: 'Fri, 14 Oct 2011 12:00:00 +0000'
o_deliver-withinNoSpecifies the maximum time window for delivering the message. Accepts values in format `[0-9]+h[0-9]+m` (e.g., `1h30m`, `30m`, `24h`), with a minimum of `5m` and maximum of `24h`. For scheduled messages, the delivery window starts from the scheduled time. The standard retry schedule applies within this window, so shorter timeframes may result in fewer delivery attempts.
o_deliverytime-optimize-periodNoToggles Send Time Optimization (STO) on a per-message basis. String should be set to the number of hours in `[0-9]+h` format, with the minimum being `24h` and the maximum being `72h`. This value defines the time window in which Mailgun will run the optimization algorithm based on prior engagement data of a given recipient. See [Sending a Message with STO](https://documentation.mailgun.com/docs/mailgun/user-manual/sending-messages/send-sto) for details. *Please note that STO is only available on certain plans. See www.mailgun.com/pricing for more info*
o_time-zone-localizeNoToggles Timezone Optimization (TZO) on a per message basis. String should be set to preferred delivery time in `HH:mm` or `hh:mmaa` format, where `HH:mm` is used for 24 hour format without AM/PM and hh:mmaa is used for 12 hour format with AM/PM. See [Sending a Message with TZO](https://documentation.mailgun.com/docs/mailgun/user-manual/sending-messages/send-tzo) for details. *Please note that TZO is only available on certain plans. See www.mailgun.com/pricing for more info*
o_testmodeNo
o_trackingNo
o_tracking-clicksNo
o_tracking-opensNo
o_require-tlsNo
o_skip-verificationNo
o_sending-ipNoUsed to specify an IP Address to send an email that is owned by your account
o_sending-ip-poolNoIf an IP Pool ID is provided, the email will be delivered with an IP that belongs in that pool
o_tracking-pixel-location-topNo
o_archive-toNoSends a copy of successfully delivered messages to the specified URL via HTTP POST. The request uses Content-Type: application/mime and contains the exact message the recipient's SMTP server received. NOTE: These are accounted for and billed as delivered messages
o_suppress-headersNoRemoves specified X-Mailgun headers from the delivered message. Provide header names separated by commas (e.g., 'X-Mailgun-Variables,X-Mailgun-Tag') or use 'all' to remove all X-Mailgun headers.Note: X-Mailgun-Sid header is currently used to process complains received via feedback loops.
h_X-My-HeaderNoAdds custom headers to the email. Use 'h:' prefix followed by header name and value. Example: 'h:X-Custom-Header=my-value'
v_my-varNoAttaches custom data to the message using the 'v:' prefix followed by a variable name. When sending with templates, provides values for template variable substitution (overridden by 't:variables' if both are provided). When not using templates, treated as metadata and included in events/webhooks. Variables are visible in the delivered email's X-Mailgun-Variables header. Example: 'v:user-id=123'. NOTE: Anything over 4KB will be truncated in the event/webhooks.
recipient-variablesNoA JSON-encoded dictionary for batch sending with personalized variables per recipient. Each key is a recipient email address, each value is a dictionary of variables for that recipient. Variables can be referenced in the message using %recipient.variablename%. Example: '{"alice@example.com": {"name":"Alice", "id":1}, "bob@example.com": {"name":"Bob", "id":2}}'. Maximum 1,000 recipients per batch. See [Batch Sending](https://documentation.mailgun.com/docs/mailgun/user-manual/sending-messages/batch-sending) for more information
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden for behavioral disclosure. 'Send an email' implies a write/mutation operation but reveals nothing about authentication needs, rate limits, side effects (e.g., billing implications noted in schema for 'o:archive-to'), error handling, or response format. This is critically inadequate for a complex mutation tool with no annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise ('Send an email') with zero wasted words, making it front-loaded and easy to parse. However, this conciseness comes at the cost of completeness, but purely on brevity and structure, it's optimal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex mutation tool with 37 parameters, no annotations, and no output schema, the description is completely inadequate. It fails to address behavioral aspects, usage context, or any details beyond the minimal purpose, leaving the agent with insufficient information to understand the tool's full scope and implications.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 73%, providing good baseline documentation for most parameters. The description adds no parameter-specific information beyond the generic 'Send an email', so it doesn't compensate for the 27% gap or enhance understanding of parameter interactions. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't add value but doesn't detract either.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Send an email' states the basic action but is overly simplistic for a complex tool with 37 parameters. While it identifies the verb ('Send') and resource ('email'), it doesn't distinguish this from other email-related tools in the sibling list (like template management or analytics tools) and lacks specificity about the comprehensive capabilities implied by the extensive parameter schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. With many sibling tools (e.g., template management, analytics, list management), there's no indication of when this primary email-sending tool is appropriate versus other post/put tools for related functions, leaving the agent without contextual usage direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mailgun/mailgun-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server