The GetMailer MCP Server enables AI assistants like Claude to send and manage transactional emails through the GetMailer service via the MCP protocol.
Account Management: Sign up for GetMailer accounts directly from Claude and check account status including email verification, subscription plan, and sending limits.
Email Operations: Send transactional emails with HTML/text content, CC/BCC recipients, reply-to addresses, and template variables. List sent emails with pagination, retrieve detailed delivery events and tracking information, and create batch email jobs for sending personalized emails to multiple recipients with progress monitoring.
Template Management: List existing email templates and create new ones with dynamic subjects, HTML content, and variable placeholders for reusable email formats.
Domain Management: List verified sending domains, add new domains with DNS records for verification, and check domain verification status.
Analytics & Monitoring: Access email analytics as summary or daily statistics, and track performance metrics including sent, delivered, bounced, and complained emails.
Suppression List Management: View suppressed email addresses and add addresses to suppression lists with reasons (bounce, complaint, or manual entry) to prevent sending to specific addresses.
Integration: Works with Claude Desktop, supports global installation and npx execution, and can be configured with environment variables.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@GetMailer MCP Server send a welcome email to newuser@example.com from hello@myapp.com"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP (Model Context Protocol) server for GetMailer - Send transactional emails from AI assistants like Claude.
The fastest way to get started is to sign up directly through MCP:
1. Add the MCP server to Claude Desktop (no API key needed yet):
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"getmailer": {
"command": "npx",
"args": ["getmailer-mcp"]
}
}
}2. Ask Claude to sign you up:
"Sign me up for GetMailer with email user@example.com and password MyPassword123"
3. Claude will return your API key. Update your config:
{
"mcpServers": {
"getmailer": {
"command": "npx",
"args": ["getmailer-mcp"],
"env": {
"GETMAILER_API_KEY": "gm_your_api_key_here"
}
}
}
}4. Restart Claude Desktop and start sending emails!
Related MCP server: Unosend MCP Server
npm install -g getmailer-mcpIf you already have an API key, add this to your Claude Desktop configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"getmailer": {
"command": "npx",
"args": ["getmailer-mcp"],
"env": {
"GETMAILER_API_KEY": "gm_your_api_key_here"
}
}
}
}Or if installed globally:
{
"mcpServers": {
"getmailer": {
"command": "getmailer-mcp",
"env": {
"GETMAILER_API_KEY": "gm_your_api_key_here"
}
}
}
}Create a new GetMailer account directly from Claude. Returns an API key and sends a verification email.
Important: You must verify your email before you can send emails. Check your inbox after signing up!
Parameters:
email (required): Your email address (no disposable emails)
password (required): Password (min 8 chars, must include uppercase, lowercase, and number)
name: Your name (optional)
Example:
Sign me up for GetMailer with my email developer@example.comCheck your account status including email verification, subscription plan, and sending limits.
Parameters: None
Example:
Check my GetMailer account statusReturns:
Email verification status
Subscription plan and remaining emails
Number of verified domains
Whether you can send emails
Any required actions (verify email, add domain, etc.)
Send a transactional email.
Parameters:
from (required): Sender email address
to (required): Array of recipient addresses
subject (required): Email subject
html: HTML content
text: Plain text content
cc: CC recipients
bcc: BCC recipients
replyTo: Reply-to address
templateId: Template ID (instead of html/text)
variables: Template variables
Example:
Send an email from hello@myapp.com to user@example.com with subject "Welcome!" and HTML content "<h1>Hello!</h1>"List sent emails with status information.
Parameters:
limit: Number of emails to return (default: 20)
cursor: Pagination cursor
Get details of a specific email including delivery events.
Parameters:
id (required): Email ID
List available email templates.
Create a new email template.
Parameters:
name (required): Template name
subject (required): Subject line (can include {{variables}})
html (required): HTML content (can include {{variables}})
text: Plain text content
List verified sending domains.
Add a new sending domain.
Parameters:
domain (required): Domain name (e.g., example.com)
Returns DNS records that need to be configured.
Check if a domain has been verified.
Parameters:
id (required): Domain ID
Get email analytics and statistics.
Parameters:
type: "summary" or "daily"
days: Number of days for daily stats
List suppressed email addresses.
Parameters:
limit: Number of entries to return
Add email addresses to the suppression list.
Parameters:
emails (required): Array of email addresses
reason: MANUAL, BOUNCE, or COMPLAINT
Create a batch email job.
Parameters:
name (required): Batch name
from (required): Sender address
recipients (required): Array of {to, variables} objects
subject: Email subject
html: HTML content
text: Plain text content
templateId: Template ID
replyTo: Reply-to address
List batch email jobs.
Get batch job status and progress.
Parameters:
id (required): Batch ID
Once configured, you can ask Claude:
"Send an email to user@example.com from notifications@myapp.com saying their order has shipped"
"List my recent emails"
"Check the status of email abc123"
"Create an email template for password resets"
"Show me my email analytics for the past week"
"Add user@spam.com to my suppression list"
GETMAILER_API_KEY: Your GetMailer API key (optional for signup, required for other tools)
GETMAILER_API_URL: Custom API URL (default: https://getmailer.app)
Option 1: Sign up via MCP (Recommended)
Use the signup tool directly from Claude - no web browser needed!
Option 2: Sign up via web
Sign up at getmailer.app
Go to API Keys
Create a new API key
Documentation: getmailer.app/docs
Issues: GitHub Issues
Add a new sending domain (returns DNS records to configure)
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain name to add (e.g., example.com) |
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 indicates a write operation ('Add') and mentions the output ('returns DNS records to configure'), but fails to disclose critical traits such as permissions required, whether the operation is idempotent, potential side effects, or error conditions. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and resource, followed by the key outcome. There is no wasted verbiage, and every word earns its place, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (a write operation with one parameter) and lack of annotations and output schema, the description is minimally adequate. It covers the basic purpose and output but omits details on usage context, behavioral traits, and error handling. This results in a description that meets the bare minimum but leaves the agent with unanswered questions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'domain' well-documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, such as format constraints or examples. Given the high schema coverage, a baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and resource ('new sending domain'), making the purpose immediately understandable. It distinguishes this from sibling tools like 'list_domains' or 'verify_domain' by focusing on creation rather than listing or verification. However, it doesn't explicitly contrast with all siblings, keeping it from 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.
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 'verify_domain' or other domain-related operations. It mentions the return value ('returns DNS records to configure'), which hints at a post-creation step, but lacks explicit when-to-use or when-not-to-use instructions, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add email addresses to the suppression list
| Name | Required | Description | Default |
|---|---|---|---|
| emails | Yes | Email addresses to suppress | |
| reason | No | Reason for suppression (default: MANUAL) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions adding to a suppression list (implying a write/mutation operation) but doesn't address critical aspects like permissions needed, whether the action is reversible, rate limits, or what happens if emails are already suppressed. This leaves significant gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It lacks information about behavioral traits (e.g., idempotency, error handling), expected outcomes, or how this tool relates to siblings like 'list_suppression'. The agent would need to guess about many operational aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters (emails array and reason enum). The description doesn't add any parameter-specific context beyond what's in the schema, such as format requirements for emails or implications of different reason values, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and target resource ('email addresses to the suppression list'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_suppression' or explain what a suppression list is, preventing 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'list_suppression' or 'list_emails', nor about prerequisites such as whether emails must be verified first. The description only states what it does, not when it should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a batch email job to send to multiple recipients
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Batch job name | |
| from | Yes | Sender email address | |
| subject | No | Email subject (can include {{variables}}) | |
| html | No | HTML content (can include {{variables}}) | |
| text | No | Plain text content (optional) | |
| templateId | No | Template ID to use instead of html/text (optional) | |
| recipients | Yes | Array of recipients with optional per-recipient variables | |
| replyTo | No | Reply-to address (optional) |
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. While 'create' implies a write operation, the description doesn't address critical behavioral aspects: whether this is an asynchronous job, what permissions are required, if there are rate limits, what happens on failure, or what the expected output looks like. It mentions the action but lacks operational context needed 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise - a single sentence that communicates the core purpose without any wasted words. It's front-loaded with the essential information and earns its place efficiently. No structural issues or unnecessary elaboration are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex mutation tool with 8 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't address the asynchronous nature implied by 'batch job', doesn't explain what happens after creation, doesn't mention error handling, and provides no context about how this integrates with sibling tools. The agent lacks critical operational understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 all 8 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain relationships between parameters (e.g., 'html' vs 'templateId'), provide examples, or clarify edge cases. The baseline score of 3 reflects adequate but minimal value addition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Create a batch email job to send to multiple recipients'. It specifies the verb ('create'), resource ('batch email job'), and scope ('to multiple recipients'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'send_email' or 'create_template', which would be needed for 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.
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. There's no mention of when to choose 'create_batch' over 'send_email' (for single emails) or 'create_template' (for reusable templates), nor any context about prerequisites, timing considerations, or exclusions. The agent must infer usage from the name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new email template
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Template name | |
| subject | Yes | Email subject (can include {{variables}}) | |
| html | Yes | HTML content (can include {{variables}}) | |
| text | No | Plain text content (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it creates a template without disclosing behavioral traits. It doesn't mention permissions required, whether creation is idempotent, rate limits, or what happens on success/failure (e.g., returns a template ID). This leaves significant gaps 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after creation (e.g., returns a template ID for use in 'send_email'), error conditions, or dependencies on other tools like 'verify_domain'. More context is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters (name, subject, html, text). The description adds no additional meaning beyond implying these parameters are used for creation, which is already clear from the tool name. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('new email template'), making the purpose immediately understandable. However, it doesn't distinguish this from sibling tools like 'list_templates' or 'get_email', which would require mentioning it's specifically for creation rather than retrieval or listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. There's no mention of prerequisites (e.g., needing a verified domain), when not to use it, or how it differs from sibling tools like 'send_email' or 'create_batch' for email-related tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get email analytics and statistics
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Type of analytics (summary or daily) | |
| days | No | Number of days for daily stats (default: 30) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what the tool does, not how it behaves. It doesn't disclose whether this is a read-only operation, what permissions are needed, if there are rate limits, or what format the analytics return. This is inadequate 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.
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 and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficient. It doesn't explain what analytics are returned, their format, or any behavioral constraints. The agent would be guessing about the tool's behavior and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information beyond what's already in the schema (which has 100% coverage). It doesn't explain what 'summary' vs 'daily' analytics include, or how the 'days' parameter affects results. 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'email analytics and statistics', making the purpose immediately understandable. However, it doesn't differentiate this tool from potential sibling analytics tools (none exist in the sibling list), so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. There's no mention of prerequisites, context, or comparison with other tools like 'get_email' or 'list_emails' that might provide related data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get batch job status and progress
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Batch ID |
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 this is a 'Get' operation, implying it's read-only, but doesn't confirm safety aspects like whether it requires authentication, has rate limits, or what happens with invalid IDs. The description adds minimal behavioral context beyond the basic action, leaving gaps for a tool that likely interacts with batch processing systems.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 ('Get batch job status and progress'), and every word earns its place by specifying what is retrieved. No unnecessary details or redundancy are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of batch job operations, the lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'status and progress' entails (e.g., success/failure states, percentage completion, error messages) or the return format. For a tool with potential behavioral nuances, this minimal description leaves too much unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'id' parameter documented as 'Batch ID'. The description doesn't add any meaning beyond this (e.g., explaining where to find the ID or its format). According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('batch job status and progress'), making the purpose immediately understandable. It doesn't specifically differentiate from sibling tools like 'list_batches' or 'create_batch', but the focus on retrieving status/progress for a specific batch is clear. No tautology or misleading elements are present.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'list_batches' (which likely lists multiple batches) or 'create_batch' (which creates new batches). There's no mention of prerequisites (e.g., needing a batch ID from a previous operation) or context for when this specific retrieval is appropriate. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific email including delivery events
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Email ID |
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 mentions 'delivery events' as part of the details, which adds some context beyond a basic read operation, but fails to address critical aspects like permissions needed, rate limits, error conditions, or whether the operation is idempotent. For a tool 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.
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 any wasted words. It is appropriately sized and front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single parameter read operation), no annotations, and no output schema, the description is minimally adequate. It specifies the resource and includes 'delivery events' as extra detail, but lacks information on return values, error handling, or behavioral constraints, leaving room for improvement in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'id' clearly documented as 'Email ID'. The description does not add any additional meaning or context about the parameter beyond what the schema provides, such as format examples or sourcing guidance. With high schema coverage, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'details of a specific email including delivery events', which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'list_emails' or 'get_batch', 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.
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 'list_emails' or 'get_batch', nor does it mention prerequisites or exclusions. It only states what the tool does, not when to apply it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List batch email jobs
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'List batch email jobs' implies a read-only operation but doesn't specify whether it returns all batches, supports pagination, includes metadata (e.g., status, dates), or has rate limits. For a list tool with zero annotation coverage, this is a significant gap in transparency about how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('List batch email jobs') with zero wasted words. It is front-loaded and directly states the core functionality without unnecessary elaboration. This is appropriately sized for a simple list tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is minimally complete. It states what the tool does but lacks behavioral details (e.g., return format, pagination) that would be helpful for an agent. Without annotations or output schema, the description should ideally provide more context about the listing behavior, but it's adequate for basic understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so the schema fully documents the lack of inputs. The description doesn't add parameter details, which is appropriate since there are none. Baseline is 4 for 0 parameters, as no compensation is needed, and the description correctly implies no filtering or options are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List batch email jobs' clearly states the verb ('List') and resource ('batch email jobs'), making the purpose immediately understandable. It distinguishes from siblings like 'get_batch' (which likely retrieves a single batch) and 'create_batch' (which creates one), though it doesn't explicitly differentiate them. The purpose is specific but lacks explicit sibling comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, context (e.g., after creating batches), or exclusions (e.g., not for filtering or analytics). With siblings like 'get_batch' for single batches and 'get_analytics' for performance data, the lack of usage guidelines leaves the agent to infer based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List verified sending domains
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 only states what the tool does ('List verified sending domains') without explaining what 'verified' means, how results are returned (e.g., pagination, format), or any constraints like rate limits or authentication needs. This leaves significant gaps for a tool that likely interacts with a domain management system.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place by conveying essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema), the description is adequate as a minimum viable explanation. However, it lacks context about what 'verified' entails, how results are structured, or any behavioral traits, which could be important for an AI agent to use it effectively. Without annotations or output schema, more detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, but it appropriately doesn't mention any. A baseline of 4 is applied for zero-parameter tools when the schema is fully covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('verified sending domains'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_batches' or 'list_templates' beyond the resource type, 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.
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. For example, it doesn't specify if this should be used before 'verify_domain' or after 'add_domain', nor does it mention any prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List sent emails with status information
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of emails to return (default: 20) | |
| cursor | No | Pagination cursor for next page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'status information' but doesn't disclose behavioral traits like pagination behavior (implied by cursor parameter), rate limits, authentication needs, or what specific statuses are returned. For a list operation with no annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 a clarifying detail ('with status information'). Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (list operation with pagination), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavior, output format, or usage context. It meets the minimum viable threshold but has clear gaps in completeness for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 (limit and cursor) fully. The description doesn't add any parameter-specific meaning beyond what the schema provides, such as default behavior or usage examples. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('sent emails'), specifying scope with 'with status information'. It distinguishes from siblings like 'get_email' (singular) and 'send_email' (action), but doesn't explicitly differentiate from other list tools like 'list_batches' or 'list_templates'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 is provided. It doesn't mention prerequisites, context for listing sent emails specifically, or compare with siblings like 'get_email' for single emails or 'list_batches' for batch operations. The description only states what it does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List suppressed email addresses (bounced, complained, or manually added)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of entries to return (default: 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions what types of suppressions are included but doesn't cover pagination behavior, sorting, default ordering, error conditions, or authentication requirements. For a list operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without unnecessary words. It's appropriately sized for a simple list operation and front-loads the essential information immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter and no output schema, the description is adequate but incomplete. It covers what's being listed but lacks context about return format, typical result structure, or how results are organized. Without annotations or output schema, more behavioral context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter, so the schema already documents the 'limit' parameter fully. The description adds no parameter-specific information beyond what's in the schema. This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List') and resource ('suppressed email addresses'), with explicit scope details ('bounced, complained, or manually added'). It distinguishes this tool from siblings like list_domains or list_emails by focusing on suppression status rather than general listings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. While the purpose is clear, there's no mention of prerequisites, typical use cases, or how it differs from other list operations like list_emails or get_email. The description assumes context without providing it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available email templates
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 ('List') but doesn't describe what 'available' means (e.g., all templates, only active ones), whether it requires authentication, pagination behavior, rate limits, or the return format. This leaves significant gaps for a tool that presumably returns data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('List available email templates') that front-loads the core action and resource. It wastes no words, making it easy to parse quickly, which is ideal for a simple tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters) and lack of output schema, the description is minimal. However, with no annotations to cover behavioral aspects like safety or return format, and the description not addressing these, it's incomplete. For a list operation, agents need to know what 'available' entails and the response structure, which is missing here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, and since there are none, it doesn't need to compensate for any gaps. A baseline of 4 is given as it avoids unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List available email templates' clearly states the verb ('List') and resource ('email templates'), making the purpose immediately understandable. It distinguishes from siblings like 'create_template' (creation) and 'list_emails' (different resource), though it doesn't explicitly differentiate from 'list_batches' or 'list_domains' beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 templates to exist), exclusions, or comparisons to siblings like 'get_email' or 'list_emails', leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a transactional email via GetMailer
| Name | Required | Description | Default |
|---|---|---|---|
| from | Yes | Sender email address (must be from a verified domain) | |
| to | Yes | Recipient email address(es) | |
| subject | Yes | Email subject line | |
| html | No | HTML content of the email | |
| text | No | Plain text content of the email | |
| cc | No | CC recipients (optional) | |
| bcc | No | BCC recipients (optional) | |
| replyTo | No | Reply-to address (optional) | |
| templateId | No | Template ID to use instead of html/text (optional) | |
| variables | No | Template variables as key-value pairs (optional) |
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. While 'Send' implies a write operation, the description doesn't mention authentication requirements, rate limits, delivery guarantees, error handling, or what happens on success/failure. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps that could affect agent decision-making.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for the tool's complexity and immediately communicates the core function without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't address critical context like authentication requirements, rate limits, error conditions, or what constitutes a successful operation. The agent would need to guess about behavioral aspects that should be documented for a tool that sends emails.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 all 10 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send') and resource ('transactional email via GetMailer'), making the purpose immediately understandable. However, it doesn't differentiate this from potential sibling tools like 'create_batch' or other email-related operations, which would require more specific context about what makes this 'transactional' versus other email types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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_batch' or template-based operations. It mentions 'transactional email' but doesn't explain what that means in practice or when other tools might be more appropriate. There are no usage prerequisites, exclusions, or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if a domain has been verified
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Domain ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It doesn't disclose whether this is a read-only operation, what permissions are required, what the response format looks like, or how verification status is determined. The description simply restates the basic function without adding meaningful behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise at just 6 words, front-loading the essential information with zero wasted words. Every word earns its place in communicating the core function without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a verification tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'verified' means in this context, what verification entails, what the response will contain, or how this differs from simply listing domains. The minimal description leaves too many contextual questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents the single 'id' parameter adequately. The description doesn't add any additional context about parameter meaning, format expectations, or how to obtain domain IDs. This meets the baseline for high schema coverage but doesn't enhance understanding beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Check') and resource ('domain'), making it immediately understandable. However, it doesn't differentiate from sibling tools like 'list_domains' or 'get_analytics' which might also provide domain status information, preventing 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.
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. With siblings like 'list_domains' that might show verification status, there's no indication whether this tool is for checking a specific domain's verification status after adding it, or if it's the preferred method over other listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose targeting specific resources and actions in the email sending domain. For example, add_domain vs verify_domain handle different aspects of domain management, while send_email vs create_batch address different email sending scenarios. No tools appear to overlap in functionality.
All tools follow a consistent verb_noun naming pattern throughout (e.g., add_domain, create_batch, get_analytics, list_templates). The verbs are appropriate and predictable (add, create, get, list, send, verify), and the snake_case convention is uniformly applied across all 14 tools.
With 14 tools, this server is well-scoped for an email sending service, covering domain management, email sending (transactional and batch), templates, analytics, and suppression lists. Each tool earns its place by addressing a distinct aspect of the workflow, avoiding both excessive bloat and critical omissions.
The tool set provides complete CRUD/lifecycle coverage for the email sending domain. It includes creation (add_domain, create_batch, create_template), retrieval (get_analytics, get_batch, get_email, list_* tools), and operational actions (send_email, verify_domain, add_to_suppression). No obvious gaps exist; agents can manage the full email workflow from setup to analytics.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Transactional email for AI agents: templates, domain verify, and sends.
Send transactional emails for AI agents via SMTP. Templates included.
Email for AI agents — send, receive as a webhook, manage domains, templates, routing.
Send, track, and manage transactional and bulk email delivery
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/getplatform/getmailer-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
