Skip to main content
Glama
Sign In

Inbox Triage

by com.getinboxtriage
OverviewDiscussionsAdmin

Inbox zero: apply decisions to a batch

inbox_zero_decide
Destructive

Applies the person's decisions to the batch from inbox_zero_start, then returns the next batch and a new batchId; when it is empty, call inbox_zero_stop. Pass the batchId and { n, action, until?, reason? } per row: archive, trash, snooze (needs until), star, label (labelIds), leave, handled, or reply. reply returns a draft hint for create_draft; nothing is sent from here. handled keeps a message in the inbox but out of needs until new mail arrives on its thread; handled also marks the message read. rules ({ action, by: { sender?, inbox?, olderThanDays?, range? }, until? }) act on every matching undecided message, for "archive everything from this sender"; each chunk returns an undoId in ruleUndoIds, and VIP rows are skipped except by a handled or leave rule, and a trash rule skips mail from people (trash those by naming them); more than 25 archives or trashes from rules returns a preview with a confirmToken first and moves nothing, so ask the person and repeat the call with it; by.sender may be a whole domain written as @example.com. Every change returns an undoId. ask:true asks the person in their app to apply all suggestions, answer in chat, or skip the batch; askedInApp tells you whether they answered. When the client cannot ask, the result carries a decideUrl: give the person that link, and call inbox_zero_decide as usual if they answer in chat instead. Work on your own only on a clear instruction or a saved agentRules rule; otherwise suggest and wait. Prefer archive over trash; report counts and undo ids.

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

Input Schema

NameRequiredDescriptionDefault
askNoAsk the person in their app about the returned batch (hosts with form prompts only). Default false.
rulesNoBulk rules over ALL undecided rows, not just the batch; VIP rows are skipped
batchIdNoThe batchId of the list the person is answering
decisionsNo
confirmTokenNoWhen rules would archive or trash more than 25 messages, the first call returns a preview and moves nothing; repeat the same call with its confirmToken after the person agrees.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare destructive mutation and non-idempotency, but the description adds crucial behavioral context: reply only returns a draft hint and sends nothing, handled marks read and keeps the message out of needs until new mail arrives, rules can affect all undecided messages, VIP rows are skipped, large rule archives/trashes trigger a preview with no moves, and changes return undoId values. These details materially help the agent predict side effects.

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 description is front-loaded with the core operation and return behavior, then layers in important caveats and edge cases. It is dense and somewhat run-on, but for a tool with this many distinct behaviors most sentences carry necessary operational detail.

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?

Despite having no output schema, the description explains the important return values: next batch, new batchId, undoId, ruleUndoIds, preview confirmToken, askedInApp, and decideUrl. Combined with the destructive annotation, it gives an agent enough context to invoke and interpret the tool safely.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

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

Schema coverage is 80%, but the description adds substantial meaning beyond the schema: it explains each action, clarifies snooze requires until, ties labelId usage to label, explains rule matching by sender/domain, describes confirmToken preview behavior, and states that ask:true asks the person in their app. This compensates well for any remaining schema gaps.

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: it applies decisions to the batch from inbox_zero_start, returns the next batch and a new batchId, and directs the agent to inbox_zero_stop when empty. This clearly distinguishes it from sibling batch tools and gives an agent enough to know exactly what operation it performs.

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 explicitly covers when to act autonomously versus suggest and wait, when to call inbox_zero_stop, how to handle the empty-batch condition, and how to respond to preview/confirmToken flows. It also names fallback behavior when the client cannot ask, including giving the person a decideUrl.

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