Skip to main content
Glama
deenesjakoruzh
mailtrap

Mailtrap Email Sending

by mailtrap
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

TypeScript test NPM

MCP Mailtrap Server

An MCP server that provides tools for sending and testing in sandbox via Mailtrap.

Prerequisites

Before using this MCP server, you need to:

  1. Create a Mailtrap account

  2. Verify your domain

  3. Get your API token from Mailtrap API settings

  4. Get your Account ID from Mailtrap account management

Required Environment Variables:

  • MAILTRAP_API_TOKEN - Required for all functionality

  • MAILTRAP_ACCOUNT_ID - Required for templates, stats, email logs, sandbox list/show, and sending domains. Optional only for send-email and send-sandbox-email.

Optional (can be passed as tool parameters instead):

  • DEFAULT_FROM_EMAIL - Default sender email when from is not provided to send-email or send-sandbox-email. Enables switching sender per call via the from parameter.

  • MAILTRAP_TEST_INBOX_ID - Default test inbox ID for sandbox tools when test_inbox_id is not provided. Enables switching between inboxes per call via the test_inbox_id parameter.

Related MCP server: Resend MCP Server

Quick Install

Install in Cursor

Install with Node in VS Code

Smithery CLI

Smithery is a registry installer and manager for MCP servers that works with all AI clients.

npx @smithery/cli install mailtrap

Smithery automatically handles client configuration and provides an interactive setup process. It's the easiest way to get started with MCP servers locally.

Setup

Claude Desktop

Use MCPB to install the Mailtrap server. You can find those files in Releases. Download .MCPB file and open it. If you have Claude Desktop - it will open it and suggest to configure.

Claude Desktop or Cursor

Add the following configuration:

{
  "mcpServers": {
    "mailtrap": {
      "command": "npx",
      "args": ["-y", "mcp-mailtrap"],
      "env": {
        "MAILTRAP_API_TOKEN": "your_mailtrap_api_token",
        "DEFAULT_FROM_EMAIL": "your_sender@example.com",
        "MAILTRAP_ACCOUNT_ID": "your_account_id",
        "MAILTRAP_TEST_INBOX_ID": "your_test_inbox_id"
      }
    }
  }
}

If you are using asdf for managing Node.js you must use absolute path to executable (example for Mac)

{
  "mcpServers": {
    "mailtrap": {
      "command": "/Users/<username>/.asdf/shims/npx",
      "args": ["-y", "mcp-mailtrap"],
      "env": {
        "PATH": "/Users/<username>/.asdf/shims:/usr/bin:/bin",
        "ASDF_DIR": "/opt/homebrew/opt/asdf/libexec",
        "ASDF_DATA_DIR": "/Users/<username>/.asdf",
        "ASDF_NODEJS_VERSION": "20.6.1",
        "MAILTRAP_API_TOKEN": "your_mailtrap_api_token",
        "DEFAULT_FROM_EMAIL": "your_sender@example.com",
        "MAILTRAP_ACCOUNT_ID": "your_account_id",
        "MAILTRAP_TEST_INBOX_ID": "your_test_inbox_id"
      }
    }
  }
}

Claude Desktop config file location

Mac: ~/Library/Application Support/Claude/claude_desktop_config.json

Windows: %APPDATA%\Claude\claude_desktop_config.json

Cursor config file location

Mac: ~/.cursor/mcp.json

Windows: %USERPROFILE%\.cursor\mcp.json

VS Code

Manually changing config

Run in Command Palette: Preferences: Open User Settings (JSON)

Then, in the settings file, add the following configuration:

{
  "mcp": {
    "servers": {
      "mailtrap": {
        "command": "npx",
        "args": ["-y", "mcp-mailtrap"],
        "env": {
          "MAILTRAP_API_TOKEN": "your_mailtrap_api_token",
          "DEFAULT_FROM_EMAIL": "your_sender@example.com",
          "MAILTRAP_ACCOUNT_ID": "your_account_id",
          "MAILTRAP_TEST_INBOX_ID": "your_test_inbox_id"
        }
      }
    }
  }
}
TIP

Don't forget to restart your MCP server after changing the "env" section.

