Skip to main content
Glama
resend

Email Sending MCP

by resend

Create Automation

create-automation

Automate email sequences triggered by events. Build workflows that send emails, apply delays, check conditions, and wait for events, enabling drip campaigns and re-engagement.

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.
Behavior5/5

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

With no annotations, the description carries full responsibility and delivers thoroughly. It specifies behavior for each step type, fallback semantics for 'from'/'subject', error modes (silent failure, run error), structural rules (tree-shaped, reachability), and return value (Automation ID and dashboard link). This is exceptionally transparent.

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?

Although lengthy, the description is meticulously structured with headers, bullet points, and examples. It front-loads purpose and usage, and every section serves a functional need given the tool's complexity. No filler.

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 high complexity (nested steps, multiple step types, branching rules), the description fully equips the agent to construct valid workflows. It covers all step types, config schemas, constraints, and return values, with multiple examples.

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?

The schema already has 100% description coverage, but the tool description goes far beyond schema definitions. It explains the exact structure of workflow steps, config objects, operator semantics, dynamic variables, and provides three complete examples. This adds immense meaning beyond the schema.

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?

Clearly states 'create an automation workflow that triggers on events and executes a sequence of steps.' This is a specific verb and resource, and it differentiates from sibling tools that update, remove, or get automations.

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?

Provides a dedicated 'When to use' section listing two concrete scenarios (automated email sequences, event-based actions). It also references a workflow with prerequisite tools, but does not explicitly mention when not to use or alternatives like update-automation, so it stops short of a 5.

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