Skip to main content
Glama
churichard

Fluxmail

by churichard
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

search_emails

Read-only

Find emails in any account using flexible query syntax for sender, recipient, subject, folder, read/starred state, attachments, and date filters.

Instructions

Search one account with typed portable syntax. The query supports text, from:, to:, subject:, in:, read and starred states, attachments, and date filters.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNo
fromNo
readNo
afterNoYYYY-MM-DD received date, inclusive in UTC
queryYesTyped portable search syntax
beforeNoYYYY-MM-DD received date, exclusive in UTC
folderNoFolder role (inbox, sent, drafts, trash, spam, starred, archive, all) or a label/folder name. Use all or omit this field to search all mail except Spam and Trash. An IMAP server's \All mailbox may use different rules.
starredNo
subjectNo
pageSizeNoDefaults to 25
accountIdNoAccount to operate on. Optional when exactly one account is connected.
pageTokenNonextPageToken from a previous call
hasAttachmentNo
includeSnippetNoRequest or suppress message previews
rawProviderQueryNoProvider-native Gmail syntax or Outlook KQL for one compatible account
includeSearchContextNoInclude a match-centered body excerpt; requires a portable text query

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.10.0
    • addedInput schema / properties / includeSearchContext
      Added value: +{
+  "description": "Include a match-centered body excerpt; requires a portable text query",
+  "type": "boolean"
+}
  2. Changed1 schema field changedv0.9.0
    • addedInput schema / properties / includeSnippet
      Added value: +{
+  "description": "Request or suppress message previews",
+  "type": "boolean"
+}
  3. First observedv0.1.0

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, and the description does not contradict that. It adds some behavioral context by clarifying the one-account scope and the supported query syntax fields, but it does not disclose pagination behavior, default folder exclusions, provider-specific caveats, or response shape.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two compact sentences with the action, resource, and scope front-loaded, followed by a concise enumeration of syntax features. There is no filler, redundancy, or repetition of schema details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A 16-parameter search tool with no output schema needs more than a two-sentence description. It omits result format and pagination, when to prefer search_emails_batch or list_emails, and default search scope and provider-specific behavior. The parameter descriptions fill some gaps, but top-level usage and output context are still 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?

Schema description coverage is 63%, and the description adds valuable meaning beyond the schema by explaining what the portable query syntax accepts: text, from:, to:, subject:, in:, read/starred states, attachments, and date filters. This is especially useful because the schema's query field only says 'Typed portable search syntax'. It does not cover every parameter, but the core search parameters are meaningfully explained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Search') and resource ('one account') and introduces 'typed portable syntax', which clearly differentiates it from ordinary listing. It does not explicitly name sibling tools, but the scope and syntax focus are enough to convey the tool's role.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use or when-not-to-use guidance. It does not mention search_emails_batch for multi-account searches, list_emails for simpler listing, or get_email for retrieving a known message. The intended usage must be inferred from the tool name and sibling list.

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

Deploy Server

Other Tools