MCP Bundle (MCPB)

For easy installation in hosts that support MCP Bundles, you can distribute an .mcpb bundle file.

# Build TypeScript and pack the MCPB bundle
npm run mcpb:pack

# Inspect bundle metadata
npm run mcpb:info

# Sign the bundle for distribution (optional)
npm run mcpb:sign

This creates mailtrap-mcp.mcpb using the repository manifest.json and built artifacts in dist/.

Usage

Once configured, you can ask agent to send emails and manage templates, for example:

Email Sending Operations:

Email Logs (debug delivery):

  • "List my recent sent email logs"

  • "Show email logs for emails sent to user@example.com"

  • "Get the email log message for ID abc-123-uuid to check delivery status"

Sending Statistics:

  • "Get sending stats for January 2025"

  • "Show delivery rates broken down by domain for last month"

  • "What are my email stats by category from 2025-01-01 to 2025-01-31?"

Sandbox Operations:

  • "Get all messages from my sandbox inbox"

  • "Show me the first page of sandbox messages"

  • "Search for messages containing 'test' in my sandbox inbox"

  • "Show me the details of sandbox message with ID 5159037506"

Template Operations:

  • "List all email templates in my Mailtrap account"

  • "Create a new email template called 'Welcome Email' with subject 'Welcome to our platform!'"

  • "Update the template with ID 12345 to change the subject to 'Updated Welcome Message'"

  • "Delete the template with ID 67890"

Sending Domains:

  • "List my sending domains"

  • "Get sending domain with ID 3938"

  • "Create a sending domain for example.com"

  • "Delete sending domain 3938"

  • "Get sending domain 3938 with DNS setup instructions"

Available Tools

send-email

Sends a transactional email through Mailtrap.

Parameters:

  • to (required): Email address(es) of the recipient(s) - can be a single email or array of emails

  • subject (required): Email subject line

  • from (optional): Email address of the sender, if not provided "DEFAULT_FROM_EMAIL" will be used

  • text (optional): Email body text, required if "html" is empty

  • html (optional): HTML version of the email body, required if "text" is empty

  • cc (optional): Array of CC recipient email addresses

  • bcc (optional): Array of BCC recipient email addresses

  • category (required): Email category for tracking and analytics

list-email-logs

Lists sent email logs (delivery history) with optional pagination and filters. Use to debug delivery issues from the IDE.

Parameters:

  • search_after (optional): Pagination cursor from the previous response's next_page_cursor

  • sent_after (optional): ISO 8601 date/time; only logs sent after this time

  • sent_before (optional): ISO 8601 date/time; only logs sent before this time

  • from_email (optional): Filter by sender email; use with from_operator (default: ci_equal)

  • to_email (optional): Filter by recipient email; use with to_operator (default: ci_equal)

  • status (optional): Filter by delivery status: delivered, not_delivered, enqueued, opted_out; use with status_operator (default: equal)

  • subject (optional): Filter by email subject; use with subject_operator (default: ci_contain). Use subject_operator: empty/not_empty to filter by presence of subject.

  • sending_domain_id (optional): Filter by sending domain ID (number); use with sending_domain_id_operator (default: equal)

  • sending_stream (optional): Filter by stream: transactional or bulk; use with sending_stream_operator (default: equal)

  • events (optional): Filter by event type(s): delivery, open, click, bounce, spam, unsubscribe, soft_bounce, reject, suspension; use with events_operator (include_event / not_include_event)

  • clicks_count / opens_count (optional): Filter by click/open count; use with *_operator: equal, greater_than, less_than

  • client_ip / sending_ip (optional): Filter by IP; use with *_operator: equal, not_equal, contain, not_contain

  • email_service_provider_response (optional): Filter by provider response text; use with *_operator (ci_contain, etc.)

  • email_service_provider (optional): Filter by provider (exact); use with *_operator: equal, not_equal

  • recipient_mx (optional): Filter by recipient MX; use with recipient_mx_operator (ci_contain, etc.)

  • category (optional): Filter by email category; use with category_operator: equal, not_equal

All parameters are optional.

get-email-log-message

