What can you do with this server?

This server allows AI agents to send and manage emails through EmailJS with the following capabilities: * send_email: Send emails using pre-configured EmailJS templates by providing a template_id and dynamic template_params (key-value pairs mapping to template variables). * validate_config: Validate EmailJS credentials (Service ID, Public Key, Template ID) before sending. Note: this performs a real send with empty params, which may consume quota or deliver an email. * get_email_history: Fetch a paginated history of emails sent through your EmailJS account (up to 100 records per page). Requires both a public key and private key for authentication. * Multi-account & Flexible Credentials: Credentials can be set via environment variables or passed directly as tool call parameters (tool call parameters take priority), enabling use of multiple EmailJS accounts within the same session.

How do I use mcp-emailjs?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-emailjs Send an email with template 'contact' to user@example.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-emailjs

by ElizioMartins

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

mcp-emailjs

An MCP (Model Context Protocol) server for EmailJS — lets AI agents like Claude send emails, validate configurations, and query email history directly through EmailJS.

⚠️ Required: enable non-browser API access

EmailJS blocks API calls from non-browser environments by default. Since this MCP server runs as a server process (not a browser), you must enable API access or send_email will fail with:

403: API access from non-browser environments is currently disabled.

To enable it:

Go to EmailJS Account → Security
Turn on "Allow EmailJS API for non-browser applications"
Save

get_email_history works without this, but send_email and validate_config require it.

Related MCP server: email-mcp

Tools

Tool	Description
`send_email`	Send an email using an EmailJS template with dynamic parameters
`validate_config`	Validate credentials and template ID before sending
`get_email_history`	Retrieve history of emails sent via your EmailJS account

Known limitations

Templates cannot be created or edited programmatically. EmailJS does not expose a public API for template management — templates must be created and edited through the EmailJS dashboard. This MCP can only use existing templates (by their template_id), not create them.

If you'd like EmailJS to add a template-management API, please 👍 and comment on the feature request: emailjs-sdk#70.

Installation

Claude Desktop

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "emailjs": {
      "command": "npx",
      "args": ["-y", "mcp-emailjs"],
      "env": {
        "EMAILJS_SERVICE_ID": "your_service_id",
        "EMAILJS_PUBLIC_KEY": "your_public_key",
        "EMAILJS_PRIVATE_KEY": "your_private_key"
      }
    }
  }
}

Config file location:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

Cursor / other MCP clients

{
  "mcpServers": {
    "emailjs": {
      "command": "npx",
      "args": ["-y", "mcp-emailjs"],
      "env": {
        "EMAILJS_SERVICE_ID": "your_service_id",
        "EMAILJS_PUBLIC_KEY": "your_public_key",
        "EMAILJS_PRIVATE_KEY": "your_private_key"
      }
    }
  }
}

Environment Variables

Variable	Required	Description
`EMAILJS_SERVICE_ID`	Yes*	Your EmailJS service ID
`EMAILJS_PUBLIC_KEY`	Yes*	Your EmailJS public key
`EMAILJS_PRIVATE_KEY`	No	Your EmailJS private key (required for `get_email_history`)

*Can be passed per tool call as parameters instead of env vars.

Credential Priority

Credentials are resolved in this order:

Parameter passed in the tool call (overrides everything)
Environment variable
Error with a descriptive message

This allows using multiple EmailJS accounts in the same session.

Usage Examples

Send an email

Send an email using template "template_contact" with:
- to_name: "Alice"
- to_email: "alice@example.com"
- message: "Hello from Claude!"

Validate your config

Validate my EmailJS configuration for service "service_gmail" and template "template_welcome"

Check email history

Show me the last 10 emails I sent via EmailJS

Where to find your credentials

Go to EmailJS Dashboard
Service ID → Email Services → your service
Public Key → Account → API Keys → Public Key
Private Key → Account → API Keys → Private Key

Local Development

git clone https://github.com/ElizioMartins/mcp-emailjs
cd mcp-emailjs
npm install
npm run build

# Test with MCP Inspector
npm run inspector

License

MIT

Available Tools

3 tools

get_email_historyA

