Skip to main content
Glama

Search emails

search_emails
Read-onlyIdempotent

Search synchronized email copies for words or phrases and receive ranked results with body snippets; narrow by sender, subject, date, and more without contacting a mail server.

Instructions

Searches the emails already synchronized into MailFathom's local mailbox copy for text, and returns the best matches ranked by relevance with bounded extracts of the body around the matched words. Retrieval is lexical or hybrid depending on how this server is configured, and every response says which in its retrievalMode field: lexical finds the words a query contains rather than what they mean, while hybrid also finds mail whose meaning is close and combines the two rankings. Words that appear only inside an attachment are never searchable either way. Narrows 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 whole bodies, raw MIME, or attachment content. Mail in the account's junk folder is left out unless includeJunkMail is set. Returns one window of at most 50 results that nothing continues, so narrow the filters or write a different query to reach other mail. Matching nothing is a normal empty result rather than an error.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
foldersNoMailFathom folders to search, 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 searches whichever folder each account in scope maps with that role, whatever it is called there. Omit to search 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 search, each named by its configured account identifier or by the display name it is published under. Omit to search 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 window.
queryTextYesThe text to search for, up to 512 characters. Quoted phrases, OR, and a leading - to exclude a word are understood; every other punctuation mark is ordinary text. Write the words the mail itself is likely to contain, in the language it was written in rather than the language of your request: matching compares words rather than translating them, so a mailbox holding several languages is reached by a search per language. Required: a search with no text is a listing, which list_emails answers in a stable order and with a cursor.
resultLimitNoHow many ranked results to return, from 1 to 50. Omit to take the default of 20. A value outside the range is refused rather than clamped, so a window is never smaller than it claims to be.
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. Searching 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. The result reports which answer produced it.
subjectFragmentNoReturn only emails whose subject contains this text, without regard to case, up to 256 characters. This narrows which emails are eligible before any of them is ranked and is unrelated to queryText, which is what the eligible ones are matched against. 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
matchesYesThe matched emails, most relevant first, ties broken by the newest received. Empty when nothing matched the query and the filters, which is a normal answer.
retrievalModeYesHow these results were retrieved. 'lexical' means full-text matching over the words the mail is written in: a query term that appears nowhere in a message will not find it however close its meaning. 'hybrid' means that ranking was combined with a search by embedding similarity, so a message can appear without carrying the query's words. Read this field on every response rather than assuming a mode: the same server answers 'lexical' when its embedding provider is unavailable, and neither mode involves a chat model or rewrites the query.
semanticSearchYesWhat this server can do with embeddings, which is what tells you why a 'lexical' answer was lexical. 'inactive' means the server does not embed mail at all, so lexical is the intended and only mode. 'available' means it does and its provider is answering. 'degraded' means it does, but it currently cannot reach the embedding provider or its configuration is wrong, so these results are narrower than the server intends: say so rather than retrying, because nothing about the request caused it and the server's operator has to fix it.
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 search. False means its mail was left out and is reachable by calling again with includeJunkMail set.
Install Server

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds extensive behavioral context: never contacts a mail server, never marks as read, never returns raw MIME or attachments, retrieval mode is variable, attachment content is unsearchable, junk filtered by default, and result windows are not continuable. These details go well beyond annotations.

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

Conciseness4/5

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

The description is long but every sentence adds value. It is front-loaded with the core purpose and then systematically covers retrieval, filters, exclusions, and edge cases. While it could be broken into clearer sub-sections, it remains dense and purposeful without redundancy.

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?

For a tool with 14 parameters and an output schema, the description covers all crucial edge cases: retrieval mode differences, attachment limitations, junk mail handling, window size cap and non-continuation, handling of no results, and interplay with listing. It also clarifies that the tool reads only local copies, which is critical for agent expectations.

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

Parameters4/5

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

Schema coverage is 100% with detailed per-parameter descriptions. The overall description adds semantic meaning by explaining how filters collectively narrow results (e.g., 'Narrows by account, folder, sender address...') and notes that filter combination is 'unrelated to queryText'. This provides high-level understanding beyond the schema.

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 clearly states the tool's purpose: searching synchronized local emails for text and returning ranked matches with bounded extracts. It specifies the resource (MailFathom's local mailbox copy) and the action (searches), and differentiates from siblings like list_emails (listing) and get_email_content (full content retrieval) by explicitly noting it never returns whole bodies.

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

Usage Guidelines5/5

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

The description provides strong guidance on when to use this tool: it explains the retrieval modes (lexical/hybrid), the limitation of searching only local copies, and explicitly contrasts with list_emails for listing via queryText description. It also clarifies that no results is normal, guiding the agent on expected behavior.

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