Gets a single email log message by ID (UUID): a readable summary (from, to, subject, sent time, status, category, stream, engagement, delivery context), then detailed event history. Optionally, with include_content: true, you can also load and show the message body (HTML and plain text) when Mailtrap exposes a raw message URL.

Parameters:

  • message_id (required): UUID of the email log message (from send response or list-email-logs). Use list-email-logs to find message IDs.

  • include_content (optional): When true, fetches the raw EML (if raw_message_url is available) and appends parsed HTML and plain-text body sections, similar to show-sandbox-email-message.

get-sending-stats

Get email sending statistics (delivery, bounce, open, click, spam rates) for a date range. Optionally break down by domain, category, email service provider, or date. Check delivery rates without leaving the editor.

Parameters:

  • start_date (required): Start date for the stats range (YYYY-MM-DD)

  • end_date (required): End date for the stats range (YYYY-MM-DD)

  • breakdown (optional): How to break down the stats: aggregated (default), by_domain, by_category, by_email_service_provider, or by_date

  • sending_domain_ids (optional): Limit results to these sending domain IDs (array of integers)

  • sending_streams (optional): Limit to transactional and/or bulk (array of strings)

  • categories (optional): Limit to these email categories (array of strings)

  • email_service_providers (optional): Limit to these providers, e.g. Google, Yahoo, Outlook (array of strings)

create-template

Creates a new email template in your Mailtrap account.

Parameters:

  • name (required): Name of the template

  • subject (required): Email subject line

  • html (or text is required): HTML content of the template

  • text (or html is required): Plain text version of the template

  • category (optional): Template category (defaults to "General")

list-templates

Lists all email templates in your Mailtrap account.

Parameters:

  • No parameters required

update-template

Updates an existing email template.

Parameters:

  • template_id (required): ID of the template to update

  • name (optional): New name for the template

  • subject (optional): New email subject line

  • html (optional): New HTML content of the template

  • text (optional): New plain text version of the template

  • category (optional): New category for the template

NOTE

At least one updatable field (name, subject, html, text, or category) must be provided when calling update-template to perform an update.

delete-template

Deletes an existing email template.

Parameters:

  • template_id (required): ID of the template to delete

send-sandbox-email

Sends an email to your Mailtrap test inbox for development and testing purposes. This is perfect for testing email templates without sending emails to real recipients.

Parameters:

  • to (required): Email address(es) of the recipient(s) - can be a single email or array of emails (will be delivered to your test inbox)

  • subject (required): Email subject line

  • from (optional): Email address of the sender, if not provided "DEFAULT_FROM_EMAIL" will be used

  • text (optional): Email body text, required if "html" is empty

  • html (optional): HTML version of the email body, required if "text" is empty

  • cc (optional): Array of CC recipient email addresses

  • bcc (optional): Array of BCC recipient email addresses

  • category (optional): Email category for tracking

NOTE

For sandbox tools, providetest_inbox_id in the tool call or set the MAILTRAP_TEST_INBOX_ID environment variable. You can switch between inboxes per call by passing test_inbox_id.

get-sandbox-messages

Retrieves a list of messages from your Mailtrap test inbox. Useful for checking what emails have been received in your sandbox during testing.

Parameters:

  • page (optional): Page number for pagination (minimum: 1)

  • last_id (optional): Pagination using last message ID. Returns messages after the specified message ID (minimum: 1)

  • search (optional): Search query to filter messages

NOTE

All parameters are optional. If none are provided, the first page of messages from the inbox will be returned. Use page for traditional pagination, last_id for cursor-based pagination, or search to filter messages by content.

show-sandbox-email-message

Shows detailed information and content of a specific email message from your Mailtrap test inbox, including HTML and text body content.

Parameters:

  • message_id (required): ID of the sandbox email message to retrieve

NOTE

Useget-sandbox-messages first to get the list of messages and their IDs, then use this tool to view the full content of a specific message.

list-sending-domains

List sending domains and their DNS verification status.

Parameters:

  • No parameters required

get-sending-domain

Get a sending domain by ID and its verification status (including DNS records). Optionally include DNS setup instructions by setting include_setup_instructions to true.

