Skip to main content
Glama
resend

Email Sending MCP

by resend

Create Automation

create-automation

Create automated email sequences triggered by events, with steps for sending, delaying, conditional branching, and contact management.

Instructions

Purpose: Create an automation workflow that triggers on events and executes a sequence of steps.

When to use:

  • User wants to set up automated email sequences (welcome series, drip campaigns, re-engagement)

  • User wants to automate actions based on events (update contacts, add to segments)

Workflow: manage-events (create event, if needed) → list-templates (to get template IDs) → get-template (to check if template has "from" and "subject" — if not, use list-domains to pick a verified domain for the step config) → create-automation → send-event (to test)

Returns: Automation ID and dashboard link.

The workflow is a JSON object with one key: "steps" — an array of step objects.

Each step has: key (unique string), type, config, and either "next" (string|null) or "branches" (for branching steps). Use keys like: "trigger", "send_email_1", "delay_1", "condition_1", "wait_event_1".

Step types

trigger — starts the automation when an event fires (required, exactly one)

config: { "eventName": "" } Uses "next".

send_email — send an email using a published template

config: { "template": { "id": "", "variables": { "": "" } }, "from": "Name sender@example.com", "subject": "Email subject", "replyTo": "" } "from" and "subject" are resolved from the step config first, then fall back to the template. If neither provides a "from", the email will silently fail to send. If neither provides a "subject", the run will error. Best practice: always set "from" and "subject" on the step config so the automation is self-contained. Use list-domains to find verified domains for "from". "replyTo" and "variables" are optional. Variables can use { "var": "event." } or { "var": "contact." } for dynamic values. Uses "next".

delay — pause the workflow

config: { "duration": "" } Examples: "30 minutes", "1 hour", "2 days", "1 week". Max 30 days. Uses "next".

condition — conditional split based on contact or event data

config: A condition rule object: Single rule: { "type": "rule", "field": "event." or "contact.", "operator": "", "value": } Compound: { "type": "and"|"or", "rules": [, ...] } Operators: eq, neq, gt, gte, lt, lte, contains, starts_with, ends_with, exists, is_empty. exists/is_empty do not require a value. Uses "branches": { "condition_met": "", "condition_not_met": "" }

wait_for_event — pause until a specific event arrives or timeout

config: { "eventName": "", "timeout": "", "filterRule": } For email lifecycle events use "resend:email.<opened|clicked|bounced|delivered|complained|failed|suppressed>". Uses "branches": { "event_received": "", "timeout": "" }

contact_update — update contact fields

config: { "firstName": "", "lastName": "", "unsubscribed": true|false, "properties": { "": "" } } All fields optional. Values can use { "var": "event." } for dynamic data. Uses "next".

contact_delete — remove the contact from the audience

config: {} Uses "next".

add_to_segment — add contact to a segment

config: { "segmentId": "" } Uses "next".

Rules

  1. Every step must be reachable from the trigger via next/branches.

  2. Terminal steps have "next": null (or null branch values).

  3. The workflow must be tree-shaped — no merging branches back together.

Example: Linear drip campaign

{ "steps": [ { "key": "trigger", "type": "trigger", "config": { "eventName": "user.created" }, "next": "send_email_1" }, { "key": "send_email_1", "type": "send_email", "config": { "template": { "id": "tmpl_123" }, "from": "Welcome hello@example.com", "subject": "Welcome!" }, "next": "delay_1" }, { "key": "delay_1", "type": "delay", "config": { "duration": "3 days" }, "next": "send_email_2" }, { "key": "send_email_2", "type": "send_email", "config": { "template": { "id": "tmpl_456" }, "from": "Welcome hello@example.com", "subject": "Getting started" }, "next": null } ] }

Example: Re-engagement with wait_for_event

{ "steps": [ { "key": "trigger", "type": "trigger", "config": { "eventName": "user.created" }, "next": "send_email_1" }, { "key": "send_email_1", "type": "send_email", "config": { "template": { "id": "tmpl_789" }, "from": "Team team@example.com", "subject": "Welcome" }, "next": "wait_event_1" }, { "key": "wait_event_1", "type": "wait_for_event", "config": { "eventName": "resend:email.opened", "timeout": "3 days" }, "branches": { "event_received": null, "timeout": "send_email_2" } }, { "key": "send_email_2", "type": "send_email", "config": { "template": { "id": "tmpl_abc" }, "from": "Team team@example.com", "subject": "Did you miss this?" }, "next": null } ] }

Example: Condition branch

{ "steps": [ { "key": "trigger", "type": "trigger", "config": { "eventName": "trial.ended" }, "next": "condition_1" }, { "key": "condition_1", "type": "condition", "config": { "type": "rule", "field": "event.converted", "operator": "eq", "value": true }, "branches": { "condition_met": "send_email_1", "condition_not_met": "send_email_2" } }, { "key": "send_email_1", "type": "send_email", "config": { "template": { "id": "tmpl_thanks" }, "from": "Team team@example.com", "subject": "Thanks for upgrading!" }, "next": null }, { "key": "send_email_2", "type": "send_email", "config": { "template": { "id": "tmpl_win_back" }, "from": "Team team@example.com", "subject": "We'd love to have you back" }, "next": null } ] }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesName for the automation (e.g., "Welcome Series")
statusNoInitial status. Default: disabled. Use "enabled" to activate immediately.
workflowYesThe workflow definition. See the tool description for the full schema and examples.
Behavior4/5

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

No annotations are provided, so the description bears full responsibility. It details the workflow object structure, step types, configs, rules, and examples. It discloses return values (Automation ID and dashboard link) and notes potential silent failures for send_email if 'from' is missing. However, it does not mention rate limits, authentication requirements, or idempotency.

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

Conciseness4/5

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

The description is long but well-structured with clear sections (Purpose, When to use, Workflow, Returns, Step types, Rules, Examples). It is front-loaded with essential information. While verbose, the length is justified by the tool's complexity; every part serves a purpose.

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

Completeness5/5

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

Given the tool's complexity (3 parameters, nested objects, no output schema), the description is exceptionally complete. It covers all step types, configs, constraints, and provides examples for common patterns. No crucial details are missing for an agent to use it correctly.

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

Parameters5/5

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

Schema coverage is 100%, but the description adds immense value beyond the schema. For the complex 'workflow' parameter, it provides full step type definitions, configs, rules, and three complete examples. The schema only describes the shape; the description explains semantics and constraints (e.g., tree-shaped, no merging).

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

Purpose5/5

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

The description clearly states the purpose: 'Create an automation workflow that triggers on events and executes a sequence of steps.' It distinguishes from siblings like update-automation by focusing on creation, and from send-broadcast by emphasizing automation over one-off sends. The 'When to use' section and examples further clarify its role.

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

Usage Guidelines4/5

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

The description includes a 'When to use' section with specific scenarios (automated email sequences, event-based actions) and a suggested workflow (manage-events → list-templates → ...). It does not explicitly state when not to use it, but the context is clear. The alternative tools like send-broadcast or update-automation are implicitly differentiated.

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/resend/resend-mcp'

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