Skip to main content
Glama
resend

Email Sending MCP

by resend

Create Broadcast

create-broadcast

Set up a broadcast email for a segment by specifying subject, body, and segment ID, then send it later with send-broadcast.

Instructions

Purpose: Create a broadcast campaign (one email sent to an entire segment). Defines subject, body, and segment; does NOT send yet. Use send-broadcast to send it.

NOT for: Sending a one-off email to specific people (use send-email). Not for adding contacts (use create-contact).

Returns: Broadcast ID. Use this ID with send-broadcast to send, or get-broadcast/update-broadcast to manage.

When to use:

  • User wants to "email my list", "send a newsletter", "broadcast to my segment", "email all contacts in X"

  • Newsletter, announcement, or bulk message to one segment

  • Supports personalization: {{{FIRST_NAME}}}, {{{LAST_NAME}}}, {{{EMAIL}}}, {{{RESEND_UNSUBSCRIBE_URL}}}

"All contacts" note: Broadcasts require a segment. There is no "all contacts" option in the API. If the user wants to send to all contacts, check list-segments for an existing segment that covers everyone. If none exists, suggest creating one with create-segment.

Workflow: list-segments (if needed) → create-broadcast → get-tiptap-json-content (with include_schema: true) → compose-broadcast → send-broadcast.

Content options after creating:

  • compose-broadcast (recommended): Sets TipTap content that the user can visually edit in the Resend dashboard. Use this when the user wants to collaborate on or refine the email in the editor.

  • update-broadcast with html/text: Sets static HTML/text content. Use this only when the user explicitly wants to set raw HTML. Switching between compose and html/text modes is lossy — some content or formatting may be lost. Ask the user before switching.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fromYesFrom email address (e.g. "onboarding@resend.com" or "Resend <onboarding@resend.com>")
htmlNoHTML version of the email content. Placeholders: {{{FIRST_NAME|fallback}}}, {{{LAST_NAME|fallback}}}, {{{EMAIL}}}, {{{RESEND_UNSUBSCRIBE_URL}}}. Email HTML requirements — follow all of these without exception: STRUCTURE - Always include <!DOCTYPE html>, <html>, <head>, <body> - Layout must be table-based: <table>, <tr>, <td> — never use <div> for layout - Outer wrapper table at width="100%", inner content table at max 600px wide - Every table must have cellpadding="0" cellspacing="0" border="0" CSS - All styles must be inline (style="...") — no <style> tag, no external stylesheets - No flexbox, no grid, no CSS variables, no CSS shorthand (use padding-top not padding) - font-family must always include web-safe fallbacks (Arial, Helvetica, Georgia, sans-serif) - Always set font-size, line-height, and color explicitly on every text element IMAGES - Always set width, height, border="0", display:block on every <img> - Use absolute URLs only — no relative paths - Always include alt text LINKS & BUTTONS - Never use <button> — use <a> styled as a button inside a <td> - No <video>, <form>, or <input> elements - No JavaScript of any kind OUTLOOK COMPATIBILITY - Use bgcolor attribute on <td> alongside CSS background-color - No CSS background-image (poor Outlook support) - Add <!--[if mso]> conditionals where needed for Outlook rendering META (in <head>) - <meta charset="UTF-8"> - <meta name="viewport" content="width=device-width, initial-scale=1.0"> - <meta http-equiv="X-UA-Compatible" content="IE=edge">
nameYesName for the broadcast. If the user does not provide a name, go ahead and create a descriptive name for them, based on the email subject/content and the context of your conversation.
textNoPlain text version of the email content. The following placeholders may be used to personalize the email content: {{{FIRST_NAME|fallback}}}, {{{LAST_NAME|fallback}}}, {{{EMAIL}}}, {{{RESEND_UNSUBSCRIBE_URL}}}. If omitted, HTML will be used to generate it. Pass an empty string to disable automatic text generation.
replyToNoReply-to email address(es)
subjectYesEmail subject
segmentIdYesSegment ID to send to
previewTextNoPreview text for the email
Behavior5/5

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

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: 'does NOT send yet', requires a segment ('There is no all contacts option'), personalization placeholders, and that switching between compose and html/text modes is lossy. This is substantial context beyond a simple create action.

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 long but highly structured with bold headers, bullet points, and sections. Every sentence serves a purpose: purpose, exclusions, return value, when-to-use, workflow, content options. Front-loaded with the most critical information. No fluff.

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 8 parameters, no annotations, and no output schema, the description is exceptionally complete. It covers returns, workflow, personalization, segment requirements, alternatives, and content-authoring modes. This provides a full operating context for an AI agent.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful parameter context by explaining when to use html/text vs compose-broadcast, and clarifies that the name can be auto-generated. It also notes the 'all contacts' limitation relevant to segmentId. This goes beyond schema descriptions.

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 explicitly states the purpose: 'create a broadcast campaign (one email sent to an entire segment)'. It clearly distinguishes from send-broadcast, send-email, and create-contact with specific 'NOT for' examples. The verb+resource+scope is specific and unambiguous.

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

Usage Guidelines5/5

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

Provides explicit guidance on when to use: user intents like 'email my list', 'send a newsletter', 'broadcast to my segment'. Also includes 'NOT for' exclusions and a clear workflow (list-segments → create-broadcast → get-tiptap-json-content → compose-broadcast → send-broadcast). Names alternatives such as send-email and create-contact.

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