What can you do with this server?

This server gives AI assistants full access to the Resend transactional email API through natural language, covering email sending, domain management, API key management, and contact/audience management. Email Sending * Send a single transactional email with HTML or plain text, Cc/Bcc, Reply-To, custom headers, and scheduled delivery * Send batch emails (up to 100 in a single API call) * List recent sent emails and their delivery status * Get full details of a specific email by ID Domain Management * Create, list, verify DNS records for, and delete sending domains API Key Management * Create API keys with full, sending, or domain-scoped permissions * List active API keys (tokens hidden) and delete them by ID Audience & Contact Management * Create and list audiences for organizing contacts * Full CRUD operations on contacts within audiences, including managing subscription status Additional Capabilities * Automate email workflows (e.g., sending welcome emails, auditing infrastructure) via conversational prompts * Built-in rate-limiting and automatic retry on 429 errors to stay within Resend's API limits * Compatible with any MCP client such as Claude Desktop, Cursor, or Windsurf

Which integrations are available for this server?

Allows sending transactional emails, managing sending domains, API keys, and audience contacts via the Resend API.

Resend MCP Server

by friendlygeorge

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Resend MCP Server

An MCP server for Resend — connect any MCP-compatible client to the Resend transactional email API.

npm version npm downloads License: MIT MCP Compatible TypeScript Claude Desktop Cursor

What is this?

An MCP (Model Context Protocol) server that gives AI assistants and agents full access to Resend's email API — send single or batch emails, manage sending domains, API keys, audiences, and contacts — through natural language.

Use it with Claude Desktop, Cursor, Windsurf, Cline, Continue, or any MCP-compatible client to send emails, manage infrastructure, and build automation around email.

Related MCP server: Resend MCP

Why use this?

18 built-in tools — covers sending (single + batch), domains, API keys, audiences, and contacts
Send emails by talking — "send a welcome email to jane@example.com" just works
Manage your infrastructure — create/verify/delete domains, mint/revoke API keys, manage contacts
Batch sending — send up to 100 emails in a single API call
Full contact CRUD — create, read, update, and delete contacts across audiences
Rate-limited automatically — respects Resend's 10 req/s free tier, retries on 429
Works with every MCP client — Claude Desktop, Cursor, Windsurf, Cline, Continue, and more

Quick Start

Add to your MCP client config (e.g. claude_desktop_config.json):

{
  "mcpServers": {
    "resend": {
      "command": "npx",
      "args": ["-y", "resend-mcp-server"],
      "env": {
        "RESEND_API_KEY": "re_xxxxxxxxxxxx"
      }
    }
  }
}

Get a free API key at resend.com/api-keys.

Use it

Ask your AI assistant things like:

"Send an email to jane@example.com thanking her for signing up"
"List the last 5 emails I sent"
"What happened to email ID abc-123?"
"Create a new sending domain for mail.acme.com"
"Verify domain domain-xyz"
"Mint a new API key called 'production-server'"
"Add jane@example.com to audience audience-1"

Tools

Tool	Description
`send_email`	Send a transactional email (HTML or plain text, with Cc/Bcc/Reply-To)
`send_batch_email`	Send up to 100 emails in a single API call
`list_emails`	List recent sent emails with their delivery status
`get_email`	Get details for a specific email by ID
`create_domain`	Add a new sending domain
`list_domains`	List all sending domains in your account
`verify_domain`	Trigger DNS verification for a domain
`delete_domain`	Remove a sending domain
`create_api_key`	Create a new API key (full, sending, or domain-scoped)
`list_api_keys`	List all API keys (tokens are hidden)
`delete_api_key`	Delete an API key by ID
`list_audiences`	List all audiences in your account
`create_audience`	Create a new audience for organizing contacts
`list_contacts`	List contacts in an audience
`get_contact`	Get details for a specific contact by ID
`create_contact`	Add a new contact to an audience
`update_contact`	Update a contact's email, name, or subscription status
`delete_contact`	Remove a contact from an audience

Use Cases

Transactional Email Automation

"Send a welcome email to every new signup" — automate onboarding flows, receipts, and notifications through natural language. No more switching between email dashboards.

Domain Management