Retrieve the history of emails sent via EmailJS. Requires EMAILJS_PUBLIC_KEY and EMAILJS_PRIVATE_KEY (accessToken) for authentication.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number for pagination (default: 1)
`count`	No	Number of records per page, max 100 (default: 20)
`user_id`	No	EmailJS public key. Overrides EMAILJS_PUBLIC_KEY env var.
`accessToken`	No	EmailJS private key. Overrides EMAILJS_PRIVATE_KEY env var.

TDQS

A3.6/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 mentions authentication requirements but does not disclose other behavioral traits such as rate limits, idempotency, or error handling for missing credentials.

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 two sentences long, front-loaded with the core purpose, and contains no unnecessary words or repetition.

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

Completeness4/5

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

For a simple retrieval tool with pagination parameters and no output schema, the description covers purpose and authentication. It lacks details on response format, but the tool is relatively straightforward.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds no additional semantic meaning beyond reinforcing authentication requirements, which is baseline behavior.

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

Purpose5/5

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

The description clearly states the verb 'Retrieve' and the resource 'history of emails sent via EmailJS'. It distinguishes from siblings like 'send_email' and 'validate_config' by specifying the action and context.

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

Usage Guidelines3/5

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

The description implies usage when email history is needed, but does not explicitly state when to use versus siblings or provide exclusions. The authentication requirement is mentioned, but no guidance on when not to use.

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

send_emailB

Send an email using an EmailJS template. Credentials can be passed as parameters or read from EMAILJS_SERVICE_ID, EMAILJS_PUBLIC_KEY, and EMAILJS_PRIVATE_KEY environment variables.

ParametersJSON Schema

Name	Required	Description
`template_id`	Yes	EmailJS template ID (e.g. 'template_abc123')
`template_params`	No	Key-value pairs that map to variables in the EmailJS template
`service_id`	No	EmailJS service ID. Overrides EMAILJS_SERVICE_ID env var.
`user_id`	No	EmailJS public key. Overrides EMAILJS_PUBLIC_KEY env var.
`accessToken`	No	EmailJS private key for extra security. Overrides EMAILJS_PRIVATE_KEY env var.

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description carries full responsibility for disclosing behavioral traits. It only states the action 'Send an email' and mentions credential sources. It fails to disclose side effects (e.g., sending is destructive), error behavior, rate limits, or whether the operation is idempotent. This is insufficient for an agent to understand runtime implications.

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 very concise at one sentence (16 words) and front-loads the main purpose. It earns its place without unnecessary words. However, it could be slightly expanded to include key behavioral info without harming conciseness, so it is not a perfect 5.

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 complexity (5 parameters, 1 required, no output schema) and no annotations, the description is far from complete. It omits what the tool returns (e.g., success/error response), how to obtain template IDs, whether it works offline, and how it relates to siblings (e.g., using get_email_history to check sent emails). It needs much more context for an agent to use it reliably.

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?

Input schema coverage is 100%, so the baseline is 3. The description adds that credentials can be passed as parameters or from env vars, which is already implied in the schema descriptions (e.g., 'Overrides EMAILJS_SERVICE_ID env var'). No additional meaning is provided; it does not clarify how template_params map to variables or when to use overrides.

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 tool's function: 'Send an email using an EmailJS template.' It uses a specific verb ('Send') and resource ('email using EmailJS template'), which immediately distinguishes it from sibling tools like get_email_history (reading) and validate_config (validating).

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

Usage Guidelines3/5

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

The description provides a minor usage hint about credentials (can be from env vars or parameters) but does not explicitly say when to use this tool vs. alternatives. It lacks guidance on prerequisites (e.g., valid template ID) or when not to use it. No comparison to siblings is made.

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

validate_configA

Validate EmailJS credentials and template ID. WARNING: EmailJS has no dry-run endpoint, so this performs a real send with empty template params — it consumes send quota and may deliver an email if the template has no required variables. Returns a clear message indicating which part of the configuration is invalid.

ParametersJSON Schema

