Skip to main content
Glama
Sign In

Inbox Triage

by com.getinboxtriage
OverviewDiscussionsAdmin

Show the inbox

show_inbox
Read-onlyIdempotent

Shows the person's mail as an interactive, actionable list.

Shows the person their mail across all inboxes (or one) as an interactive list they can act on: open a message, archive, trash, mark as spam, star, label, select several, and undo. Use it only when the person asks to see, browse or click through their mail ("show me my inbox", "let me look"). For questions ("what needs me today", "anything urgent", "any scams") answer in chat with get_brief or list_messages instead: the view sits above your answer and pushes it down. Always pass the filter that matches the request: "today" for today's mail (and pass timeZone if you know it), "since" for "since I last checked", "vip" for VIPs, "newsletters" for newsletters, "reply" for mail from a person addressed to you that you have not answered, "all" for everything. The default "needs" is unread or VIP mail still in the inbox, of any age, so do not use it for "today". since (ISO) narrows any filter, not only "since" itself, so "newsletters from this week" is one call: filter "newsletters" with since set to the start of the week. Always includes a numbered text list with previews (the id block, and a top-level sayToHuman summary) in content/text no matter what the client is, alongside the interactive view for hosts that support it. Apps that cannot show the list (Claude Code and other terminals) get the same rows as a numbered text list with previews: show it to the person as it is (in a code block, without the id block at the end), then add two or three sentences on what matters most. In apps that show the list, do not repeat it. Rows are numbered across pages; when the person refers to rows ("archive 2 and 5", "open 3"), map each number to inboxId and messageId using the id block at the end of the text or structuredContent.rows (field n), then use archive_messages (or the other message tools), get_message, or create_draft. Reply and unsubscribe from the list come back to you as chat requests; sending, unsubscribing and reporting spam still need the person's approval.

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

Input Schema

NameRequiredDescriptionDefault
inboxNoInbox name (like "Work Gmail"), inbox id, or leave empty for all inboxes combined
limitNoRows per page, 1 to 50. Default 25.
sinceNoISO time. Applies to whichever filter is set, not only "since": combine it with any filter for a single call ("newsletters from this week" is filter: newsletters, since: <start of this week>). For filter "since" alone, defaults to when the person last finished triage.
filterNoneeds (default: unread or VIP mail in the inbox, newsletters left out, unread automated mail older than attentionDays left out), vip, newsletters, today, since (since the last triage), all, reply: mail from a person addressed to you that you have not answered
offsetNo
timeZoneNoThe person's IANA time zone, like America/Chicago, so "today" means their calendar day. Without it, "today" is the last 24 hours.

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?

Although annotations already declare read-only/non-destructive, the description adds substantial context the annotations cannot: what actions the interactive list exposes, that content/text always contains a numbered list regardless of client, that terminals get text-only output, row numbering persisting across pages, and that sending/unsubscribing/spam actions require approval.

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 routing before mechanics, and most sentences carry actionable information (filter mapping, terminal fallback, row-number mapping). It is a long single block, however, and the filter guidance partially duplicates the enum description, making it denser than strictly necessary.

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, the description compensates fully by explaining the return surface (content/text numbered list, id block, structuredContent.rows with field n) and how hosts that cannot render the view should handle it. Nothing an agent needs to call or interpret this tool is 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 coverage is high (83%), so baseline is 3, but the description adds real meaning the schema does not: the default 'needs' semantics (unread or VIP, any age, newsletters excluded), that 'since' narrows any filter and not just the 'since' filter, with a worked example. It largely restates filter vocabulary that the enum already covers, which keeps it from a 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 ('Shows the person's mail as an interactive, actionable list') and immediately clarifies scope (all inboxes or one). It explicitly distinguishes itself from get_brief and list_messages, which handle question answering, so an agent can tell the siblings apart.

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 ('show me my inbox', 'let me look') and when-not ('what needs me today', 'anything urgent') with named alternatives and the reason (the view pushes the answer down). It also prescribes exactly which filter to pass for each kind of request, including that 'needs' is not for 'today'.

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