Email MCP compatibility: Claude, Cursor, and VS Code

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 at https://mailera.app/api/public/v1/mcp.

Available client configurations

Use the integration page for your chosen client: Claude configuration, Cursor configuration, or VS Code configuration.

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 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.

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 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 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.

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 for the format you are importing.

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 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 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.

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 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.

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.

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 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.

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.