"Add mail.acme.com as a sending domain and verify it" — manage DNS records, DKIM, and SPF through your AI assistant instead of logging into Resend's dashboard.

Contact & Audience Management

"Add jane@example.com to my VIP audience" — build and segment contact lists without touching a spreadsheet. Full CRUD on contacts and audiences.

Batch Campaigns

"Send this newsletter to all contacts in audience-1" — batch-send up to 100 emails in one call. Perfect for newsletters, product announcements, or re-engagement campaigns.

Infrastructure Audit

"List all my API keys and domains" — audit your Resend setup in seconds. See which keys are active, which domains are verified, and clean up stale resources.

Security

API key required — Resend API key is passed via environment variable, never logged or stored in files.
No local file access — does not read or write any files on your machine.
No shell access — does not execute commands or spawn processes.
Rate-limited — automatically caps requests at ~9 req/s to stay within Resend's free tier.
Open source — MIT licensed. Inspect the code at GitHub.

Troubleshooting

Rate limit errors (429)

The server auto-retries on 429 with a 2s backoff. Free tier allows 10 req/s. The server caps at ~9 req/s to stay safe. If you hit this frequently, consider upgrading your Resend plan.

"Invalid API key" errors

Verify your RESEND_API_KEY starts with re_ and is active at resend.com/api-keys. Keys take up to 30 seconds to propagate after creation.

Server won't start

Make sure Node.js 18+ is installed: node --version. If using npx, ensure npm is up to date: npm install -g npm@latest.

MCP client can't connect

Verify the config path is correct. Claude Desktop uses ~/Library/Application Support/Claude/claude_desktop_config.json on macOS and %APPDATA%\Claude\claude_desktop_config.json on Windows. Restart the client after config changes.

Emails not delivering

Check list_emails for delivery status. Common issues: missing DNS records (run verify_domain), bounce due to invalid address, or domain not yet verified. Resend's dashboard shows detailed webhook events.

Requirements

Node.js 18+
A Resend account and API key (RESEND_API_KEY)

Rate Limits

The server automatically rate-limits requests to ~9 calls/second to stay safely under Resend's free-tier limit of 10 req/s. If you hit a 429 anyway, it waits 2s and retries once.

Development

git clone https://github.com/friendlygeorge/resend-mcp-server.git
cd resend-mcp-server
npm install
npm run build
RESEND_API_KEY=re_xxxx npm start

License

MIT

Available Tools

18 tools

create_api_keyA

Create a new Resend API key (token is only returned once)

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Friendly name for the key (e.g. 'production-server')
`permission`	No	Permission scope (default: full_access)	full_access
`domain_id`	No	Restrict key to a specific domain (for sending_access)

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations provided, the description carries full burden. It does disclose that the token is only returned once, which is critical, but lacks other behavioral details like side effects or required permissions.

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 a single, focused sentence with a key parenthetical note. It is efficient and front-loaded with the action.

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

Completeness3/5

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

The description mentions the token-only-once behavior, which is good, but does not explain the response format or include other contextual details that would be helpful given no output schema.

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?

The input schema has 100% description coverage for all 3 parameters, so the description adds no additional semantic value beyond what the schema already provides. Baseline score is appropriate.

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 'Create a new Resend API key' with the specific verb 'Create' and resource 'API key', and adds a notable behavior. It is well-distinguished from sibling tools which handle contacts, domains, and emails.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives or any prerequisites. The description only states what it does without contextual usage advice.

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

create_audienceB

Create a new audience for organizing contacts

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Audience name (e.g. 'Newsletter Subscribers')

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full burden. It only says 'create', implying mutation, but does not disclose what happens if the audience already exists, any side effects, or required permissions.

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 a single concise sentence with no wasted words. However, it could be slightly longer to improve clarity without losing conciseness.

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

Completeness3/5

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

For a simple create tool with one parameter and no output schema, the description is minimally complete. It lacks information about return values or side effects.

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 100% for the single parameter 'name', and the description does not add extra meaning beyond the schema. Baseline 3 is appropriate.

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 verb 'Create' and resource 'audience', and it distinguishes from sibling tools like create_contact by specifying 'audience for organizing contacts'.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives (e.g., list_audiences or create_contact). The description does not mention prerequisites or context.

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

