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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed11 schema fields changedv0.6.2
    • changedInput schema / properties / folders / description
      Previous value: -"MailFathom 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, and Important; 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."New value: +"MailFathom 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."
    • addedInput schema / properties / isRemotelyFlagged
      Added value: +{
      +  "default": null,
      +  "description": "Return 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.",
      +  "type": [
      +    "boolean",
      +    "null"
      +  ]
      +}
    • addedInput schema / properties / keyword
      Added value: +{
      +  "default": null,
      +  "description": "Return 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.",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
    • changedInput schema / properties / queryText / description
      Previous value: -"The 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. Required: a search with no text is a listing, which list_emails answers in a stable order and with a cursor."New value: +"The 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."
    • addedOutput schema / properties / matches / items / properties / summary / properties / machineAuthorship
      Added value: +{
      +  "description": "How much this email's own text reads as machine written — generated or drafted with an AI text model rather than typed. A heuristic estimate from the email's own characters, not a measurement and not a probability. It is informational only: it is not a spam verdict, not a risk score, and not a statement that the email is unwanted or unsafe.",
      +  "properties": {
      +    "likelihood": {
      +      "description": "How strongly the text read as machine written, from 0 to 1. A heuristic score rather than a probability: 0 means the text was read and carried nothing, and the scale has no top because no combination of these signals reaches certainty. It is 0 as well when state is 'notAssessed', where it means nothing at all — read state first. Two scores are comparable only within one deployment and one release; get_email_content publishes the profile the number came from.",
      +      "type": "number"
      +    },
      +    "state": {
      +      "description": "The reading of likelihood: 'likely' when the text carries enough of what machine-written text carries that a person typing it is the less likely reading, 'possible' when it carries some of it in a combination a person also reaches, 'unlikely' when it was read and carries little or none of it, and 'notAssessed' when nothing read it — which is what an email with no readable body carries, what a deployment that turned the assessment off records, and what mail stored before this deployment assessed anything carries until it is re-read. 'likely' is not an accusation and warrants no action on its own.",
      +      "enum": [
      +        "notAssessed",
      +        "unlikely",
      +        "possible",
      +        "likely"
      +      ],
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "state",
      +    "likelihood"
      +  ],
      +  "type": "object"
      +}
    • addedOutput schema / properties / matches / items / properties / summary / properties / remoteFlags / properties / keywords
      Added value: +{
      +  "description": "The keywords the mail server reported for the email, such as $JUNK or a label a mail client set, in upper case and without duplicates. Flag names are compared without regard to case, so the case a keyword is written in never decides a match; an empty list means the server reported none, or that nothing has observed this email yet.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • changedOutput schema / properties / matches / items / properties / summary / properties / remoteFlags / required
      Previous value: -[
      -  "seen",
      -  "answered",
      -  "flagged",
      -  "draft",
      -  "deleted",
      -  "wasObserved"
      -]New value: +[
      +  "seen",
      +  "answered",
      +  "flagged",
      +  "draft",
      +  "deleted",
      +  "keywords",
      +  "wasObserved"
      +]
    • changedOutput schema / properties / matches / items / properties / summary / properties / senderAddress / description
      Previous value: -"The sender address as written by the email, or null when it carried no usable sender address."New value: +"The sender address as written by the email, or null when it carried no usable sender address. This is a claim the email made about itself and nothing here verified it; senderVerification is what says whether anything did."
    • addedOutput schema / properties / matches / items / properties / summary / properties / senderVerification
      Added value: +{
      +  "description": "What was established about the author this email displays. Two independent answers: whether the displayed author was authenticated, and whether this deployment recognizes them. Neither is a judgement about whether the email is wanted or unwanted.",
      +  "properties": {
      +    "authorAuthentication": {
      +      "description": "What the receiving mail server established about the author shown in the From header: 'authenticated' when it confirmed the displayed author, 'failed' when it evaluated the displayed domain under that domain's own published policy and the email did not satisfy it, and 'notEstablished' when nothing trusted was enough to conclude either way — which is also what an email carries when the mailbox trusts no authentication-reporting server, and what mail stored before this deployment recorded the answer carries until it is re-read. It is not derived from senderAddress, which is a claim the email wrote about itself.",
      +      "enum": [
      +        "notEstablished",
      +        "failed",
      +        "authenticated"
      +      ],
      +      "type": "string"
      +    },
      +    "deploymentTrust": {
      +      "description": "Whether this deployment's own trusted-sender configuration recognizes the authenticated author: 'trusted' when it names them, 'unknown' otherwise. This is this deployment's classification and not an authentication result. 'unknown' is the ordinary state of legitimate mail from a correspondent nobody has named, and is also what an email whose author was not authenticated carries, so it says nothing on its own — read it together with authorAuthentication.",
      +      "enum": [
      +        "unknown",
      +        "trusted"
      +      ],
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "authorAuthentication",
      +    "deploymentTrust"
      +  ],
      +  "type": "object"
      +}
    • addedOutput schema / properties / matches / items / properties / summary / properties / threadId
      Added value: +{
      +  "description": "The identifier of the conversation this email belongs to, or null when it has not been assembled into one. Two emails carrying the same threadId are the same exchange; a matching subject is not. Pass it to a content read as threadId to retrieve the conversation itself.",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
    • changedOutput schema / properties / matches / items / properties / summary / required
      Previous value: -[
      -  "storedEmailId",
      -  "accountId",
      -  "accountDisplayName",
      -  "folderAlias",
      -  "toAddresses",
      -  "sizeBytes",
      -  "attachments",
      -  "remoteFlags",
      -  "contentAvailability"
      -]New value: +[
      +  "storedEmailId",
      +  "accountId",
      +  "accountDisplayName",
      +  "folderAlias",
      +  "senderVerification",
      +  "machineAuthorship",
      +  "toAddresses",
      +  "sizeBytes",
      +  "attachments",
      +  "remoteFlags",
      +  "contentAvailability"
      +]
  2. First observedv0.6.0

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.