Skip to main content
Glama

List the mail feed

list_feed

List the user's mail the way Busymail groups it: clusters of related conversations within a category, newest first. This is the same grouping the user sees on their feed and the best starting point for understanding what is in the mailbox. Each cluster carries its key, category, generated summary where one exists, and how many conversations and emails it holds. Open a cluster with get_cluster, or a single conversation with get_conversation. Narrow by category, or by date with after and before, each optional on its own. If the result comes back with has_more true it was capped at limit and there is no way to page past it: narrow with category, after or before to see the rest. The response also carries two counts, neither narrowed by the category argument: unreadable_conversations, the conversations holding mail extraction gave up on, and processing_conversations, the conversations whose mail is still being read and that no cluster shows yet. Both run over the after and before window asked for, never reaching back past the window this mailbox is read over, and both count conversations where total counts clusters, so neither may be added to total. They never name the same conversation. A non-zero count on either means this listing omits mail, and a zero on one alone says nothing about the other. Both being zero still does not make the listing whole: mail extraction has read but has not yet summarised is in no cluster either.

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": "list_feed"
  }
}

Input Schema

NameRequiredDescriptionDefault
afterNoOnly clusters whose newest mail arrived from this date onwards, as YYYY-MM-DD. INCLUSIVE: the date itself is included, from midnight. Optional on its own: you may give after, before, both, or neither.
limitNoMaximum clusters to return (1-200, default 50).
beforeNoOnly clusters whose newest mail arrived strictly before this date, as YYYY-MM-DD. EXCLUSIVE: the date itself is excluded entirely, so for a single day pass the NEXT day here - one day is after: 2026-07-05, before: 2026-07-06. Optional on its own: you may give after, before, both, or neither.
categoryNoLimit to one category. Omit for all categories.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden, and it does: it discloses the hard cap at limit with no pagination, the two side counts, that the counts are not narrowed by category, that they count conversations where total counts clusters, and that they are bounded by the readable window. It also warns that zero counts do not guarantee completeness because unsummarised mail appears in no cluster.

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?

Front-loaded with purpose and next steps, then the caveats. The closing passage on the two counts is dense and repetitive in places ('both count... neither may be added... never name the same conversation'), but each clause carries real behavioral information rather than filler.

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 and no annotations, the description compensates by describing the returned cluster fields, the total, and the two auxiliary counts with their exact semantics. For a four-parameter listing tool with tricky truncation behavior, an agent has everything needed to call it and interpret the result.

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 coverage is 100%, so the baseline would be 3, but the description adds meaning the schema does not: it clarifies that after/before/category are each independently optional and links limit to the has_more cap behavior. That linkage is the only real addition, keeping it below 5.

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?

States a specific verb and resource ('List the user's mail') plus a distinctive shape: clustered, category-grouped, newest first. It explicitly routes the agent onward to get_cluster and get_conversation, so it's clearly distinguishable from siblings like search, list_sent, and list_categories.

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 explicit when-to-use ('best starting point for understanding what is in the mailbox'), names the alternatives for drilling down, and describes exactly how to narrow with category/after/before. It even explains the recovery path when has_more is true, which is the main wrong-turn an agent could make.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources