[RFC] Architecture questions for an event-driven Email MCP Server

[radiykharisov]

Pre-submission Checklist

• I have verified that this discussion would not be more appropriate as an issue in a specific repository
• I have searched existing discussions to avoid duplicates

Discussion Topic

Building an MCP translation layer for Atomic Mail (our event-driven email backend running on Haraka + Kafka + Cyrus). The goal is to expose it as a native email infrastructure for agents, but we are hitting a few API design questions regarding MCP best practices:

1. The backend is event-driven via Kafka. What's the current consensus on notifying agents about new mail? Polling an MCP tool feels terribly inefficient. Is there a solid server-to-client push pattern evolving in MCP?

2. For attachments, we drop heavy files into S3 to avoid huge payloads (claim-check pattern). When an agent needs to read a file, is it better practice to just return a pre-signed S3 URL via a tool (for out-of-band fetch), or pipe the data directly through the MCP response?

3. We have native JMAP support. In your experience, do LLMs actually handle deeply nested JMAP JSON reliably? Or is it better to abstract it and flatten everything into narrow, task-specific tools (e.g., get_clean_thread) to save context?

Would love to hear how others are handling similar data-heavy or event-driven setups.

[armorer-labs]

Event-driven email tools feel like a place where provenance and approval semantics matter just as much as transport mechanics.\n\nAn email server is not only moving bytes around; it is introducing text from a very messy trust domain into the agent loop. Message bodies, quoted replies, signatures, forwarded chains, and attachments can all carry instructions or requests with very different authority.\n\nSo one architectural question I would push on is: how much provenance survives when email content becomes agent context? If the system cannot preserve whether a piece of text came from the user, an external sender, a prior agent draft, or a human approval artifact, it becomes much harder to apply the right downstream policy.\n\nThat seems especially important for any flow that can send, forward, reply, or extract sensitive information automatically.

[armorer-labs]

For an event-driven email MCP, I would strongly separate “accept the user intent” from “approve the concrete send behavior.” Email is one of those domains where an innocent-looking intent can expand into a high-impact external action.

The boundary I would want:

1. scan the initial client intent, especially if it contains retrieved/user-provided text
2. scan the expanded workflow plan: trigger, recipients, template, queries, unsubscribe behavior
3. scan the final outbound send payload immediately before execution

That final boundary catches cases where a prompt-injected template or retrieved record tries to add an exfiltration destination, leak credentials, or alter recipients.

I have been testing this shape with Armorer Guard, a local Rust scanner/MCP proxy. It is not email-specific, but the tools/call proxy mode is designed for exactly this “before the external action executes” point:

armorer-guard mcp-proxy -- npx your-mcp-server

Live demo: https://huggingface.co/spaces/armorer-labs/armorer-guard-demo

Curious whether your architecture already has an internal representation of the expanded email workflow; that seems like the best object to scan and approve.