Skip to main content
Glama
churichard

Fluxmail

by churichard
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

list_emails

Read-only

Retrieve and filter email messages from connected accounts with metadata, previews, and pagination. Search by folder, sender, dates, unread status, or full-text to find specific messages quickly.

Instructions

List emails from the user's connected mailbox with metadata and optional previews. Filter by folder, sender, unread, dates, etc. Paginate with pageToken. Use get_email for full bodies. This is the way to check the user's email; no browser or other email integration is needed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNo
fromNo
readNo
textNoLiteral full-text search terms
afterNoYYYY-MM-DD received date, inclusive in UTC
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

A4.2/5.0
Behavior4/5

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

readOnlyHint already establishes the safety profile, and the description adds behavior beyond that: metadata with optional previews, filtering by multiple criteria, pagination with pageToken, and full bodies delegated to get_email. It does not describe ordering or the exact response envelope, but for a read-only listing tool this is strong added context.

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?

Three sentences with the core action front-loaded, followed by filters, pagination, and routing to get_email. There is no filler; even the final integration claim earns its place by telling the agent this is the canonical mailbox check.

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

Completeness4/5

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

For a read-only list tool with a rich schema, this is largely complete: the agent learns the purpose, main filters, pagination behavior, and when to escalate to get_email. It stops short of distinguishing from search_emails for advanced queries and does not state the response shape beyond 'metadata and optional previews,' leaving minor gaps for a 16-parameter surface.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds a useful high-level framing by grouping filters by folder, sender, unread, and dates, and it correctly ties pageToken to pagination. However, with 16 parameters and only 63% schema coverage, it does not meaningfully compensate for undocumented parameters like to, read, starred, subject, or hasAttachment, leaving the agent to infer their 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?

Opens with a specific verb and resource: 'List emails from the user's connected mailbox with metadata and optional previews.' It also differentiates from get_email by directing full bodies there, making the role of this tool clear relative to a close sibling.

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: use this to check the user's email without a browser or separate email integration, and use get_email when full bodies are needed. However, it does not mention search_emails or search_emails_batch as alternatives or say when those should be preferred, so exclusions are incomplete.

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