Inbox Triage

Review newsletters and mailing lists

review_unsubscribes

Read-onlyIdempotent

Lists newsletter and mailing-list senders so the person can review and unsubscribe.

Lists the newsletter and mailing-list senders in the synced mail across all inboxes (or one), one row per sender: how many messages, how many unread, the newest date, whether one-click unsubscribe is available, and a noise reading: perWeek (messages per week over the last four weeks), unreadRatio, noise (high, medium, low: how much the person ignores a frequent sender; never high for a VIP or someone they have replied to) and a suggestion (unsubscribe, archive, keep). A known-good sender is never noise, and a service's notification stream (notifications@, alerts@; notification: true) is always keep: its settings live in that service. Noisiest first. Paged: returns at most limit senders (default 25, max 100) starting at offset, plus totalSenders/hasMore/nextOffset; page with offset rather than assuming one call returns every sender. Rows no longer carry messageIds (only hasInboxMail, a boolean): to archive a sender's mail use archive_messages with sender { inboxId, email }, not a raw id list. Every call also includes a numbered text list with previews (same as show_inbox) and a top-level sayToHuman summary; apps that cannot show the list (Claude Code and other terminals) should show the text as-is, without the block marked for the agent. When the person names rows ("unsubscribe from 1 and 3"), take inboxId, email, and newestMessageId from that block or from structuredContent.rows (field n is the row number). Unsubscribe with propose_unsubscribe and the person's approval; archive a sender's mail with archive_messages and sender. VIP senders are marked and never archived in bulk.

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

Input Schema

Name	Required	Description
`inbox`	No	Inbox name (like "Work Gmail"), inbox id, or leave empty for all inboxes
`limit`	No	Senders per page, 1 to 100. Default 25.
`offset`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 26, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already mark it read-only, idempotent, non-destructive, but the description adds substantial non-obvious behavior: the noise model (perWeek over four weeks, unreadRatio, never high for VIPs or replied-to senders), that notification streams are always 'keep', sorting (noisiest first), and pagination envelope fields (totalSenders/hasMore/nextOffset). This is context beyond any structured field.

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?

Content is front-loaded and nearly every clause carries operational value, but the opening sentence largely restates the second, and the dense single-block prose (noise rules, paging, row numbering, terminal rendering all in one paragraph) makes it harder to scan than it needs to be.

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 fully covers the return shape (per-sender fields, envelope totals, hasMore/nextOffset, numbered text block, sayToHuman), the row-numbering contract used by 'unsubscribe from 1 and 3', and what it deliberately no longer returns (messageIds). Nothing an agent needs 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.

Parameters4/5

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

Schema coverage is 67% and the description compensates well: it clarifies limit defaults (25) and caps (100), states offset paging semantics and why to use it, and notes inbox can be a name, id, or empty for all. It adds meaning beyond the schema without fully specifying the offset default behavior, so not 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?

The description states a specific verb and resource — lists newsletter/mailing-list senders in synced mail, one row per sender — which clearly distinguishes it from siblings like list_messages or show_inbox. It even names the exact per-sender fields returned, so an agent knows precisely what this tool yields.

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?

It routes explicitly to alternatives: unsubscribe via propose_unsubscribe with approval, archive a sender's mail via archive_messages using sender { inboxId, email }, and it warns against doing either with raw message ids. It also gives paging guidance (page with offset rather than assuming everything returns in one call) and terminal-app rendering guidance.

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?