Skip to main content
Glama

gws-mcp__gmail_trash

Destructive

Moves one Gmail message to Trash. Takes the message ID. The message leaves the inbox and every other label view and stays in Trash, where Gmail deletes it for good after 30 days; gmail_untrash restores it before then. Returns the message ID and the labels the message carries afterwards. Acts on the one message named, not on the rest of its thread.

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": {
      "message_id": "<message_id>"
    },
    "name": "gws-mcp__gmail_trash"
  }
}

Input Schema

NameRequiredDescriptionDefault
accountNoOptional email address of the connected account to use (e.g. 'user@gmail.com'). If omitted, the default account is used.
message_idYesThe ID of the message to move to Trash, as gmail_search, gmail_list and gmail_read return it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only declare destructiveHint=true and readOnlyHint=false; the description adds the consequential detail an agent actually needs: the message leaves all label views, sits in Trash, and is permanently deleted by Gmail after 30 days unless untrashed. It also states the return payload (message ID plus resulting labels), which annotations never provide.

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

Conciseness5/5

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

Four short sentences, front-loaded with the action and scope, then consequences, then return value. Each sentence contributes distinct information (scope, retention, reversal, return, thread boundary) with no filler.

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 simple single-parameter mutation with no output schema, the description covers what it does, what is affected, reversibility, retention window, and what comes back. Nothing needed to invoke it correctly or to understand the risk is missing.

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 coverage is 100%, so both parameters are already documented, including that message_id comes from gmail_search/gmail_list/gmail_read. The description's "Takes the message ID" adds essentially nothing beyond the schema, so the baseline of 3 applies.

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 ("Moves one Gmail message to Trash") and immediately bounds scope with "Acts on the one message named, not on the rest of its thread," which cleanly separates it from the sibling gmail_trash_thread. An agent can pick the right one 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Names the reversal path explicitly ("gmail_untrash restores it before then") and rules out thread-wide behaviour, giving clear selection context. It stops short of covering the adjacent alternatives, e.g. when to trash versus archive by removing labels or mark as spam, so it is not a full when/when-not map.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.