Parameters:

  • sending_domain_id (required): Sending domain ID

  • include_setup_instructions (optional): If true, append DNS setup instructions to the response. Default: false

create-sending-domain

Create a new sending domain. After creation, add DNS records to verify the domain (use get-sending-domain with include_setup_instructions: true to see the records).

Parameters:

  • domain_name (required): Domain name (e.g. example.com)

delete-sending-domain

Delete a sending domain.

Parameters:

  • sending_domain_id (required): Sending domain ID to delete

Development

  1. Clone the repository:

git clone https://github.com/mailtrap/mailtrap-mcp.git
cd mailtrap-mcp

  1. Install dependencies:

npm install

Configuration with Claude Desktop or Cursor

TIP

See the location of the config file in theSetup section.

Add the following configuration:

{
  "mcpServers": {
    "mailtrap": {
      "command": "node",
      "args": ["/path/to/mailtrap-mcp/dist/index.js"],
      "env": {
        "MAILTRAP_API_TOKEN": "your_mailtrap_api_token",
        "DEFAULT_FROM_EMAIL": "your_sender@example.com",
        "MAILTRAP_ACCOUNT_ID": "your_account_id",
        "MAILTRAP_TEST_INBOX_ID": "your_test_inbox_id"
      }
    }
  }
}

If you are using asdf for managing Node.js you should use absolute path to executable:

(example for Mac)

{
  "mcpServers": {
    "mailtrap": {
      "command": "/Users/<username>/.asdf/shims/node",
      "args": ["/path/to/mailtrap-mcp/dist/index.js"],
      "env": {
        "PATH": "/Users/<username>/.asdf/shims:/usr/bin:/bin",
        "ASDF_DIR": "/opt/homebrew/opt/asdf/libexec",
        "ASDF_DATA_DIR": "/Users/<username>/.asdf",
        "ASDF_NODEJS_VERSION": "20.6.1",
        "MAILTRAP_API_TOKEN": "your_mailtrap_api_token",
        "DEFAULT_FROM_EMAIL": "your_sender@example.com",
        "MAILTRAP_ACCOUNT_ID": "your_account_id",
        "MAILTRAP_TEST_INBOX_ID": "your_test_inbox_id"
      }
    }
  }
}

VS Code

TIP

See the location of the config file in theSetup section.

{
  "mcp": {
    "servers": {
      "mailtrap": {
        "command": "node",
        "args": ["/path/to/mailtrap-mcp/dist/index.js"],
        "env": {
          "MAILTRAP_API_TOKEN": "your_mailtrap_api_token",
          "DEFAULT_FROM_EMAIL": "your_sender@example.com",
          "MAILTRAP_ACCOUNT_ID": "your_account_id",
          "MAILTRAP_TEST_INBOX_ID": "your_test_inbox_id"
        }
      }
    }
  }
}

Testing

You can test the server using the MCP Inspector:

npm run dev

Running the MCPB Server

# Run the MCPB server directly
node dist/mcpb-server.js

# Or use the provided binary
mailtrap-mcpb-server
TIP

For development with the MCP Inspector:

npm run dev:mcpb

Error Handling

This server uses structured error handling aligned with MCP conventions:

  • VALIDATION_ERROR: Input validation failures

  • CONFIGURATION_ERROR: Missing or invalid configuration

  • EXECUTION_ERROR: Runtime execution errors

  • TIMEOUT: Operation timeout (30 seconds default)

Errors include actionable messages and are logged in structured form.

Security

  • Input validated via Zod schemas

  • Environment variables handled securely

  • Timeout protection on operations (30 seconds)

  • Sensitive details sanitized in error output

Logging

Structured JSON logs with levels: INFO, WARN, ERROR, DEBUG.

Enable debug logging by setting DEBUG=true.

# Example: enable debug logging
DEBUG=true node dist/mcpb-server.js

Important: The server writes logs to stderr so stdout remains reserved for JSON-RPC frames. This prevents hosts from encountering JSON parsing errors due to interleaved logs.

Log analysis example using jq:

# Filter error logs
node dist/mcpb-server.js 2>&1 | jq 'select(.level == "error")'

