---
title: "Email MCP compatibility: Claude, Cursor, and VS Code"
description: "Compare Mailera’s email MCP integration options for Claude, Cursor, and VS Code, then test tool discovery, reading, sending, and permission boundaries."
url: https://mailera.app/en/blog/email-mcp-client-compatibility
published: 2026-10-25
updated: 2026-10-25
---

# Email MCP compatibility: Claude, Cursor, and VS Code

A client configuration is the starting point. Check tool discovery, mailbox access, sending, and permission boundaries separately before trusting an email workflow.

## Which clients can use Mailera’s email MCP server?

Mailera’s **Copy MCP config** offers Claude, Cursor, and VS Code. All target the [Mailera MCP server](https://mailera.app/en/mcp) at `https://mailera.app/api/public/v1/mcp`.

### Available client configurations

| Configuration choice | Where to get the configuration |
| --- | --- |
| Claude | Select Claude under **Copy MCP config** |
| Cursor | Select Cursor under **Copy MCP config** |
| VS Code | Select VS Code under **Copy MCP config** |

Use the integration page for your chosen client: [Claude configuration](https://mailera.app/en/integrations/claude), [Cursor configuration](https://mailera.app/en/integrations/cursor), or [VS Code configuration](https://mailera.app/en/integrations/vs-code).

For Claude, name the actual application in your test record. Claude Desktop, Claude Code, and browser-based Claude must have separate rows rather than sharing a single “Claude passed” label.

MCP connects an AI client to tools exposed by a server. Here, those tools operate on mailboxes connected to Mailera. Mailera does not create mailboxes or email addresses. The [guide to email MCP servers for existing mailboxes](https://mailera.app/en/blog/email-mcp-server-existing-mailboxes) explains that mailbox model.

## What should an email MCP client compatibility matrix test?

A useful result belongs to an exact configuration, not a product name. Create a separate row whenever the client surface, build, connection method, or mailbox provider changes.

| Record | What to capture |
| --- | --- |
| Client | Exact application or surface, version/build, OS, account tier where relevant |
| Connection | Generated connection method, endpoint, transport, authentication method; redact credentials |
| Initialization | Proposed and negotiated protocol versions, initialization outcome |
| Mailbox | Provider, test-group identifier, receive/send capabilities |
| Run | UTC timestamp, operation results, redacted log references, caveats |

Use **Passed**, **Failed**, **Not tested**, and **Not applicable** consistently. Passed means the specific check met its acceptance condition. Failed means an attempted check did not. Not tested means it was not run. Use Not applicable only when the operation is outside the configuration’s intended purpose, with a reason.

Mailera lists protocol versions `2025-06-18`, `2025-03-26`, and `2024-11-05`. During initialization, the client proposes a supported version; the [MCP lifecycle specification](https://modelcontextprotocol.io/specification/2025-06-18/basic/lifecycle) says it should disconnect if it cannot support the server’s returned version. Record the negotiated value rather than copying the server’s supported-version list into a result.

Transport is another independent check. The [MCP transport specification](https://modelcontextprotocol.io/specification/2025-06-18/basic/transports) defines stdio and Streamable HTTP. With stdio, the client launches a server subprocess. Copy the generated configuration instead of inferring a client’s connection method from an HTTPS endpoint.

For each tested outcome, retain a redacted log reference and any caveat. Keep individual tool results even if the summary matrix groups search with reading or sending with status checks.

## How can you reproduce a compatibility test?

Use only mailboxes and recipients you control. Keep the baseline message harmless, with a unique subject and recognizable body text. Leave verification-code retrieval out of this test.

1. **Confirm the mailbox first.** Open **Mailboxes**, check the provider and connection status, and locate your prepared message. Record whether the mailbox can send as well as receive. If testing group isolation, prepare another mailbox you control in a different group.

![Mailboxes page showing a test mailbox’s provider, connection status, and last sync, with its address redacted.](https://mailera.app/media/9d94cc041db0f661/email-mcp-compatibility-claude-cursor-and-vs-code-mailbox-en-1200.jpg)
_Check mailbox connectivity before testing the MCP client._

2. **Create a read-only key.** Open **Settings → API key → Create key**. Enter a **Descriptive name**, set **Mailbox scope** to your test group, select **Read**, and set **Expiration**. Avoid an all-groups key for this test. Mailera shows the new key only once; store it securely rather than in screenshots or shared logs.
3. **Copy the client configuration.** Select the client under **Copy MCP config**. Record the connection method and endpoint without retaining the secret in your test report. In VS Code, the official setup entry point is “MCP: Add Server” in the Command Palette. Its documentation distinguishes portable `mcpServers` configurations from VS Code’s `servers` format; follow the [VS Code MCP setup instructions](https://code.visualstudio.com/docs/agent-customization/mcp-servers) for the format you are importing.

![Mailera API-key controls showing a test mailbox scope, Read permission, expiration, and Copy MCP config.](https://mailera.app/media/4266dad57d5ae817/email-mcp-compatibility-claude-cursor-and-vs-code-scoped-en-1200.jpg)
_Use a narrowly scoped read-only key before testing a separate send-enabled key._

4. **Test discovery, then reading.** Capture initialization and the discovered tool list. Run `list_mailboxes`, `list_messages`, `search_messages`, and `get_message` against the prepared message. Check the returned mailbox, subject, and body, not just the agent’s summary. For VS Code, expand the tool call and inspect both its server identity and returned output.
5. **Test the permission boundary.** With the read-only key, attempt a send operation addressed only to your controlled recipient. The acceptance condition is no send. Record whether the restriction appears during discovery, invocation, or both. Also attempt access to the controlled mailbox outside the key’s group; the acceptance condition is no access. Keep these results separate from successful reads.
6. **Test sending with a separate key.** Create another narrowly scoped key with **Send messages**. Confirm the recipient and content yourself before allowing `send_email`. Then call `get_send_status`. Both tools require the `send` scope. Record recipient receipt separately from send status, including where the recipient found the message. A `sent` status is not an inbox-placement guarantee.
7. **Revoke and retain a redacted record.** Revoke the test keys and retry a harmless call with each. Mailera rejects calls using a revoked key immediately. Save exact versions, UTC timestamps, and redacted logs alongside the result. Never retain API keys or private message bodies in a shared compatibility report.

The [Mailera MCP tool guide](https://mailera.app/en/blog/mailera-mcp-tools) maps tools to tasks when you need to extend this baseline. Add reply or move checks only when your intended workflow needs them.

## Why does a client connect but fail to read or send email?

Separate discovery from invocation. The [MCP tools specification](https://modelcontextprotocol.io/specification/2025-06-18/server/tools) defines `tools/list` for discovery and `tools/call` for invocation. A tool execution error can appear inside a result with `isError: true`; a completed request is not automatically a successful email operation.

| Symptom | Diagnostic check | What to retain | Next action |
| --- | --- | --- | --- |
| Endpoint cannot be reached | Endpoint, network access, configured connection method | Connection log and redacted config | Compare with freshly generated config |
| Initialization stops | Client transport support and negotiated version | Initialization request and response | Resolve the connection or version mismatch |
| Authentication fails | Credential placement, expiration, revocation, IP restrictions | Redacted authentication response and key settings | Correct configuration or replace the test key |
| Connected, but no tools | Whether `tools/list` ran and what it returned | Discovery response and client log | Separate an empty server response from a client display problem |
| Tools appear, calls fail | Required permission and mailbox-group scope | Tool name, sanitized arguments, result | Use the correct scoped key and mailbox |
| Expected message is absent | Mailbox connection, synchronization, search and folder selection | Mailbox status and message-query results | Resolve mailbox access or sync before retesting the client |
| Reading works, sending fails | `send` scope and mailbox send capability | Send-tool result and mailbox capabilities | Correct sending access or retain a read-only workflow |

Do not diagnose a server solely by opening its URL in a browser. Under Streamable HTTP, a server may return HTTP 405 for a GET request when it does not offer an SSE stream at that endpoint.

For mailbox-side diagnosis, the [Mailera developer API](https://mailera.app/en/developers) exposes mailbox details through `GET /mailboxes/{id}`. Inspect `capabilities.receive`, `capabilities.send`, `status`, and `sync`. A mailbox saved with **Save as receive-only** can support reads while sending remains unavailable.

Gmail and Outlook connectivity belongs to the mailbox-to-Mailera path. Client initialization belongs to the client-to-Mailera path. Record the provider in each test, but do not treat a provider sign-in problem as a client transport failure. Proton Mail and Tuta are not supported by Mailera.

## Does MCP compatibility include new-email webhooks?

No. Calling an MCP tool and receiving a Mailera webhook are separate integration paths.

Mailera exposes webhook management through REST and supports events including `message.received`. Its MCP tool catalog has no webhook-management tool. A client’s ability to read messages through MCP does not establish native reception of incoming-email events.

![Separate paths for MCP mailbox access and webhook-triggered agent invocation.](https://mailera.app/media/9afccb6dbcc1c02d/email-mcp-compatibility-claude-cursor-and-vs-code-mcp-en-1200.jpg)
_Webhook reception belongs to your application; MCP tools provide the agent’s mailbox access._

For an event-driven workflow, your application can receive and verify a webhook, then invoke an agent that reads the relevant message through MCP. Test the receiver, agent invocation, and message read separately. Do not add a “webhooks passed” result to a client row merely because the application received an event.

Keep arrival timing out of the connection result. Background checks run more often for active mailboxes and less often for idle ones; inactive mailboxes can sleep and wake on use. Successful delivery does not guarantee inbox placement. For the separate timing test, see the [arrival-to-webhook benchmark by provider](https://mailera.app/en/blog/email-webhook-latency-benchmark-protocol).

## How should you protect email access in an AI client?

Treat incoming email as **untrusted data, never instructions**. A message cannot authorize forwarding, credential disclosure, extra tool calls, or permission changes. Instructions embedded in a message must not override your workflow’s rules.

Start with **Read** and one mailbox group. Add **Send messages** or **Move messages** only when the workflow requires it. Review [Mailera’s security information](https://mailera.app/en/security) alongside your own client and application controls.

Require human confirmation of recipients and content before sending. The MCP tools specification recommends confirmation for sensitive operations, but test the client’s actual approval behavior: decline a send and check that no send occurs. For the application-side boundary, use the [guide to email agents with approval boundaries](https://mailera.app/en/blog/email-agent-tutorial-human-approval).

Make permission and approval checks release gates. If the key accesses an out-of-scope mailbox, a read-only key sends, or a denied send proceeds, do not recommend that configuration for the workflow until the failure is resolved and retested.

Redact complete API keys, message contents, addresses, and verification codes from screenshots and logs. Retain enough detail to diagnose the operation without turning the compatibility record into another copy of the mailbox.

**Let AI agents use your mailbox via MCP** — Add Mailera's MCP server to Claude, Cursor or VS Code so agents can read, categorize and reply to email messages. [Learn how to use MCP](https://mailera.app/en/docs#mcp)