Skip to main content
Glama
Sign In

DataToRAG

by com.datatorag
OverviewDiscussionsAdmin

gws-mcp__gmail_label_message

Destructive

Label many messages in ONE call: pass message_ids (up to 1000) with add_labels and/or remove_labels, and every message is modified by a single users.messages.batchModify request. Do not call this once per message. The label-and-mark-read pair is one call: add_labels: [""], remove_labels: ["UNREAD"]. Removing INBOX archives; removing UNREAD marks read. Label IDs come from gmail_list_labels. Returns a per-message outcome (results[]: id, ok, error) so a partial batch is visible; if the batch request is refused, each id is retried on its own and reported. message_id is for a single message only; thread_id labels every message of one conversation.

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": "gws-mcp__gmail_label_message"
  }
}

Input Schema

NameRequiredDescriptionDefault
accountNoOptional email address of the connected account to use (e.g. 'user@gmail.com'). If omitted, the default account is used.
thread_idNoA thread ID, to label or unlabel every message in that conversation in one call, as Gmail does when a conversation is selected. Provide this instead of message_id or message_ids.
add_labelsNoLabel IDs to add, e.g. ["Label_12"]
message_idNoA single message ID, for the one-message case only. Provide either this or message_ids.
message_idsNoThe message IDs to modify together in one call, up to 1000. Prefer this over message_id whenever there is more than one message.
remove_labelsNoLabel IDs to remove, e.g. ["INBOX"] to archive or ["UNREAD"] to mark read; combine with add_labels to label and mark read in the same call

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=false and destructiveHint=true, and the description goes well beyond that: removing INBOX archives, removing UNREAD marks read, the batch-then-per-id retry fallback if the batch request is refused, and the per-message results[] with ok/error so partial failures are visible. That is exactly the behavioral context an agent needs before running a destructive bulk mutation.

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 the headline batch capability, then the anti-pattern warning, then the label-ID cheat sheet, then the return behavior — a sensible order with no filler sentences. It runs long and repeats a couple of schema details (up to 1000, message_id scope), which costs a point.

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 bulk mutation with no output schema, the description still explains the return shape (results[] with id, ok, error), the failure/retry path, and how to obtain valid label IDs. Nothing material is left for the agent to guess.

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 100%, so the baseline would be 3, but the description adds real semantics: which special label IDs produce which side effects (INBOX/UNREAD), how add_labels and remove_labels combine in one call, and that thread_id labels every message of a conversation. Some content (the 1000 cap, message_id being single-only) merely restates the schema, which keeps this from a 5.

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?

Opens with a specific verb, resource and scale: "Label many messages in ONE call" with message_ids up to 1000 and add_labels/remove_labels, executed as a single users.messages.batchModify. It also distinguishes itself from the one-message case and from thread-level labeling, so an agent can tell it apart from siblings like gmail_mark_read or gmail_trash.

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?

Explicitly says "Do not call this once per message," names the alternative (message_id for a single message), and states the workflow prerequisite that label IDs come from gmail_list_labels. The thread_id sentence tells the agent exactly which selector to use for a conversation instead of per-message IDs.

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

All DataToRAG 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