# Filter debug logs
node dist/mcpb-server.js 2>&1 | jq 'select(.level == "debug")'

Troubleshooting

Common issues:

  1. Missing API Token: ensure MAILTRAP_API_TOKEN is set

  2. Sandbox not working: provide test_inbox_id in the tool call or set MAILTRAP_TEST_INBOX_ID env

  3. Timeout errors: check network connectivity and Mailtrap API status

  4. Validation errors: ensure all required fields are provided

Contributing

Bug reports and pull requests are welcome on GitHub. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the code of conduct.

License

The package is available as open source under the terms of the MIT License.

Code of Conduct

Everyone interacting in the Mailtrap project's codebases, issue trackers, chat rooms and mailing lists is expected to follow the code of conduct.

Available Tools

8 tools
create-templateB
Destructive

Create a new email template

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesName of the template
subjectYesEmail subject line
htmlNoHTML content of the template (optional)
textNoPlain text version of the template (optional)
categoryNoTemplate category (optional, defaults to 'General')

TDQS

B3.3/5.0
Behavior3/5

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

The annotations already declare destructiveHint=true, indicating this is a write operation. The description adds minimal behavioral context beyond that - it confirms creation but doesn't specify what happens on success/failure, whether templates are immediately usable, or any permissions required. No contradiction with annotations exists.

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, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a creation tool with good schema documentation and gets straight to the point.

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 creation tool with destructiveHint annotation and no output schema, the description is minimally adequate. It identifies the resource type but doesn't explain what an email template entails in this system, how it's used, or what the creation result looks like. The combination of basic description and annotations provides the essentials but leaves contextual gaps.

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?

With 100% schema description coverage, all parameters are documented in the schema. The description adds no additional parameter information beyond what's already in the schema descriptions. The baseline score of 3 reflects adequate but not enhanced parameter documentation.

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 ('create') and resource ('email template'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'update-template' beyond the obvious verb difference, nor does it specify what distinguishes a template from other email-related resources in the system.

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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like needing to be logged in), when to choose this over 'update-template' for existing templates, or how it relates to email-sending tools like 'send-email' or 'send-sandbox-email'.

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

delete-templateA
Destructive

Delete an existing email template

ParametersJSON Schema
NameRequiredDescriptionDefault
template_idYesID of the template to delete

TDQS

A3.5/5.0
Behavior4/5

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

The annotations already declare destructiveHint=true, indicating this is a destructive operation. The description adds value by specifying 'Delete an existing email template,' which reinforces the destructive nature and clarifies the resource type. However, it doesn't provide additional behavioral details like confirmation prompts, error handling, or permissions required beyond what annotations imply.

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 unnecessary words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse. Every word earns its place.

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?

Given the tool's destructive nature (annotations cover this) and simple single-parameter schema, the description is adequate but minimal. It lacks output information (no schema provided) and doesn't address error cases or dependencies on other tools (e.g., needing to list templates first). For a destructive tool, more context would be beneficial.

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, with the 'template_id' parameter fully documented. The description doesn't add any parameter-specific information beyond what the schema provides, such as format examples or constraints. Since the schema coverage is high, the 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 clearly states the action ('Delete') and resource ('an existing email template'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'update-template' or 'list-templates' in terms of scope or intent, which prevents a perfect score.

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 provides no guidance on when to use this tool versus alternatives like 'update-template' or 'list-templates', nor does it mention prerequisites (e.g., needing a valid template_id). It simply states what the tool does without contextual usage information.

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

get-sandbox-messagesC

Get list of messages from the sandbox test inbox

ParametersJSON Schema
NameRequiredDescriptionDefault
pageNoPage number for pagination
last_idNoPagination using last message ID. Returns messages after the specified message ID.
searchNoSearch query to filter messages

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but lacks details on permissions, rate limits, response format, or whether this is a read-only operation. For a list operation with zero annotation coverage, this leaves significant 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, efficient sentence that directly states the tool's purpose without unnecessary words or redundancy, making it appropriately front-loaded and concise.

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 lack of annotations and output schema, the description is incomplete. It doesn't explain the return format, pagination behavior beyond schema hints, or how it interacts with sibling tools, leaving the agent with insufficient context for a list operation.

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 schema description coverage is 100%, so the schema fully documents all three parameters (page, last_id, search). The description adds no additional parameter semantics beyond what the schema provides, meeting the baseline for high coverage.

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 'Get' and resource 'list of messages from the sandbox test inbox', making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'show-sandbox-email-message' which might retrieve a single message, leaving some ambiguity about scope.

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 provides no guidance on when to use this tool versus alternatives like 'show-sandbox-email-message' or 'send-sandbox-email', nor does it mention any prerequisites or contextual constraints for usage.

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

