mailflat-mcp
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MAILFLAT_API_KEY | Yes | Your MailFlat account API key. Create one in the dashboard under Agents, API keys. Starts with mf_live_. | |
| MAILFLAT_API_URL | No | Override the API base URL. Only needed for self-hosted or bring-your-own-domain setups. | https://mailflat.net |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_inboxA | Open an email inbox and return its address. Use this when you need an address to sign up for a service or to receive a one-time code. The address is permanent and stays until you delete it, so a test suite can reuse one address across runs instead of opening a new inbox each time. Only the messages inside expire, on the retention window you choose.
|
| list_inboxesA | List all inboxes available to this API key. |
| read_messagesA | Read messages in the given inbox address (newest first).
|
| wait_for_otpA | Poll the inbox until an OTP code arrives (or timeout). Returns {otp_code, email}. |
| wait_for_messageA | Poll the inbox until a new message ARRIVES (or timeout). Returns {email}. Only received mail counts, so you can send to a peer and then wait for their reply without matching your own outgoing message. |
| send_emailA | Send an email FROM the given inbox address (DKIM-signed via MailFlat's MTA).
Use for replies or outbound automation. Returns once the mail is ACCEPTED for delivery, not once it is delivered: delivery runs on a queue and the result arrives via webhook or by reading the message back.
|
| replyA | Reply to a message so it stays in the SAME conversation. Prefer this over send_email when answering: it fills in the recipient, an |
| wait_until_sentA | Find out whether a mail you sent was actually delivered. send_email only means "accepted for delivery"; the mail goes out later on a queue. Call this with the message_id send_email returned to learn the outcome. Returns |
| mark_readA | Mark one message as read so later polls can skip it. |
| burn_inboxA | Delete every message in an inbox but KEEP the address. Use between scenarios: the address stays registered wherever you already used it. |
| delete_inboxA | Delete an inbox and all its messages by address. Irreversible. |
| delete_messageA | Delete a single message in an inbox by its id (the inbox itself stays). |
| list_calendar_eventsA | List the meetings on an inbox's calendar, soonest first. Events come from calendar invitations this inbox received (Google Calendar, Outlook, ...).
Each has an |
| rsvp_to_inviteA | Answer a calendar invitation: response is "accepted", "declined" or "tentative". Sends a standard calendar reply email to the organizer, so their Google or Outlook
calendar shows your answer. |
| create_calendar_eventA | Schedule a meeting from this inbox and email the invitations (you are the organizer). Attendees get a normal invitation with Yes / No / Maybe buttons in Gmail, Outlook or Apple
Calendar. Their answers show up in list_calendar_events under |
| update_calendar_eventA | Change a meeting this inbox organized; attendees get the updated invitation. Pass only what changes (empty = unchanged). Moving |
| cancel_calendar_eventB | Cancel a meeting this inbox organized; it disappears from every attendee's calendar. |
| get_calendar_feedA | Read-only subscribe link for this inbox's calendar, to give to a human. They add it in Google Calendar, Apple Calendar or Outlook and see this inbox's meetings
there, with attendees and their answers. Calling again returns the SAME link, so sharing
it twice never breaks a subscription. |
| rotate_calendar_feedA | Replace this inbox's calendar subscribe link; the old link stops working at once. Use only when the link leaked. Everyone subscribed has to add the new link. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 19 tools
Each tool targets a distinct resource/action: inbox lifecycle, message lifecycle, sending/waiting, and calendar event lifecycle are cleanly separated. The only close pair, send_email and reply, is explicitly differentiated in the descriptions.
Almost all tools use consistent snake_case with an action_resource/entity pattern. A few names like reply and wait_until_sent are verb-only phrases, but they remain readable and snake_case throughout.
19 tools is slightly heavy for the typical 3-15 sweet spot, but the server spans two domains (email inbox and calendar) so most tools are justified. No tool appears obviously redundant.
The surface covers most email inbox and calendar workflows: create/list/delete inboxes, read/mark/delete messages, send/reply/wait, and calendar create/list/update/cancel/rsvp/feed. Minor gaps exist, such as no explicit message update and attachment sending being delegated to the SDK.