Inbox Triage

Confirm and report the message as spam

confirm_mark_spam

Destructive

Reports the pending message as spam, after the person approves in the app prompt or on the approval page.

Moves the pending report's message to the provider's Spam/Junk mailbox (iCloud/IMAP: the mailbox flagged \Junk, or named "Junk"; Gmail: adds the SPAM label and removes INBOX; Microsoft: moves to the junkemail folder), after the person approves it. Requires pendingSpamId + approvalCode from propose_mark_spam. Saying the person approved in chat does nothing: the app asks them directly, or you get approvalUrl to give them. One-shot: the pending report is consumed the moment it is carried out (successfully or not), so it can never be retried/replayed under the same id. Call propose_mark_spam again if it fails and the human wants to retry. Not a permanent delete, and the message drops out of list_messages/get_message here immediately because Spam/Junk is never synced back in. Returns an undoId: the person can undo the move from Activity for 7 days, or you can call undo_view_action with it: undo puts the message back, teaches the filter it is not spam, and takes the sender off the blocklist if this report put it there. In apps that can prompt the person directly (propose_mark_spam returned confirmInApp:true), the person is asked in the app and answers there; nothing happens unless they say yes. Approval is the app prompt or the approval page (approvalUrl); the result says which (approvalPath). Chat approval does not count.

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": {
      "pendingSpamId": "<pendingSpamId>",
      "approvalCode": "<approvalCode>"
    },
    "name": "confirm_mark_spam"
  }
}

Input Schema

Name	Required	Description
`approvalCode`	Yes	approvalCode returned by propose_mark_spam for this pending report
`pendingSpamId`	Yes	pendingSpamId returned by propose_mark_spam
`humanApprovedInChat`	No	Ignored. Approval happens in the in-app prompt or on the approval page.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 26, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Goes well beyond the destructiveHint/idempotentHint annotations: per-provider mailbox outcomes (\Junk, Gmail SPAM label + INBOX removal, Microsoft junkemail folder), the one-shot consumption of the pending report even on failure, and the fact that the message disappears from list_messages/get_message because Spam/Junk is never synced back. The undo semantics (undoId, 7-day window, filter retraining, blocklist removal) round it out. Slightly overlong rather than incomplete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core action and the approval requirement are front-loaded, but the prose is bloated by repetition: the point that in-chat approval does not count is made three separate times ("Saying the person approved in chat does nothing", "Chat approval does not count", and implicitly again in the parenthetical), and the mailbox routing list is dense. It could lose roughly a third of its length without losing information.

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 destructive, non-idempotent, one-shot mutation with no output schema, the description covers everything an agent needs: who approves, how approval arrives, what happens to the message on each provider, that retries require a fresh proposal, and how to reverse it. The undoId return value is explained despite no output schema existing.

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

Parameters3/5

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

Schema description coverage is 100%, so all three parameters are already documented, including that humanApprovedInChat is ignored. The description restates the provenance of pendingSpamId/approvalCode and reinforces the chat-approval rule, but adds no new parameter-level detail such as format or expiry.

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 ("Reports the pending message as spam") and immediately scopes it to the post-approval execution step, distinguishing it from the sibling propose_mark_spam that merely stages the request. An agent can tell the propose/confirm pair apart without opening either schema.

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 prerequisites (pendingSpamId + approvalCode from propose_mark_spam), an explicit failure path ("Call propose_mark_spam again if it fails and the human wants to retry"), and an explicit non-path (chat approval does not count). It also names undo_view_action as the reversal route with the alternative 7-day Activity undo.

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?