Name	Required	Description
`template_id`	Yes	EmailJS template ID to validate
`service_id`	No	EmailJS service ID. Overrides EMAILJS_SERVICE_ID env var.
`user_id`	No	EmailJS public key. Overrides EMAILJS_PUBLIC_KEY env var.
`accessToken`	No	EmailJS private key for extra security. Overrides EMAILJS_PRIVATE_KEY env var.

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It explicitly warns that this tool performs a real send, consumes quota, and may deliver an email, which is critical behavioral information. However, it lacks details about return format or validation criteria beyond a 'clear message'.

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 two sentences long, front-loading the purpose and then providing essential behavioral warning. Every sentence serves a purpose with no wasted words.

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

Completeness4/5

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

Given there is no output schema, the description adequately explains what the tool does and notes important side effects. It could mention what a successful validation returns, but the promise of a 'clear message' is sufficient for most agents.

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

Parameters3/5

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

Schema description coverage is 100%, so baseline is 3. The description adds high-level context but does not elaborate on individual parameter usage beyond what the schema already provides.

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 tool's purpose: 'Validate EmailJS credentials and template ID.' This is a specific verb+resource combination that distinguishes it from sibling tools like 'send_email' and 'get_email_history'.

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

Usage Guidelines3/5

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

The description provides context about the tool's side effects (real send, quota consumption) but does not explicitly state when to use or not use this tool versus alternatives. No direct comparison to siblings is given.

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 tool updatev1.0.1Jun 22, 2026

Changedvalidate_config1 field changed

changedInput schema / properties / accessToken / description

Previous value: -"EmailJS private key. Overrides EMAILJS_PRIVATE_KEY env var."New value: +"EmailJS private key for extra security. Overrides EMAILJS_PRIVATE_KEY env var."

3 tool updatesv1.0.0Jun 19, 2026
- First observedget_email_history
- First observedsend_email
- First observedvalidate_config

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.9/5.0

Scored 2026-06-22 18:50 across 3 tools

Disambiguation5/5

Each tool serves a distinct purpose: retrieving history, sending emails, and validating configuration. No overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (get_email_history, send_email, validate_config).

Tool Count5/5

Three tools is well-scoped for an email service, covering the core operations without unnecessary bloat.

Completeness4/5

The set covers sending, history, and config validation. Minor gap: lacks template management or cancellation, but core workflow is complete.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

email A
dev.primitive
Email infrastructure for AI agents — send, receive, search, and reply to email over MCP.
Email Communication
302
AgentMailOAuth
to.agentmail
Email inboxes for AI agents: send, receive, reply, search, and manage threaded email over MCP.
Email Communication
2
CryptoAgentMail
io.github.influqa
Hosted email MCP for AI agents with inboxes, send/receive, memory, recovery, and credits.
Email Communication
21
AgenticEmail A
dev.agenticemail
Hosted email for AI agents: create inboxes, send, receive, and reply over MCP with scoped API keys
Email Communication
2

Related MCP Servers

email-mcp-server
Email Communication
egyptianego17
A
license
A
quality
C
maintenance
An MCP server that enables AI assistants to send emails via SMTP, supporting simple and custom emails with attachments and CC/BCC, plus connection testing.
Updated 7 months ago (2026-02-17 00:15 UTC)
3
28
MIT
email-mcp
Email Communication
yashjoshiatgit
A
license
Not graded
quality
D
maintenance
A production-ready MCP server that empowers AI agents to securely send emails via SMTP, supporting plain text, HTML, and attachments.
Updated 6 months ago (2026-03-04 10:29 UTC)
MIT
Shoot Email
powersurge01
A
license
Not graded
quality
B
maintenance
An MCP server that provides AI agents with a persistent, agent-native email mailbox for sending, receiving, and managing emails through bounded-context retrieval, idempotent operations, and explicit acknowledgement.
Updated 2 months ago (2026-07-30 18:14 UTC)
MIT
@striderlabs/mcp-gmail
Email Communication
markswendsen-code
A
license
A
quality
D
maintenance
MCP server that gives AI agents the ability to send, read, and search email via Gmail.
Updated 3 months ago (2026-06-18 01:07 UTC)
4
27 npm
MIT