Inbox Triage

Label messages

label_messages

Idempotent

Adds Gmail labels to the person's messages. Gmail inboxes only. Messages the person picked: pass each row's inboxId and messageId from show_inbox (the id block at the end of its text, or structuredContent.rows), usually by row number ("archive 2 and 5"). Or pass sender { inboxId, email } to act on that sender's mail still in the inbox, like "archive everything from 2" after review_unsubscribes (up to 50 newest per call). Needs labelIds from list_labels. Mail from a VIP is skipped when you act on several messages. Act on a VIP's message alone, and only after the person agrees: in apps that can prompt the person, they are asked directly; otherwise ask in chat and pass vipConfirmed:true. Reporting spam is not done here: it goes through propose_mark_spam then confirm_mark_spam, one message at a time. Work on your own only on a clear instruction or a saved agentRules rule; otherwise suggest and wait. The result has an undoId for undo_view_action, which works once, for 7 days; report counts and the undoId.

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

Input Schema

Name	Required	Description
`items`	No
`sender`	No	Instead of items: every message from this sender still in the inbox
`labelIds`	No	Gmail label ids from list_labels
`vipConfirmed`	No	true only after the person agreed in chat to act on this one VIP message

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 26, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond annotations, the description discloses key behavior: sender-based actions affect up to 50 newest messages still in the inbox, VIP messages are skipped when acting on several messages, and VIP actions require confirmation or vipConfirmed:true. It also explains that the result includes an undoId usable once for 7 days and that counts and undoId should be reported.

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 dense but front-loaded, starting with the core purpose and then layering usage, VIP, spam-routing, autonomy, and undo behavior. Most sentences carry necessary constraints, though the result is long and could be easier to scan with clearer breaks.

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?

For a mutation tool with no output schema, the description covers what an agent needs: accepted input sources, sender behavior, label source, VIP confirmation requirements, spam exclusion, autonomy limits, and the undoId result. Nothing critical for correct invocation appears missing.

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?

The description adds substantial meaning beyond the schema: items should come from show_inbox's id block or structuredContent.rows, often by row number, and sender targets all messages from that sender still in the inbox. It also clarifies that labelIds must come from list_labels and that vipConfirmed is only for a confirmed single VIP message.

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: adding Gmail labels to messages, limited to Gmail inboxes. It also distinguishes this from related tools such as propose_mark_spam and confirm_mark_spam, so an agent can tell what this tool does and does not handle.

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 gives explicit usage paths: pass rows from show_inbox or act on a sender after review_unsubscribes, with concrete examples like "archive 2 and 5" and "archive everything from 2". It also defines when not to use this tool for spam and when to act autonomously versus suggesting and waiting.

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?