Skip to main content
Glama

Gmail Search Emails

gmail_search_emails
Read-onlyIdempotent

Search Gmail messages or whole conversations by query, labels, sender, recipient, subject, unread status, attachments, and age, with paginated results and optional Spam/Trash inclusion.

Instructions

Find Gmail messages, or with group_by_thread whole conversations, by a Gmail search query, labels (names or IDs) and helper filters (sender, recipient, subject, unread, attachments, age), ANDed together, a page at a time; Spam and Trash are left out unless include_spam_trash is true. Use gmail_get_mail_digest for a plain recent feed and gmail_check_mail_updates to poll for new mail since a saved checkpoint. Returns messages (id, thread_id, from, subject, date, snippet, unread, has_attachments, is_draft, is_sent) or threads (the same plus message_count), next_page_token, result_size_estimate and effective_query. Read bodies with gmail_read_emails or gmail_get_thread.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "gmail_search_emails"
  }
}

Input Schema

NameRequiredDescriptionDefault
queryNoGmail search query in the same syntax as the Gmail search box, e.g. 'from:ana@example.com newer_than:7d has:attachment'. It is wrapped in parentheses and ANDed with the helper filters; with no query, labels or filters, all mail outside Spam and Trash matches.
labelsNoOnly mail that carries every one of these labels, given by name as shown in Gmail (e.g. 'Clients/Acme') or by ID; system labels such as INBOX or UNREAD match case-insensitively. An unknown or ambiguous name fails with not_found and the candidate labels.
to_emailNoRecipient filter, added to the query as to:"<value>", e.g. 'team@example.com'.
is_unreadNoWhen true, adds is:unread so only unread messages match; false adds nothing, so read mail matches too.
from_emailNoSender filter, added to the query as from:"<value>"; an address or part of a name, e.g. 'ana@example.com'.
page_tokenNoThe next_page_token from the previous response of this same call; omit for the first page.
max_resultsNoMessages (or, with group_by_thread, conversations) per page, 1 to 500 (default 25); each hit is fetched separately, so large pages are slower.
has_attachmentNoWhen true, adds has:attachment so only messages with attachments match; false adds nothing.
group_by_threadNoWhen true, returns conversations instead of messages: threads, each summarized by its newest message plus message_count. Default false returns individual messages.
newer_than_daysNoOnly mail from the last N days, 1 to 3650, translated to Gmail's newer_than:{N}d query operator.
subject_containsNoPhrase that must appear in the subject line, added to the query as subject:"<value>".
include_spam_trashNoAlso return items in Spam and Trash; by default they are excluded.

Output Schema

NameRequiredDescriptionDefault
countNoNumber of items in this response.
threadsNo
has_moreNoWhether another page is available.
messagesNo
fetched_atNoRFC3339 time when this response was fetched.
effective_queryNo
next_page_tokenNoOpaque token for the next page, or null.
account_timezoneNo
result_size_estimateNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.1.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety bar is covered. The description still adds real behavioral context beyond them: Spam and Trash are silently excluded unless include_spam_trash is true, results are paged, and the return payload's shape including next_page_token and effective_query is disclosed. It does not mention the per-hit fetch cost or latency caveat, which lives only in the schema.

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?

Every clause carries information and the purpose is front-loaded before the sibling routing, with no filler. However, it is delivered as one long semicolon-chained sentence, which makes the return-field list and pagination notes harder to scan than they need to be.

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 12-parameter search tool with an output schema and full annotation coverage, the description covers purpose, filter combination logic, exclusions, pagination entry point, sibling routing and follow-up read tools. Nothing an agent needs in order to call it correctly is missing.

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?

With 100% schema description coverage the baseline is 3, and the description genuinely adds meaning beyond the schema by stating that all query parts are ANDed together and that an empty call matches all mail outside Spam and Trash. It also notes labels accept names or IDs and that group_by_thread changes both the unit of results and the page size 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 a specific verb and resource ('Find Gmail messages'), states the full scope (query, labels, helper filters, ANDed, paged), and calls out the group_by_thread variant explicitly. It is easily distinguished from gmail_get_mail_digest and gmail_check_mail_updates, which are named.

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?

It explicitly routes the agent: use gmail_get_mail_digest for a plain recent feed, gmail_check_mail_updates to poll since a checkpoint, and gmail_read_emails or gmail_get_thread to read bodies. That is concrete when-to-use-this-vs-alternatives guidance covering three siblings.

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