list-templatesB
Read-only

List all email templates

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.4/5.0
Behavior3/5

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

The description adds minimal behavioral context beyond the readOnlyHint annotation. It doesn't specify whether this returns a paginated list, the format of returned templates, or any rate limits. However, it doesn't contradict the annotation (which correctly indicates a read-only 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 a single, efficient sentence with zero wasted words. It's appropriately sized for a simple list operation and front-loads the core purpose immediately.

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 read-only list tool with no parameters and no output schema, the description is minimally adequate. However, it lacks details about the return format (e.g., structured list vs. raw data) and doesn't leverage the sibling context to clarify its role in the template management workflow.

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?

With 0 parameters and 100% schema description coverage, the description appropriately doesn't need to explain parameters. The baseline for this scenario is 4 since there are no parameters to document.

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 ('List') and resource ('all email templates'), making the purpose unambiguous. However, it doesn't differentiate from potential sibling tools like 'get-sandbox-messages' or explain what distinguishes listing templates from other template operations.

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 provides no guidance on when to use this tool versus alternatives like 'create-template', 'update-template', or 'delete-template'. It doesn't mention prerequisites, context for listing templates, or any exclusions.

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

send-emailB
Destructive

Send an email to your recipient email address using Mailtrap Email API. You can send emails to multiple recipients at once.

ParametersJSON Schema
NameRequiredDescriptionDefault
fromNoEmail address of the sender
toYesEmail address(es) of the recipient(s) - can be a single email or array of emails
subjectYesEmail subject line
ccNoOptional CC recipients
bccNoOptional BCC recipients
categoryYesEmail category for tracking
textNoEmail body text
htmlNoOptional HTML version of the email body

TDQS

B3.2/5.0
Behavior3/5

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

The annotations include 'destructiveHint: true', indicating this is a write operation with potential side effects. The description adds that it uses 'Mailtrap Email API' and supports multiple recipients, providing some context beyond annotations. However, it doesn't disclose additional behavioral traits like rate limits, authentication needs, or what 'destructive' entails (e.g., email delivery, no undo). With annotations covering the safety profile, a 3 is appropriate for adding moderate value.

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 concise with two sentences: one stating the purpose and one adding a usage detail. It's front-loaded with the core functionality. However, the second sentence could be more informative (e.g., clarifying 'multiple recipients' vs. schema details), slightly reducing 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?

Given the tool's complexity (8 parameters, destructive operation) and lack of output schema, the description is moderately complete. It covers the basic purpose and API context but lacks details on when to use, behavioral nuances, or return values. With annotations providing some safety info, it's adequate but has clear gaps for a mutation tool.

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, with clear documentation for all 8 parameters (e.g., 'from' as 'Email address of the sender'). The description doesn't add meaning beyond the schema, such as explaining parameter interactions or constraints. According to the rules, with high schema coverage (>80%), the baseline is 3 even without param info in the description.

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's purpose: 'Send an email to your recipient email address using Mailtrap Email API.' It specifies the action (send), resource (email), and technology (Mailtrap Email API). However, it doesn't explicitly differentiate from sibling tools like 'send-sandbox-email' or 'get-sandbox-messages', which would require a 5.

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 provides minimal usage guidance: 'You can send emails to multiple recipients at once.' It doesn't specify when to use this tool versus alternatives like 'send-sandbox-email' (e.g., for testing vs. production), nor does it mention prerequisites, exclusions, or context for use. This lack of explicit guidance limits its effectiveness.

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

send-sandbox-emailA

Send an email in sandbox mode to a test inbox without delivering to your recipients

ParametersJSON Schema
NameRequiredDescriptionDefault
fromYesEmail address of the sender
toYesEmail addresses (comma-separated or single)
subjectYesEmail subject line
ccNoOptional CC recipients
bccNoOptional BCC recipients
categoryNoOptional email category for tracking
textNoEmail body text
htmlNoOptional HTML version of the email body

TDQS

A4.4/5.0
Behavior4/5

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

The description adds valuable behavioral context beyond the annotations. While annotations only indicate destructiveHint=false (non-destructive), the description clarifies that emails go to a 'test inbox' and won't reach actual recipients, which is crucial for understanding the tool's testing/simulation behavior. No contradiction with annotations exists.

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, efficient sentence that front-loads the key information (sandbox mode, test inbox, no delivery) with zero wasted words. Every element serves a clear purpose in distinguishing this tool's behavior.

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 tool with good annotations (destructiveHint=false) and full schema coverage, the description provides sufficient context about the sandbox/testing behavior. The main gap is the lack of output schema, but the description compensates by clarifying the test inbox destination. It adequately covers the tool's purpose and usage context.

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?

With 100% schema description coverage, all parameters are well-documented in the schema itself. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3 for adequate coverage without extra 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 clearly states the specific action ('send an email') and resource ('in sandbox mode to a test inbox'), with explicit differentiation from normal email sending ('without delivering to your recipients'). It distinguishes from the sibling 'send-email' tool by specifying the sandbox/testing context.

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?

The description explicitly states when to use this tool ('in sandbox mode to a test inbox') and when not to use it ('without delivering to your recipients'), providing clear context for testing versus production email sending. It implicitly contrasts with the sibling 'send-email' tool for actual delivery.

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

show-sandbox-email-messageB

Show sandbox email message details and content from the sandbox test inbox

ParametersJSON Schema
NameRequiredDescriptionDefault
message_idYesID of the sandbox email message to retrieve

TDQS

B3.1/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 states 'show' implies a read operation, but doesn't disclose behavioral traits like whether it requires authentication, rate limits, error handling (e.g., invalid message_id), or what 'details and content' includes (e.g., headers, body, attachments). This leaves significant gaps for a 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 a single, efficient sentence with zero waste. It's front-loaded with the core purpose and includes essential context ('from the sandbox test inbox'), making it appropriately sized for a simple tool.

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?

Given 1 parameter with full schema coverage and no output schema, the description is minimally adequate. It specifies the resource scope ('sandbox test inbox') but lacks behavioral details (e.g., response format, error cases) and usage guidelines, leaving room for improvement despite the tool's low complexity.

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, with 'message_id' documented as 'ID of the sandbox email message to retrieve'. The description adds no additional parameter semantics beyond this, such as format examples or constraints. Baseline 3 is appropriate when schema does the heavy lifting.

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 'show' and the resource 'sandbox email message details and content', specifying it's from the 'sandbox test inbox'. It distinguishes from siblings like 'get-sandbox-messages' (which likely lists messages) and 'send-sandbox-email' (which sends messages), but doesn't explicitly contrast them in the description text.

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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid message_id from the sandbox), exclusions, or comparisons to sibling tools like 'get-sandbox-messages' for listing messages first.

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