create_contactB

Add a new contact to a Resend audience

ParametersJSON Schema

Name	Required	Description
`audience_id`	Yes	Audience ID
`email`	Yes	Contact email address
`first_name`	No	First name
`last_name`	No	Last name
`unsubscribed`	No	Whether the contact is unsubscribed

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided, so description must disclose behavior. It only states 'Add' but omits details like idempotency, uniqueness constraints, or side effects.

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?

Single clean sentence, no wasted words, front-loaded with verb and resource.

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

Completeness2/5

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

With 5 parameters, no output schema, and no annotations, the description is too brief. Missing details on return value and behavioral nuances.

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 coverage is 100% with descriptions for all parameters. Description adds no extra meaning beyond schema, meeting baseline for good schema coverage.

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?

Description clearly states the action ('Add a new contact') and the specific resource ('to a Resend audience'), distinguishing it from sibling tools like create_api_key or create_domain.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives (e.g., list_contacts for viewing). Implied usage only through action verb.

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

create_domainB

Create a new sending domain in Resend

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Domain name (e.g. 'mail.acme.com')
`region`	No	AWS region (default: us-east-1)

TDQS

B3.2/5.0

Behavior2/5

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

No annotations exist, so the description must disclose behavior. It does not mention that created domains require verification, DNS record setup, or other side effects. The description is too brief for a mutation tool.

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 a single, clear sentence with no wasted words. It is efficient and immediately conveys the purpose.

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

Completeness2/5

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

For a creation tool with 2 parameters and no output schema, more context is needed (e.g., verification requirements, DNS records, return value). The description lacks completeness.

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 100%, so the schema already documents both parameters. The description adds no additional meaning beyond the schema for 'name' and 'region'.

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 'Create a new sending domain in Resend', specifying the action (create), resource (sending domain), and system (Resend). This clearly distinguishes from sibling tools like verify_domain and list_domains.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like verify_domain or list_domains. No preconditions or context for usage are provided.

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

delete_api_keyB

Delete a Resend API key by ID

ParametersJSON Schema

Name	Required	Description	Default
`key_id`	Yes	API key ID (from list_api_keys)

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description carries full burden for behavioral disclosure. It only states the action without explaining consequences (e.g., irreversibility, cascading effects, required permissions). This is insufficient for a delete operation.

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 a single sentence with no wasted words. However, it could be expanded to include key behavioral information without losing conciseness.

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

Completeness2/5

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

For a single-parameter delete tool with no output schema, the description is too minimal. It lacks details on success indicators or prerequisites beyond the param description.

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 coverage is 100% with key_id described, so baseline is 3. The description adds no extra 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?

The description clearly states the verb 'Delete', the resource 'Resend API key', and the method 'by ID'. It is specific and distinguishes this tool from siblings like create_api_key or list_api_keys.

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

Usage Guidelines3/5

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

No explicit guidance on when to use this tool or alternatives. Usage is implied from the action 'Delete', but no context on prerequisites or when not to use.

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

delete_contactC

Remove a contact from an audience

ParametersJSON Schema

Name	Required	Description	Default
`audience_id`	Yes	Audience ID
`contact_id`	Yes	Contact ID

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided; description carries full burden. It says 'Remove' but does not disclose whether deletion is permanent, reversible, or what side effects occur (e.g., impact on audiences or history).

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

Conciseness2/5

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

Description is a single sentence, but it omits crucial behavioral context that should be included. Under-specified rather than conciseness.

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

Completeness2/5

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

For a deletion tool with no output schema and no annotations, the description should at minimum indicate permanence or side effects. It is incomplete.

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 coverage is 100% with basic descriptions ('Audience ID', 'Contact ID'), but the tool description adds no additional meaning beyond these. Baseline 3 for high coverage.

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?

Description clearly states the action ('Remove'), the resource ('a contact'), and the scope ('from an audience'). It distinguishes from sibling tools like create_contact, update_contact, and get_contact.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives (e.g., archiving or deactivating a contact). No prerequisites or context for deletion.

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

delete_domainB

Remove a sending domain from your Resend account

ParametersJSON Schema

Name	Required	Description	Default
`domain_id`	Yes	Domain ID (from list_domains)

TDQS

