Skip to main content
Glama
Sign In

Inbox Triage

by com.getinboxtriage
OverviewDiscussionsAdmin

Search the whole mailbox on the provider, not just the synced window

search_mailbox
Idempotent

Searches subject/from/body on the provider itself (Gmail search, IMAP SEARCH, or Graph $search), not just the already-synced window list_messages reads, so older mail the sync window has not reached yet (e.g. "the lease agreement from 2022") can still be found. Matches are pulled into the local store so get_message and list_messages can open them afterward; they stay available until they age out of their folder's window the normal way, the same as load_older_messages. Spam and Trash are never searched. Returns newest first, capped at limit (default 20, max 50). date is always ISO 8601, like every other tool. snippet is the provider's own preview when it has one, falling back to the subject only when nothing else exists.

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>",
      "query": "<query>"
    },
    "name": "search_mailbox"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMax results to return, clamped 1..50. Default 20.
queryYesWords to search for in subject/sender/body, 1-200 characters.
folderNoRestrict to one of this inbox's selected folders (see list_folders). Omit to search the whole mailbox except Spam/Trash.
inboxIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

The description goes well beyond the annotations: it explains that this is a provider-side search whose hits are pulled into the local store (which explains readOnlyHint=false despite being semantically a read), how long those cached hits persist and when they age out, that Spam/Trash are never searched, and the result ordering. These are exactly the behaviors an agent cannot infer from readOnlyHint/idempotentHint alone.

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 distinguishing point (provider-side search vs. synced window) is front-loaded in the first clause, and every sentence carries real information. It is dense and long for a single paragraph, but no sentence is 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?

There is no output schema, and the description compensates by describing the return set: newest first, capped at limit, ISO 8601 dates, and snippet provenance with a fallback. With those plus the caching lifetime and Spam/Trash exclusion, an agent has everything needed to call and interpret it.

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 75%, so the schema already documents query, folder, and limit well. The description repeats the limit default/max and doesn't add syntax guidance for `query` (e.g. whether phrases or operators are supported) or clarify the folder/whole-mailbox interaction beyond what the schema says. Baseline 3 fits when structured fields carry the load.

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?

The description states a specific verb+resource (searches subject/from/body on the provider itself) and explicitly separates it from the already-synced window that list_messages reads. It even names the underlying provider mechanisms (Gmail search, IMAP SEARCH, Graph $search), leaving no ambiguity about which sibling tool this is.

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?

It gives a concrete when-to-use scenario (older mail the sync window has not reached, e.g. 'the lease agreement from 2022') and positions itself against list_messages and load_older_messages. What's missing is an explicit inverse rule, e.g. 'for mail already in the synced window use list_messages instead,' which is only strongly implied.

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

All Inbox Triage toolsInspect
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