Skip to main content
Glama
igorolv

mail-mcp-server

search

search
Read-onlyIdempotent

Find locally synced emails by text, sender, recipient, subject, body, attachment content, folder, or date; then read matching messages.

Instructions

Search locally synced messages in one connection. Choose query and field for text search; optionally restrict by folder and dates. Text results are most relevant first. To list messages by date alone, omit query and supply since or until; results are newest first, without snippets.

Subject, body and attachment text support Russian and English word forms; irregular forms and synonyms may be missed. If results are sparse, try fewer words, other forms, synonyms or the other language in separate calls. An empty result does not prove the mail is absent: only synced, indexed content is searched.

Read a hit with getMessage using the same connection and the hit's key. Snippets mark matches as word, but may show only part of a match or body context. If a hit has snippetAttachmentFile, read that attachment with getAttachment using the same connection, the hit's key and file=snippetAttachmentFile. Recognized copies are returned once; copies lists other matching keys and folders. total and paging count these groups.

Input Schema

NameRequiredDescriptionDefault
fieldNoChoose one: any (default; all fields below), subject, body, from, to (includes Cc), attachmentName (whole name or parts), attachmentText (extracted contents), label (mailbox label words, such as Gmail's Inbox, Sent or user labels; connections without labels match nothing). from/to search addresses and names. For an exact address match, use an unquoted full address: field=from, query=user@example.com. This ignores case and display names. any also searches content, so an address there need not be a participant. Without query, field has no effect
limitNoResults per page: 1 to 100, default 20; larger values are capped at 100
queryNoSearch terms, a quoted phrase or a full email address; at most 1000 characters. Words combine with AND (common stop words may be ignored); double quotes make a phrase. No OR/NOT, wildcards, fuzzy matching or field-prefix syntax such as from:. Search alternatives in separate calls. Omit only when since or until is given
sinceNoInclude messages at or after this date/time, using the message Date header, not receipt or download time. Format: YYYY-MM-DD (UTC midnight), or ISO-8601 with Z or an offset, e.g. 2026-10-01T09:00:00+03:00; at most 3 fractional second digits. Messages without a date are excluded
untilNoInclude messages strictly before this date/time; same header and format as since. To include a whole day, use the following day's midnight. Must be later than since when both are given. Messages without a date are excluded
folderNoOne folder key from listFolders, not its display name. Omit to search all folders in the connection
offsetNoDefault 0. For the next page, repeat the same search arguments and use the previous nextOffset. Stop when there is no nextOffset
connectionYesConnection name from listConnections

Output Schema

NameRequiredDescriptionDefault
hitsYesHits, most relevant first; newest first for date-only search.
fieldYesField searched.
queryNoText query; absent for date-only search.
sinceNoApplied since bound, in UTC.
totalYesMatching messages; copies of one message count once.
untilNoApplied until bound, in UTC.
folderNoFolder key searched; absent for all folders.
offsetYesPosition of this page.
connectionYesConnection name.
nextOffsetNoPass as offset to get the next page; absent at the end.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety semantics are covered. The description nevertheless adds real substance beyond them: the corpus is limited to synced and indexed content, an empty result does not prove absence, morphology limits for Russian/English, ranking direction per mode, and deduplicated "recognized copies" counted in total and paging. Not a 4-5 because it does not quantify index freshness or the sync dependency beyond a passing mention.

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?

Purpose is front-loaded, followed by search semantics, then how to read a hit, then result-shape notes; every paragraph has a job. It is dense but slightly over-packed — the getMessage/getAttachment sentences repeat 'using the same connection' twice and could be tightened.

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?

With 8 parameters, an output schema and rich annotations, this covers what remains: query syntax and its limits, date-header semantics, the two result orderings, snippet/copy structure, and the cross-tool hop needed to fetch an attachment. An agent can call it correctly and interpret the response without further guessing.

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%, so the schema carries the per-parameter detail and the description correctly does not repeat it. What it adds is search-quality semantics for query (word forms, synonyms, no field-prefix syntax) and a concrete paging procedure, which meaningfully explains how to drive the parameters rather than restating their types.

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?

Opens with a specific verb and resource plus scope: "Search locally synced messages in one connection." It immediately delineates two modes (text query vs date-only listing) and routes the agent to getMessage/getAttachment for follow-up, which distinguishes it from listMessages/listFolders without needing their schemas.

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?

Explicit when-to-use rules: supply query for text search, omit it when only since/until are given, and try fewer words or the other language if results are sparse. It also names the alternative reading tools (getMessage, getAttachment) and the exact conditions and arguments that select them.

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