B3.2/5.0

Behavior2/5

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

The description implies a destructive action ('Remove'), but does not disclose consequences, reversibility, permissions required, or any side effects. With no annotations, the burden falls on the description, which is insufficient.

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 a single concise sentence that immediately conveys the tool's purpose with no wasted words.

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

Completeness2/5

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

For a deletion action with no output schema, the description is incomplete. It does not mention what happens upon success or failure, or any return values. The description should clarify the expected outcome.

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 coverage is 100% and the single parameter 'domain_id' is already well described in the schema. The description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.

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 verb ('Remove') and the resource ('a sending domain from your Resend account'). It effectively distinguishes the tool from sibling tools like create_domain, list_domains, and verify_domain.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool, prerequisites, or alternatives. The description simply states what it does without context for decision-making.

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

get_contactB

Get details about a specific contact by ID

ParametersJSON Schema

Name	Required	Description	Default
`audience_id`	Yes	Audience ID
`contact_id`	Yes	Contact ID

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It only states 'get details' (implying read-only) but omits permissions, rate limits, or what 'details' encompasses. Insufficient for safe agent use.

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?

One sentence, no wasted words. Could be slightly more informative but remains front-loaded and efficient.

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

Completeness2/5

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

No output schema and description fails to specify what 'details' are returned (e.g., name, email). Incomplete for a retrieval tool; agent cannot anticipate response structure.

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 covers both parameters with descriptions (100% coverage). The description adds no additional meaning beyond 'by ID', so baseline 3 is appropriate.

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 'Get details about a specific contact by ID' uses a specific verb ('get') and resource ('contact by ID'), clearly distinguishing it from sibling tools like create_contact, delete_contact, update_contact, and list_contacts.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like list_contacts or update_contact. No explicit when-not-to-use or context about prerequisites.

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

get_emailB

Get details about a specific email by ID

ParametersJSON Schema

Name	Required	Description	Default
`email_id`	Yes	Email ID (from send_email or list_emails)

TDQS

B3.4/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It only states 'get details' without disclosing what details are included, read-only status, permissions, or any side effects. For a tool with no annotations, this is insufficient behavioral context.

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?

Single sentence with no wasted words. Front-loaded and appropriately sized for the tool's simplicity.

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

Completeness2/5

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

Given no output schema, the description should indicate what details are returned or error conditions. It is too minimal for a tool that returns complex data. Agent lacks understanding of response structure.

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 coverage is 100%, so baseline is 3. Description does not add any extra meaning beyond what the schema already provides for the email_id parameter. No parameter information is included in the description.

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?

Description clearly states verb 'Get', resource 'details about a specific email', and method 'by ID'. It distinguishes from sibling tools like list_emails (which lists multiple) and send_email (which sends).

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

Usage Guidelines3/5

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

Description implies usage for retrieving a single email by ID, but does not explicitly state when to use this tool versus list_emails or other siblings. No exclusions or alternative guidance provided.

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

list_api_keysA

List all API keys in your Resend account (tokens are hidden)

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries full behavioral disclosure. It explicitly states that 'tokens are hidden', which is an important behavioral trait for security awareness. However, it does not mention other potential behaviors like ordering or rate limits.

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 a single, clear sentence that conveys the purpose and a key behavioral note. No wasted words; front-loaded with the primary action.

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

Completeness4/5

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

Given no parameters and no output schema, the description is largely complete. It explains what the tool does and a critical security behavior. It could mention whether results are paginated or ordered, but overall it sufficiently informs agent selection.

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?

The tool has no parameters (0 params, 100% schema coverage). Per guidelines, baseline is 4. The description adds no parameter information, but none is needed. The mention of 'in your Resend account' provides context 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?

The description clearly states the action ('List'), the resource ('all API keys'), and the scope ('in your Resend account'). It also adds a crucial detail that tokens are hidden, distinguishing it from tool names like create_api_key.

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

Usage Guidelines3/5

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

No explicit guidance on when to use this tool versus alternatives like create_api_key. However, the context of listing vs. creating is implied. For a simple list tool with no parameters, the lack of explicit usage guidelines is acceptable but not ideal.

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

list_audiencesB

