Skip to main content
Glama

search-emails

Read-only

Search, list, delta-sync, or thread-group emails — six modes selected by parameters (read-only). With no params: lists recent emails in folder (default inbox).

Instructions

Search, list, delta-sync, or thread-group emails — six modes selected by parameters (read-only). With no params: lists recent emails in folder (default inbox). With query/from/to/subject/date filters: full search (combines via OData filter). With searchExpression (deprecated alias kqlQuery): a raw Microsoft Graph $search expression for advanced server-side search. With deltaMode: true: returns current state plus a deltaToken; pass the token back on the next call for incremental changes only — ideal for inbox monitoring. With groupByConversation: true: returns conversation threads. With conversationId: returns all messages in a single thread. With internetMessageId: looks up a message by its RFC Message-ID header. Personal Outlook.com accounts have limited $search support — this tool falls back through OData filters / boolean filters / recent listing automatically, but structured filters (from/subject/receivedAfter/hasAttachments/unreadOnly) return cleaner results. Returns paged messages with id/subject/from/receivedDateTime/preview by default; use outputVerbosity to expand.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoFilter by recipient email/name. Personal Outlook.com accounts reject the server-side recipient filter, in which case this is matched locally over the 500 most recent messages only (raise with `OUTLOOK_SEARCH_SCAN_LIMIT`). On a large archive, pair `to` with `receivedAfter`/`receivedBefore` to reach older mail; the response says so when the scan was truncated.
fromNoFilter by sender email/name
countNoNumber of results (list default: 25, search default: 10, max: 50)
queryNoSearch query text. Omit for list mode. On personal Outlook.com accounts Graph `$search` is unavailable, so this falls back to a subject substring match (all words must appear in the subject) — precise, but it does NOT search message bodies. Use `searchExpression` when you need body content.
folderNoEmail folder (default: 'inbox')
subjectNoFilter by subject
kqlQueryNoDEPRECATED alias for `searchExpression` (this was never full KQL — it is a Graph `$search` expression). Prefer `searchExpression`.
deltaModeNoEnable delta sync mode. Returns only changes since last sync. Use deltaToken for subsequent calls.
deltaTokenNoToken from previous delta call for incremental sync (deltaMode only)
maxResultsNoMax results per page for delta sync (default: 100, max: 200)
unreadOnlyNoFilter to unread emails only
receivedAfterNoFilter emails received after date (ISO 8601)
conversationIdNoGet all messages in a conversation thread by conversationId.
hasAttachmentsNoFilter to emails with attachments
includeHeadersNoInclude email headers for each message (conversationId only)
receivedBeforeNoFilter emails received before date (ISO 8601)
outputVerbosityNoOutput detail level (default: standard)
searchAllFoldersNoSearch across all mail folders
searchExpressionNoRaw Microsoft Graph `$search` expression for advanced server-side search, e.g. `subject:"invoice"`, `from:github.com`, or `foo OR bar`. Quote your own phrases; a single bare token is auto-quoted. Pair with `searchAllFolders: true` for cross-folder search. Bypasses other search params. NOTE: personal Outlook.com accounts reject field-scoped `$search` outright; since v3.10.0 recognised `from:`/`to:`/`subject:` expressions are translated into the closest equivalent OData filters and retried automatically (a `subject:` term becomes a substring match, so it is close but not identical) (reported as strategy `raw-kql-translated`). Expressions that cannot be translated exactly — free text, `AND`/`OR`, unknown prefixes — are not retried, so use `query` for those there. RELEVANCE, NOT RECENCY: an untranslated expression is answered by Graph `$search` over the whole message including the body, ranked by relevance and not sorted by date, so top hits can look unrelated to a caller expecting a subject match. `query` is the more predictable choice for a term you expect in a subject line; `searchExpression` is the one that reaches body text.
internetMessageIdNoLook up email by Message-ID header (e.g. <abc123@example.com>). For threading/deduplication.
groupByConversationNoList conversations (threads) grouped by conversationId instead of individual emails.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv3.11.1
    • changedInput schema / properties / query / description
      Previous value: -"Search query text. Omit for list mode."New value: +"Search query text. Omit for list mode. On personal Outlook.com accounts Graph `$search` is unavailable, so this falls back to a subject substring match (all words must appear in the subject) — precise, but it does NOT search message bodies. Use `searchExpression` when you need body content."
    • changedInput schema / properties / searchExpression / description
      Previous value: -"Raw Microsoft Graph `$search` expression for advanced server-side search, e.g. `subject:\"invoice\"`, `from:github.com`, or `foo OR bar`. Quote your own phrases; a single bare token is auto-quoted. Pair with `searchAllFolders: true` for cross-folder search. Bypasses other search params. NOTE: on personal Outlook.com accounts field-scoped `$search` is best-effort and may return nothing — prefer `query` there (it has progressive fallback)."New value: +"Raw Microsoft Graph `$search` expression for advanced server-side search, e.g. `subject:\"invoice\"`, `from:github.com`, or `foo OR bar`. Quote your own phrases; a single bare token is auto-quoted. Pair with `searchAllFolders: true` for cross-folder search. Bypasses other search params. NOTE: personal Outlook.com accounts reject field-scoped `$search` outright; since v3.10.0 recognised `from:`/`to:`/`subject:` expressions are translated into the closest equivalent OData filters and retried automatically (a `subject:` term becomes a substring match, so it is close but not identical) (reported as strategy `raw-kql-translated`). Expressions that cannot be translated exactly — free text, `AND`/`OR`, unknown prefixes — are not retried, so use `query` for those there. RELEVANCE, NOT RECENCY: an untranslated expression is answered by Graph `$search` over the whole message including the body, ranked by relevance and not sorted by date, so top hits can look unrelated to a caller expecting a subject match. `query` is the more predictable choice for a term you expect in a subject line; `searchExpression` is the one that reaches body text."
    • changedInput schema / properties / to / description
      Previous value: -"Filter by recipient email/name"New value: +"Filter by recipient email/name. Personal Outlook.com accounts reject the server-side recipient filter, in which case this is matched locally over the 500 most recent messages only (raise with `OUTLOOK_SEARCH_SCAN_LIMIT`). On a large archive, pair `to` with `receivedAfter`/`receivedBefore` to reach older mail; the response says so when the scan was truncated."
  2. Addedv3.9.1
  3. Removedv3.9.0
  4. Changed1 schema field changedv3.7.4
    • addedInput schema / additionalProperties
      Added value: +false
  5. First observedv3.4.1

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses fallback behavior on personal Outlook.com accounts, delta-token handshake semantics, relevance-vs-recency ranking, local scan truncation, and the deprecated kqlQuery alias. No statement contradicts the 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 front-loaded with a mode summary and then provides dense but relevant behavioral detail. Some implementation-specific details like version numbers or strategy names are borderline noise, but the length is largely justified by the tool's 21-parameter complexity.

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 no output schema, the description explains the default return shape (id/subject/from/receivedDateTime/preview) and the outputVerbosity expansion path. It also covers mode prerequisites, delta-token exchange, account-specific limitations, and fallbacks, making the tool actionable without requiring the agent to infer critical behaviors.

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?

The input schema already documents all 21 parameters in detail, so the baseline is high. The description adds a valuable orchestration layer: which parameter combinations select list/search/delta/thread modes and how query vs searchExpression interact. It does not need to repeat per-parameter definitions.

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 first sentence names specific verbs and a resource: 'Search, list, delta-sync, or thread-group emails' and enumerates six modes. It clearly distinguishes this read-only search/list tool from send/update/draft siblings. The scope is unambiguous.

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 gives clear context for when to use each mode: deltaMode for incremental inbox monitoring, searchExpression for body/advanced search, and query as the more predictable subject-line search. It does not explicitly name sibling tools like read-email as alternatives, so it stops short of full exclusion guidance.

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