Skip to main content
Glama

Search Emails

search-emails
Read-onlyIdempotent

Search, list, delta-sync, or thread-group emails in Outlook Assistant; filter by sender, recipient, subject, dates, attachments, unread status, shared mailboxes, or conversation.

Instructions

Search, list, delta-sync or thread-group emails (read-only); parameters set the mode. No params: recent emails in folder (default inbox). query/from/to/subject/date filters: search, combined as an OData filter. searchExpression (deprecated alias kqlQuery): a raw Graph $search expression. deltaMode: true: current state plus a deltaToken to pass back next time for changes only. groupByConversation: true: conversation threads. conversationId: every message in one thread. internetMessageId: the message with that RFC Message-ID. sharedMailbox (alias email) searches a shared/delegated mailbox, custom folders and nested paths included. Personal Outlook.com accounts have limited $search, so the tool falls back to OData filters and a recent listing automatically; structured filters (from/subject/receivedAfter/hasAttachments/unreadOnly) give cleaner results there. Returns up to count messages (id/subject/from/receivedDateTime/preview); outputVerbosity expands them.

Input 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). There is no page cursor: when the result says more emails are available, raise `count` or narrow `receivedAfter`/`receivedBefore`.
emailNoAlias for `sharedMailbox`.
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'). Accepts a well-known name, a custom/localized display name, or a nested path like `Inbox/Subfolder`.
subjectNoFilter by subject
kqlQueryNoDEPRECATED alias for `searchExpression` (this was never full KQL — it is a Graph `$search` expression).
deltaModeNoEnable delta sync mode. Returns only changes since last sync. Use deltaToken for subsequent calls; an initial sync larger than `maxResults` arrives over several pages, each returning a continuation token to pass back until a delta token is returned. Honors `sharedMailbox`/`email` (and custom `folder` paths) to sync within a shared/delegated mailbox.
deltaTokenNoToken from previous delta call for incremental sync (deltaMode only). The token is authoritative — it encodes its own mailbox and folder, so `folder`/`sharedMailbox` are ignored and a token from a different mailbox is rejected.
maxResultsNoDelta sync page size (deltaMode only): 1-200, default 100, sent to Graph as the `Prefer: odata.maxpagesize` header. It sizes each page, not the whole sync: while a page returns a continuation token, keep calling with that token until a delta token is returned, and pass the same `maxResults` on every page (an omitted value means 100).
unreadOnlyNoFilter to unread emails only
receivedAfterNoFilter emails received after date (ISO 8601)
sharedMailboxNoEmail address of a shared/delegated mailbox to search (default: the signed-in account). Combine with `folder` (incl. custom subfolders/paths) or `searchAllFolders`. Work/school only; needs the server opt-in setting OUTLOOK_SHARED_MAILBOX (otherwise the call is refused with setup guidance).
conversationIdNoGet the messages in a conversation thread by conversationId, oldest first (up to 100; a longer thread is marked truncated — use `export target=conversation` for up to 1000). Honors `sharedMailbox`/`email` to thread within a shared/delegated mailbox.
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, escaping any `"` or `\` inside them with a backslash; a single bare token is auto-quoted and escaped for you. 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. Honors `sharedMailbox`/`email` to look up within a shared/delegated mailbox.
groupByConversationNoList conversations (threads) grouped by conversationId, not individual emails. Honors `sharedMailbox`/`email` (and custom `folder` paths) to group within a shared/delegated mailbox.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed12 schema fields changedv3.14.1
    • changedInput schema / properties / conversationId / description
      Previous value: -"Get all messages in a conversation thread by conversationId."New value: +"Get the messages in a conversation thread by conversationId, oldest first (up to 100; a longer thread is marked truncated — use `export target=conversation` for up to 1000). Honors `sharedMailbox`/`email` to thread within a shared/delegated mailbox."
    • changedInput schema / properties / count / description
      Previous value: -"Number of results (list default: 25, search default: 10, max: 50)"New value: +"Number of results (list default: 25, search default: 10, max: 50). There is no page cursor: when the result says more emails are available, raise `count` or narrow `receivedAfter`/`receivedBefore`."
    • changedInput schema / properties / deltaMode / description
      Previous value: -"Enable delta sync mode. Returns only changes since last sync. Use deltaToken for subsequent calls."New value: +"Enable delta sync mode. Returns only changes since last sync. Use deltaToken for subsequent calls; an initial sync larger than `maxResults` arrives over several pages, each returning a continuation token to pass back until a delta token is returned. Honors `sharedMailbox`/`email` (and custom `folder` paths) to sync within a shared/delegated mailbox."
    • changedInput schema / properties / deltaToken / description
      Previous value: -"Token from previous delta call for incremental sync (deltaMode only)"New value: +"Token from previous delta call for incremental sync (deltaMode only). The token is authoritative — it encodes its own mailbox and folder, so `folder`/`sharedMailbox` are ignored and a token from a different mailbox is rejected."
    • addedInput schema / properties / email
      Added value: +{
      +  "description": "Alias for `sharedMailbox`.",
      +  "type": "string"
      +}
    • changedInput schema / properties / folder / description
      Previous value: -"Email folder (default: 'inbox')"New value: +"Email folder (default: 'inbox'). Accepts a well-known name, a custom/localized display name, or a nested path like `Inbox/Subfolder`."
    • changedInput schema / properties / groupByConversation / description
      Previous value: -"List conversations (threads) grouped by conversationId instead of individual emails."New value: +"List conversations (threads) grouped by conversationId, not individual emails. Honors `sharedMailbox`/`email` (and custom `folder` paths) to group within a shared/delegated mailbox."
    • changedInput schema / properties / internetMessageId / description
      Previous value: -"Look up email by Message-ID header (e.g. <abc123@example.com>). For threading/deduplication."New value: +"Look up email by Message-ID header (e.g. <abc123@example.com>). For threading/deduplication. Honors `sharedMailbox`/`email` to look up within a shared/delegated mailbox."
    • changedInput schema / properties / kqlQuery / description
      Previous value: -"DEPRECATED alias for `searchExpression` (this was never full KQL — it is a Graph `$search` expression). Prefer `searchExpression`."New value: +"DEPRECATED alias for `searchExpression` (this was never full KQL — it is a Graph `$search` expression)."
    • changedInput schema / properties / maxResults / description
      Previous value: -"Max results per page for delta sync (default: 100, max: 200)"New value: +"Delta sync page size (deltaMode only): 1-200, default 100, sent to Graph as the `Prefer: odata.maxpagesize` header. It sizes each page, not the whole sync: while a page returns a continuation token, keep calling with that token until a delta token is returned, and pass the same `maxResults` on every page (an omitted value means 100)."
    • 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: 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."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, escaping any `\"` or `\\` inside them with a backslash; a single bare token is auto-quoted and escaped for you. 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."
    • addedInput schema / properties / sharedMailbox
      Added value: +{
      +  "description": "Email address of a shared/delegated mailbox to search (default: the signed-in account). Combine with `folder` (incl. custom subfolders/paths) or `searchAllFolders`. Work/school only; needs the server opt-in setting OUTLOOK_SHARED_MAILBOX (otherwise the call is refused with setup guidance).",
      +  "type": "string"
      +}
  2. 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."
  3. Addedv3.9.1
  4. Removedv3.9.0
  5. Changed1 schema field changedv3.7.4
    • addedInput schema / additionalProperties
      Added value: +false
  6. First observedv3.4.1

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive, openWorld, so the bar is lower, yet the description still adds real behavior: automatic OData fallback on personal accounts, `deltaToken` being authoritative/rejected cross-mailbox, shared-mailbox opt-in refusal, and scan truncation. It stops short of describing pagination cursor absence and rate limits in the description itself, though those appear 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?

The mode summary is front-loaded and each clause is terse shorthand rather than prose, but the single dense paragraph repeats substantial ground already covered by the 23 schema descriptions, making it heavier than strictly necessary.

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 23-parameter multi-mode tool with no output schema, the description covers mode selection, per-mode caveats, fallback behavior, error/opt-in conditions, and the return shape (id/subject/from/receivedDateTime/preview plus outputVerbosity). Nothing essential to correct invocation 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 coverage the baseline is 3, and the schema already documents each parameter thoroughly; the description adds connective meaning by framing parameters as mode selectors and flagging the `kqlQuery` deprecation and the relevance-not-recency caveat for `searchExpression`. That is genuine added value beyond the schema fields.

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 set and resource: 'Search, list, delta-sync or thread-group emails (read-only); parameters set the mode.' An agent immediately understands this is a multi-mode read tool and that the parameters select the mode, which cleanly separates it from read-email and folders.

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?

Gives an explicit mode-selection map (no params = recent listing; filters = OData search; searchExpression = raw $search; deltaMode = sync; groupByConversation = threads) and names alternatives where it matters, e.g. preferring structured filters or `query` over `searchExpression` on personal Outlook.com accounts.

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