List all audiences in your Resend account

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Max audiences to return (default 20)

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided, so description must cover behavioral traits. It only states the action without disclosing pagination, permissions, or rate limits, adding minimal value beyond the name.

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?

One clear sentence, front-loaded with key information. Could be slightly improved with additional context, but wastes no words.

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

Completeness3/5

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

For a simple list tool, the description is adequate but lacks details on return values or filtering behavior. Schema covers parameters, so overall complete enough.

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 100%, with the limit parameter already documented. The description adds no extra meaning, conforming to the baseline.

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 'List all audiences' with specific verb and resource. Among sibling tools, there is no other 'list_audiences', making it distinguishable.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives or when not to use it. The description is purely functional without context.

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

list_contactsB

List contacts in a Resend audience

ParametersJSON Schema

Name	Required	Description	Default
`audience_id`	Yes	Audience ID (e.g. from your Resend dashboard)
`limit`	No	Max contacts to return (default 20)

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description must cover behavior. It does not explicitly state that the operation is read-only (no destructive hints), does not mention authentication requirements, rate limits, or what happens if the audience_id is invalid. The default limit of 20 is mentioned in the schema but not in the description.

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 a single, efficient sentence. It is front-loaded with the key information. However, it could be slightly longer to add essential behavioral context without losing conciseness.

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

Completeness2/5

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

Given the simplicity of the tool (2 params, no output schema, no annotations), the description is minimal. It lacks details about return format, error handling, sorting order, or whether pagination supports cursors. A listing tool should provide enough context for an agent to understand the response structure.

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 100%, so the schema already documents both parameters. The description adds no additional meaning beyond the schema's descriptions (e.g., audience_id is 'Audience ID (e.g. from your Resend dashboard)'). Baseline 3 is appropriate.

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 'List contacts in a Resend audience' clearly states the action (list) and resource (contacts) within a specific scope (in a Resend audience). It distinguishes well from sibling tools like create_contact (create vs list) and list_domains (different resource).

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool vs alternatives, such as whether to use it for initial retrieval or if there are prerequisites like an existing audience. No mentions of filtering, sorting, or when not to use it (e.g., for large datasets where pagination might be needed).

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

list_domainsA

List all sending domains in your Resend account

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Max domains to return (default 20)

TDQS

A4/5.0

Behavior4/5

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

No annotations exist, so the description carries the full burden. The description implies a read-only list operation, which is clear. However, it does not mention pagination behavior beyond the limit parameter, leaving some behavioral gaps.

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 a single sentence, no filler words, and front-loads the key purpose. Each word earns its place.

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

Completeness4/5

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

For a simple list tool with no output schema, the description adequately states what it returns. It lacks details on default ordering or field structure, but overall is sufficient.

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 100%; the description adds no additional meaning beyond the schema's 'Max domains to return'. Baseline score of 3 is appropriate.

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 verb 'list' and resource 'sending domains' with explicit scope 'in your Resend account'. It distinguishes from sibling tools like create_domain or verify_domain by focusing on listing.

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

Usage Guidelines3/5

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

No explicit guidance on when to use this tool versus alternatives like list_api_keys. The context implies usage for retrieving domains, but no when-not-to-use or exclusion criteria are provided.

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

list_emailsC

List recent emails sent via Resend

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Max emails to return (default 20)

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It does not disclose read-only nature, potential side effects, rate limits, or sorting/pagination behavior beyond the limit parameter. Critical behavioral traits are omitted.

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 a single sentence, front-loaded with the key action and resource. It contains no fluff, but could be considered too brief to add sufficient value.

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

Completeness2/5

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

For a tool with no output schema and no annotations, the description is incomplete. It does not clarify what 'recent' means, whether results are paginated, or that the operation is read-only. Despite simplicity, it lacks basic context for safe invocation.

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 coverage is 100% for the single parameter 'limit', which already includes default and description. The description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.

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

Purpose4/5

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

The description uses a specific verb 'List' and identifies the resource 'recent emails sent via Resend', making the action clear. However, it does not explicitly differentiate from sibling list tools like list_api_keys or list_contacts, which also use 'list'.

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

Usage Guidelines2/5

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

The description implies usage for viewing recent sent emails but provides no when-not-to-use guidance, nor does it mention alternatives like get_email for individual email retrieval. No exclusions or context for tool selection.

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

