Skip to main content
Glama

List emails

list_emails
Read-onlyIdempotent

List email summaries from a local mailbox copy, filtered by account, folder, sender, recipient, subject, date, flags, keyword, or attachments. Reads local copy only, never contacting the mail server.

Instructions

Lists summaries of emails already synchronized into MailFathom's local mailbox copy, newest received first by default. Filters by account, folder, sender address, recipient address, subject text, received date range, remote seen state, remote flagged (starred) state, a keyword the mail server reported, and attachment presence. Reads the local copy only: it never contacts a mail server, never marks mail as read, and never returns body text, raw MIME, or attachment content. Mail in the account's junk folder is left out unless includeJunkMail is set. Returns at most 100 summaries per call, with an opaque cursor for the next page and a per-folder statement of how current the local copy is.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cursorNoThe nextCursor value from a previous call, to read the following page. Reuse it only with the same filters and direction; presenting it with different ones is refused. Changing only the page size is allowed.
foldersNoMailFathom folders to read, each named by its alias, such as INBOX, or by the role it plays, written as role:Junk. Roles are Inbox, Archive, Drafts, Sent, Junk, Trash, All, Flagged, Important, and Outbox; naming one reads whichever folder each account in scope maps with that role, whatever it is called there. Omit to read every folder of the accounts in scope. At most 64 may be named. An alias is MailFathom's own name for a folder and is matched without regard to case.
keywordNoReturn only emails carrying this keyword, which is a flag a mail client or server set rather than one of the five standard ones, such as $Junk or a label. Matched as a whole keyword without regard to case; up to 64 characters, and a value that is not a keyword this system stores is refused. Omit to match any, which an empty string does too. The keywords each email carries are reported in its remoteFlags.
accountsNoMailFathom accounts to read, each named by its configured account identifier or by the display name it is published under. Omit to read every account this deployment serves; call list_accounts to see what they are. At most 64 may be named, and a name this deployment does not serve is refused rather than answered with an empty page.
pageSizeNoHow many summaries to return, from 1 to 100. Omit to take the default of 25. A value outside the range is refused rather than clamped.
directionNoWhich end of the timeline to read from: newestFirst to browse recent mail, oldestFirst to walk a mailbox in full.newestFirst
senderAddressNoReturn only emails sent from this mail address. Matched as a whole address rather than as a fragment, without regard to case; a non-empty value that is not a usable mail address is refused. Omit to match any sender, which an empty string does too.
hasAttachmentsNoReturn only emails that carry attachments (true) or that carry none (false). Omit to match either. Inline images and cryptographic signature parts do not count as attachments.
isRemotelySeenNoReturn only emails the mail server last reported as read (true) or unread (false). Omit to match either. Listing never changes this state. An email whose flags no run has observed yet counts as unread.
receivedBeforeNoReturn only emails received strictly before this ISO 8601 timestamp, so consecutive ranges built from one instant neither overlap nor leave a gap. Omit for no upper bound.
includeJunkMailNoInclude mail in the account's junk folder, which is left out by default. Naming the junk folder in folderAliases does not include it; only this does. A cursor issued with one answer cannot be presented with the other. The result reports which answer produced it.
subjectFragmentNoReturn only emails whose subject contains this text, without regard to case, up to 256 characters. Wildcard characters match themselves. Omit to match any subject, which an empty string does too.
recipientAddressNoReturn only emails addressed to this mail address in their To or Cc header. Matched as a whole address rather than as a fragment; Reply-To is not searched. Omit to match any recipient, which an empty string does too.
isRemotelyFlaggedNoReturn only emails the mail server last reported as flagged (true) or unflagged (false), which is the star most mail clients show. Omit to match either. This is the \Flagged flag on a message and is unrelated to the Flagged folder role; an email whose flags no run has observed yet counts as unflagged.
receivedOnOrAfterNoReturn only emails received at or after this ISO 8601 timestamp. Emails whose received date is unknown are excluded whenever either bound is named. Omit for no lower bound.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
emailsYesThe email summaries on this page, in the requested order. Empty when no email matched the filters.
nextCursorNoAn opaque cursor for the next page. Pass it back unchanged as cursor, with the same filters. Null means this page ended the walk. A present cursor does not promise that the next page is non-empty, because mail can be expunged between two calls, but continuing from it never skips or repeats an email.
folderFreshnessYesHow current the local copy of each folder in the request's scope is, one entry per folder. Read this before concluding that a mailbox holds no matching mail.
includedJunkMailYesWhether the account's junk folder took part in this listing. False means its mail was left out and is reachable by calling again with includeJunkMail set.
Install Server

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes well beyond the annotations (readOnlyHint, idempotentHint, destructiveHint) by disclosing that it never contacts a mail server, never marks mail as read, and never returns body text, raw MIME, or attachment content. It also states the junk-folder exclusion, the 100-summary cap, opaque-cursor pagination, and per-folder currency reporting. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Five sentences each convey a distinct fact: what is listed, what filters exist, the safety/scope constraints, junk behavior, and pagination/currentness. The enumeration of filters is long but appropriate given the tool's 15 parameters; no sentence is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (15 parameters, pagination, filter semantics, local-only behavior) and the presence of an output schema, the description covers all aspects an agent needs to decide whether and how to call the tool: scope, ordering, filters, safety, junk handling, max page size, cursor, and freshness. The output schema covers return values, so their omission here is acceptable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema coverage is 100%, so the schema already documents all 15 parameters in detail. The description only summarizes the filter categories (e.g., 'remote seen state, remote flagged (starred) state') without adding syntax, format, or constraint details beyond the schema. It meets the baseline but adds no new parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Lists summaries of emails already synchronized into MailFathom's local mailbox copy, newest received first by default' – a specific verb, resource, and ordering. It lists the available filter dimensions and explicitly scopes to summaries only ('never returns body text, raw MIME, or attachment content'), distinguishing it from sibling tools like get_email_content.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description conveys clear context for when to use this tool: it is a local-only, read-only operation that returns summaries and never contacts the mail server or marks mail as read. It also notes that junk mail is excluded unless includeJunkMail is set and that cursor reuse with different filters is refused. However, it does not explicitly name alternatives such as search_emails or get_email_content for body retrieval, so 'when to use vs alternatives' is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Krzysztof318/MailFathom'

If you have feedback or need assistance with the MCP directory API, please join our Discord server