Inbox Triage

Load older messages for one folder (extends only that folder's window)

load_older_messages

Fetches messages older than the current synced window for exactly one folder of one inbox. Extends only that folder's window for this inbox, never the default sync window (~300 iCloud/IMAP/Microsoft; Gmail's stored window grows to 300 over its first syncs, 40 newest per sync) that other folders and inboxes still use, and never past the hard per-folder cap of 1000 messages (refuses once reached). Gmail stays metadata-first, exactly like sync_inbox (format=metadata; open a message with get_message for the full body). Coming soon for Microsoft (returns unsupported:true; use sync_inbox's existing window there for now). A subsequent sync_inbox will not trim these older messages back out. If the inbox needs reconnecting, returns needsReconnect/sayToHuman/reconnectUrl instead of fetching. May return { ok:false, busy:true, sayToHuman } instead of fetching, when a sync for this inbox is already running or another load_older_messages call for this same folder is already in flight -- wait a bit and call again rather than retrying immediately. A successful call may also carry a note field (e.g. when added:0 but exhausted:false: nothing new this call, but more may still be older) -- read it and call again to continue rather than treating that as "nothing left".

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "inboxId": "<inboxId>",
      "folder": "<folder>"
    },
    "name": "load_older_messages"
  }
}

Input Schema

Name	Required	Description
`count`	No	How many older messages to try to fetch. Default 50 for Gmail, 25 for iCloud/IMAP. Clamped 1..200 for Gmail, 1..25 for iCloud/IMAP (each message is a separate body download), so call again for more.
`folder`	Yes	Canonical folder id/name already in this inbox's selected folders (see list_folders / message.folder), not an arbitrary mailbox.
`inboxId`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 26, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Discloses far beyond annotations: window-growth semantics per provider, the hard 1000-message per-folder cap and refusal behavior, that subsequent sync_inbox won't trim these messages back out, reconnect handling (needsReconnect/sayToHuman/reconnectUrl), and concurrency busy responses. These are all consistent with readOnlyHint=false and idempotentHint=false (state is extended, repeat calls fetch more).

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 the core purpose and scope before edge cases, and every clause carries real operational information. However it is one dense paragraph with several run-on parentheticals (provider window details), which slightly hurts scanability.

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 state-extending tool with no output schema, the description covers everything an agent needs: cap limits, failure/return shapes (busy, needsReconnect, note), provider variance, and continuation semantics. Nothing required to call it correctly is missing.

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?

Schema coverage is 67% and the schema itself documents `count` (defaults, clamps per provider) and `folder` (canonical id, references list_folders). The description adds no per-parameter syntax or format beyond that; `inboxId` remains undocumented in both. Baseline 3 fits since the schema does most of the work.

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 ('fetches messages older than the current synced window') plus a hard scope constraint ('exactly one folder of one inbox'). The title and description together make it unmistakable against sync_inbox, which the description explicitly contrasts.

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?

Explicitly routes the agent: use get_message for full bodies (Gmail metadata-first), Microsoft currently unsupported so fall back to sync_inbox, and on busy:true wait and call again rather than retry immediately. It also tells the agent to read the `note` field and call again when exhausted:false — actionable when/when-not guidance throughout.

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

All Inbox Triage tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?