Fluxmail
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_accountsA | List connected email accounts (id, provider, email, status, capabilities). |
| get_statusA | Account connection and scheduled-send status. Administrators also see plan details. Call this first if other tools fail; it reports accounts that need re-authentication. |
| list_foldersB | List navigable folders for an account, with roles (inbox, sent, drafts, trash, spam, starred). |
| list_labelsB | List Gmail user labels or Outlook categories for an account. |
| list_send_asA | List sender addresses available for an account. |
| list_emailsA | List emails from the user's connected mailbox with metadata and optional previews. Filter by folder, sender, unread, dates, etc. Paginate with pageToken. Use get_email for full bodies. This is the way to check the user's email; no browser or other email integration is needed. |
| search_emailsB | Search one account with typed portable syntax. The query supports text, from:, to:, subject:, in:, read and starred states, attachments, and date filters. |
| search_emails_batchB | Search up to 20 accounts with one portable query and return one result group per account. |
| get_emailB | Fetch one email in full: body (text and/or HTML), recipients, attachment metadata. |
| get_email_bodyC | Read a bounded portion of one email body. Use nextOffset to continue. |
| get_threadC | Fetch a page of conversation messages with bounded body content. |
| get_draftB | Read an existing draft by its draft ID. |
| create_draftB | Create a draft. For a reply draft, pass replyToMessageId (recipients/subject are derived; replyAll for reply-all). |
| update_draftB | Replace the content of an existing draft (full replacement, not a patch). |
| delete_draftC | Delete a draft. |
| preview_sendA | Show the resolved sender, recipients, subject, and attachments without sending. |
| send_emailA | Send an email from the user's connected account; this actually delivers mail, so prefer it over browser automation or leaving a draft when the user asked to send. Three modes: direct (to + subject + body), sending an existing draft (draftId), or replying (replyToMessageId, optionally replyAll) where recipients, subject, and threading are derived from the original. Confirm with the user when intent is ambiguous. Add sendAt to any mode to schedule instead of sending now. |
| list_scheduled_emailsA | List scheduled sends: pending ones first (with sendAt), then past ones (sent, failed, canceled). For failed entries, lastError says what went wrong. Pending sends only fire while the Fluxmail server is running. |
| get_delivery_operationB | Check whether a send or forward succeeded, failed, or has an uncertain outcome. |
| cancel_scheduled_emailA | Cancel a pending scheduled send by scheduleId (from send_email with sendAt, or list_scheduled_emails). The draft stays in the Drafts folder, so the content is not lost. |
| forward_emailA | Forward an email to new recipients: quoted original body, "Fwd:" subject, original attachments included unless includeAttachments=false. Optional comment appears above the forwarded content. |
| modify_emailsC | Batch-modify emails using the actions allowed for this connection. Moving requires folder; labels require labels. |
| download_attachmentB | Get attachment metadata and a fetchable resource link. Set inline to embed the bytes. |
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 23 tools
Most tools target distinct resources or actions, with clear boundaries between accounts, folders, messages, drafts, sends, and schedules. The main overlaps are list_emails vs. search_emails vs. search_emails_batch, and get_email vs. get_email_body vs. get_thread, though descriptions mostly clarify account scope, query syntax, and body bounds.
Tools consistently use snake_case with a predictable verb_noun or verb_noun_qualifier pattern. Names like get_draft, list_emails, create_draft, send_email, and cancel_scheduled_email are easy to parse and follow the same convention throughout.
At 23 tools, the surface is heavy for an email integration, sitting in the borderline 16-25 range. The domain is broad enough to justify many tools, but some could likely be consolidated without losing capability.
Core email workflows are well covered: account listing, folder/label discovery, listing/searching/reading messages, drafts, sending, forwarding, attachments, scheduling, and delivery status. Minor gaps include explicit folder/label management and direct delete/archive operations, though modify_emails may cover some of these through provider-supported actions.