send_batch_emailA

Send multiple transactional emails in a single API call (up to 100)

ParametersJSON Schema

Name	Required	Description	Default
`emails`	Yes	Array of email objects (1-100)

TDQS

A3.6/5.0

Behavior2/5

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

With no annotations provided, the description bears full burden. It only states the action and batch limit, missing critical behavioral details such as idempotency, error handling, rate limits, or destructive potential for a write operation.

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 one concise sentence that front-loads the action and key constraint (batch size). Every word earns its place.

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

Completeness2/5

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

Given no output schema, no annotations, and a batch operation, the description is incomplete. It doesn't clarify return value, error behavior, or whether the batch is atomic.

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 coverage is 100% and the description adds no extra meaning beyond what the schema provides (batch size limit already in maxItems). Baseline score of 3 is appropriate.

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 verb 'Send' and the resource 'multiple transactional emails', and includes a distinguishing feature 'in a single API call (up to 100)', which differentiates it from the sibling 'send_email' tool.

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 implies when to use this tool (sending multiple emails at once) and implicitly excludes alternatives (e.g., use send_email for single emails). However, it lacks explicit guidance on when not to use or trade-offs like atomicity or partial failures.

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

send_emailB

Send a transactional email via Resend

ParametersJSON Schema

Name	Required	Description
`from`	Yes	Sender address (e.g. 'Acme <noreply@acme.com>')
`to`	Yes	Recipient address(es)
`subject`	Yes	Email subject line
`html`	No	HTML body
`text`	No	Plain text body
`cc`	No	Cc address(es)
`bcc`	No	Bcc address(es)
`reply_to`	No	Reply-To address(es)
`scheduled_at`	No	ISO 8601 datetime to schedule the email
`headers`	No	Custom headers as key/value pairs

TDQS

B3/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It does not disclose behavioral traits such as delivery guarantees, rate limits, authentication requirements, or that the operation is irreversible. The description is too brief for a mutation tool.

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

Conciseness3/5

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

The description is a single sentence, which is concise but lacks structure. It is too minimal to convey necessary behavioral or usage context.

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

Completeness2/5

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

With 10 parameters including nested objects, no output schema, and no annotations, the description is insufficient. It does not explain the return value, error conditions, or details about scheduling and custom headers.

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 coverage is 100%, so the schema already documents all parameters. The description adds no additional meaning beyond the schema, earning a baseline score of 3.

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

Purpose4/5

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

The description clearly states the tool sends a transactional email via Resend, which is specific and actionable. There are no sibling tools for sending email, so no differentiation needed.

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

Usage Guidelines3/5

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

No explicit guidance on when to use vs alternatives, but the context of 'transactional' implies it's for individual outbound emails. No sibling email tools exist, so the need for usage guidelines is reduced.

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

update_contactC

Update an existing contact's properties

ParametersJSON Schema

Name	Required	Description
`audience_id`	Yes	Audience ID
`contact_id`	Yes	Contact ID
`email`	No	New email address
`first_name`	No	New first name
`last_name`	No	New last name
`unsubscribed`	No	Unsubscribe status

TDQS

C2.8/5.0

Behavior2/5

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