update-templateB
Destructive

Update an existing email template

ParametersJSON Schema
NameRequiredDescriptionDefault
template_idYesID of the template to update
nameNoNew name for the template
subjectNoNew email subject line
htmlNoNew HTML content of the template
textNoNew plain text version of the template
categoryNoNew category for the template

TDQS

B3.2/5.0
Behavior3/5

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

The annotations include 'destructiveHint: true', which already indicates this is a mutation operation. The description adds minimal behavioral context beyond this, as 'Update an existing email template' implies modification but doesn't detail effects like whether changes are reversible, permission requirements, or rate limits. With annotations covering the destructive nature, the description provides basic but insufficient additional insight.

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, efficient sentence with zero wasted words, front-loading the core action ('Update') and resource. It's appropriately sized for the tool's complexity, making it easy for an agent to parse quickly without unnecessary elaboration.

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 complexity (6 parameters, destructive operation, no output schema), the description is inadequate. It lacks information on return values, error conditions, or how partial updates are handled (e.g., if only some fields are provided). With annotations covering only destructiveness, more context is needed for safe and effective use.

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, with each parameter clearly documented (e.g., 'template_id' as 'ID of the template to update'). The description adds no extra meaning beyond what the schema provides, such as explaining relationships between parameters or usage examples. Baseline 3 is appropriate since the schema does the heavy lifting.

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 resource ('an existing email template'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'create-template' or 'list-templates' beyond the basic action, missing explicit comparison that would earn a perfect score.

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 provides no guidance on when to use this tool versus alternatives like 'create-template' for new templates or 'delete-template' for removal. It also doesn't mention prerequisites (e.g., needing an existing template ID) or contextual constraints, leaving the agent to infer usage from the name alone.

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.

  1. 8 tool updatesv1.0.0
    • Addedcreate-template
    • Addeddelete-template
    • Addedget-sandbox-messages
    • Addedlist-templates
    • Changedsend-email8 fields changed
      • removedInput schema / $schema
        Removed value: -"http://json-schema.org/draft-07/schema#"
      • changedInput schema / properties / category / description
        Previous value: -"Optional email category for tracking"New value: +"Email category for tracking"
      • changedInput schema / properties / from / description
        Previous value: -"Email address of the sender (optional with default)"New value: +"Email address of the sender"
      • changedInput schema / properties / to / description
        Previous value: -"Email address of the recipient"New value: +"Email address(es) of the recipient(s) - can be a single email or array of emails"
      • removedInput schema / properties / to / format
        Removed value: -"email"
      • addedInput schema / properties / to / oneOf
        Added value: +[
+  {
+    "description": "Single email address",
+    "format": "email",
+    "type": "string"
+  },
+  {
+    "description": "Array of email addresses",
+    "items": {
+      "format": "email",
+      "type": "string"
+    },
+    "type": "array"
+  }
+]
      • removedInput schema / properties / to / type
        Removed value: -"string"
      • changedInput schema / required
        Previous value: -[
-  "to",
-  "subject"
-]New value: +[
+  "to",
+  "subject",
+  "category"
+]
    • Addedsend-sandbox-email
    • Addedshow-sandbox-email-message
    • Addedupdate-template
  2. 1 tool update
    • First observedsend-email
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored across 8 tools

Disambiguation5/5

Every tool has a clearly distinct purpose with no ambiguity. Template management tools (create, delete, list, update) are separate from sandbox operations (get messages, send sandbox email, show message) and production email sending, making misselection unlikely.

Naming Consistency4/5

Mostly consistent with a verb-noun pattern using kebab-case, but there is a minor deviation: 'get-sandbox-messages' and 'show-sandbox-email-message' both retrieve sandbox data with different verbs ('get' vs 'show'), slightly breaking the pattern.

Tool Count5/5

Well-scoped with 8 tools, each earning its place. This covers core email sending workflows (production and sandbox) and template management (CRUD operations), fitting the server's purpose without being overwhelming.

Completeness5/5

Complete coverage for the email sending domain with no obvious gaps. It includes full CRUD for templates, sandbox testing (send, list, view), and production email sending, allowing agents to handle all typical email workflows without dead ends.

Maintenance

ActivityActive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • SMTP MCP Server

    samihalawa
    A
    license
    A
    quality
    C
    maintenance
    Enables sending emails via SMTP with template management, supporting multiple SMTP configurations, template creation with variable substitution, and bulk email sending with rate limiting.
    6
    301 npm
    23
    MIT

  • SendLayer MCP Server

    gyrationtechs
    F
    license
    B
    quality
    Not graded
    maintenance
    Enables sending emails and managing webhooks through the SendLayer API. Supports plain text and HTML emails with attachments, CC/BCC recipients, and webhook event management for email delivery tracking.
    5
    -

  • sparkpost-mcp

    Pcummings
    A
    license
    B
    quality
    D
    maintenance
    Enables sending transactional emails, managing templates, suppression lists, sending domains, webhooks, subaccounts, and retrieving account metrics via the SparkPost API.
    20
    9 npm
    MIT

Appeared in Searches