Inbox Triage

Begin a mutating triage pass (acquire the per-inbox lease)

begin_triage

Acquires a lease so two agents never triage the same inbox at once.

Acquires a short-lived lease (TTL 8 min) before a pass that archives, labels, marks spam, or creates a batch of drafts, so two agents never step on the same inbox at once. Read/list/sync/get_message never need this. Call heartbeat_triage roughly every 2 minutes while the pass is running to keep the lease alive, and end_triage when done (or on error) so the lease frees up promptly instead of waiting out the TTL. Returns { ok:false, busy:true, heldBy, leaseExpiresAt } if another agent already holds the lease. Wait and retry later; do not force through it. Returns { ok:false, reason:'cadence', nextEligibleAt } if this inbox was already triaged within its cadence window (see get_triage_profile's effective.cadence) as a soft skip to avoid redundant passes. Pass force:true only for an explicit human override ("triage now anyway"), never automatically. May also return reminders (a string array, relay each line to the person before starting): a stale unsent draft (each reminded at most once, ever) or a snoozed message that came due in the last 7 days; never a snooze that is still pending.

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>",
      "agentLabel": "<agentLabel>"
    },
    "name": "begin_triage"
  }
}

Input Schema

Name	Required	Description
`force`	No	true to skip the cadence soft-check. Pass it only after the human explicitly asks to triage now.
`inboxId`	Yes
`agentLabel`	Yes	Short human-readable label identifying this agent/session, e.g. "claude-desktop" or "nightly-cron". Required.

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 only say it is a non-read-only, non-destructive, non-idempotent call; the description goes far beyond by disclosing the 8-minute TTL, the busy-lease failure payload, the cadence-window soft skip and its force override, and a reminders side channel with relay instructions and dedupe rules. This is exactly the behavioral context an agent needs before invoking.

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, then lease mechanics, then failure modes in a logical order. The opening sentence is immediately restated in expanded form ('Acquires a lease so two agents never triage the same inbox at once' followed by 'Acquires a short-lived lease (TTL 8 min)...'), which is the one wasteful redundancy in an otherwise dense, information-rich block.

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 carries the return contract (busy payload with heldBy/leaseExpiresAt, cadence payload with nextEligibleAt, reminders array) and the full lifecycle (acquire, heartbeat, end). An agent can execute the whole protocol from this text alone.

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%: force and agentLabel are already documented in the schema, and the description reinforces force with the 'only after the human explicitly asks' rule. inboxId carries no description in either place, but it is self-evident and constrained by the lease semantics. Additive but not a full compensation for the one undocumented parameter.

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 ('acquires a lease') plus the exact purpose: mutual exclusion for a mutating triage pass. It also distinguishes itself from the read-only siblings ('read/list/sync/get_message never need this') and from heartbeat_triage/end_triage, both of which are named.

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?

Explicit when-to-use (before a pass that archives, labels, marks spam, or creates a batch of drafts), when-not-to-use (read/list/sync/get_message), and which sibling to call next and how often ('heartbeat_triage roughly every 2 minutes', 'end_triage when done'). Even the override path is scoped: force:true only for an explicit human request, never automatically.

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?