No annotations exist, so the description must fully convey behavioral traits. It only says 'update' implying mutation, but fails to disclose error cases (e.g., if contact doesn't exist), update strategy (partial vs. full), or side effects. This is insufficient for safe invocation.

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

Conciseness3/5

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

The description is a single sentence, which is concise, but it lacks structural elements like separate sections for behavior or return value. It is somewhat under-specified for a tool with 6 parameters.

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

Completeness2/5

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

Given the tool's 6 parameters, no output schema, and no annotations, the description is too brief. It does not explain return values, error handling, or the effect of optional fields, making it incomplete for an AI agent to use confidently.

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?

All 6 parameters have descriptions in the input schema (100% coverage), so the baseline is 3. The tool description adds no additional meaning beyond the schema, e.g., relationships between parameters or usage hints.

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

Purpose4/5

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

The description clearly states the verb 'update' and the resource 'contact's properties', making the purpose understandable. However, it does not differentiate from sibling tools like create_contact or delete_contact, though the action is distinct enough.

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

Usage Guidelines2/5

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

No guidance provided on when to use this tool versus alternatives or any prerequisites. The description merely states the basic function without context or exclusions.

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

verify_domainB

Trigger verification of a domain's DNS records

ParametersJSON Schema

Name	Required	Description	Default
`domain_id`	Yes	Domain ID (from create_domain or list_domains)

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations, the description carries full burden but only states 'trigger verification' without revealing whether it is synchronous, requires permissions, or any side effects.

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?

One concise sentence, no fluff. Could benefit from a bit more detail without losing efficiency.

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

Completeness3/5

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

For a simple trigger tool, the description is minimally adequate but lacks information on expected outcomes, timing, or error cases.

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?

The schema has 100% description coverage; the description adds context by noting the domain_id comes from create_domain or list_domains, which helps the agent source the value.

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 uses a specific verb-resource pair ('trigger verification of a domain's DNS records'), clearly distinguishing it from sibling tools like create_domain or list_domains.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives, prerequisites (e.g., domain must exist), or what happens after triggering.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

8 tool updatesv1.1.3Jun 12, 2026
- Addedcreate_audience
- Addeddelete_api_key
- Addeddelete_contact
- Addeddelete_domain
- Addedget_contact
- Addedlist_audiences
- Addedsend_batch_email
- Addedupdate_contact
10 tool updatesv1.0.0Jun 7, 2026
- First observedcreate_api_key
- First observedcreate_contact
- First observedcreate_domain
- First observedget_email
- First observedlist_api_keys
- First observedlist_contacts
- First observedlist_domains
- First observedlist_emails
- First observedsend_email
- First observedverify_domain

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool targets a distinct resource and action. Send_email vs send_batch_email are clearly differentiated by batch vs single. CRUD operations for each resource are separate and unambiguous.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using lowercase snake_case (e.g., create_api_key, list_domains). No mixing of styles or inconsistent verbs.

Tool Count5/5

18 tools cover the main resources of an email service (API keys, audiences, contacts, domains, emails) without being excessive. Each tool serves a clear purpose.

Completeness5/5

The tool surface provides full CRUD for API keys (create, list, delete), domains (create, list, delete, verify), audiences (create, list), contacts (create, list, get, update, delete), and emails (send, send_batch, get, list). No obvious gaps for typical email API operations.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

email A
dev.primitive
Email infrastructure for AI agents — send, receive, search, and reply to email over MCP.
Email Communication
302
AgenticEmail A
dev.agenticemail
Hosted email for AI agents: create inboxes, send, receive, and reply over MCP with scoped API keys
Email Communication
2
ZapierOAuth
com.zapier
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
App Automation Workplace & Productivity
2297
AgentMailOAuth
to.agentmail
Email inboxes for AI agents: send, receive, reply, search, and manage threaded email over MCP.
Email Communication
2

Related MCP Servers

Resend MCP Server
Communication App Automation
huazhengwang
F
license
Not graded
quality
D
maintenance
An MCP (Multi-Agent Conversation Protocol) Server for interacting with Resend's email API, auto-generated using AG2's MCP builder to enable sending emails through natural language.
Updated a year ago (2025-07-07 16:19 UTC)
-
Resend MCP
Communication App Automation Developer Tools
pidanmeng
A
license
Not graded
quality
D
maintenance
Enables sending emails through the Resend service API. Provides a simple email sending tool that integrates with MCP-compatible clients.
Updated 9 months ago (2025-11-30 10:29 UTC)
29
MIT
PostStack MCP Server
Email Marketing App Automation
getpoststack
A
license
A
quality
D
maintenance
An MCP server for the PostStack email API that enables AI assistants to send transactional emails, manage contacts, handle inbound email threads, and perform deliverability checks through 84 curated tools.
Updated 3 months ago (2026-05-27 18:47 UTC)
84
29
1
MIT
email-mcp-server
Email Communication
egyptianego17
A
license
A
quality
C
maintenance
An MCP server that enables AI assistants to send emails via SMTP, supporting simple and custom emails with attachments and CC/BCC, plus connection testing.
Updated 7 months ago (2026-02-17 00:15 UTC)
3
28
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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

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