Skip to main content
Glama

bulk_modify

DestructiveIdempotent

Apply label changes to many emails at once using a Gmail search query, processing up to 1,000 messages per request. Add or remove labels in bulk, with a dry-run option to preview matched messages and counts before any change is made.

Instructions

Bulk-apply label changes to every message matching a Gmail query, batched at 1000 messages per API request. Labels may be given by name or by id: an unknown name in add is created automatically (use '/' for nested labels), an unknown name in remove is ignored. Returns matched/modified counts, matched and modified thread IDs (both lists capped at 500 — matchedThreadCount/modifiedThreadCount hold the true totals), and per-chunk failures (partial success is reported, not hidden). If more messages match than maxMessages, only the first maxMessages are processed and 'capped' is true — raise maxMessages or re-run to finish the rest. NOTE: the query hits Gmail's search index as-is, WITHOUT the live re-verification search performs. The staleness that makes search re-verify was measured on threads.list (132 threads returned, 114 carrying no unread message at all); the same query through the message index this tool uses returned 19 hits, none stale — same mailbox, same minute. So the known drift does not reach this path, but that is one measurement, not a guarantee: unverifiedPredicates in the result names the conditions taken on the index's word, and when the outcome must be read-state-precise, resolve the set with search (which verifies against live labels) and act on those thread ids instead. Set dryRun:true to rehearse: the same query resolution, matched counts/threads and the labels that would be created — and no message or label is touched. A dry run reads the SAME unverified index, so it confirms the size of the set, never its correctness. USE WHEN: mass operations — 'archive all newsletters older than 30 days' (query + remove INBOX), bulk labeling, bulk mark-read; dryRun first when the query is broad or the user should see the set before it changes. DO NOT USE: for a single thread (use modify_labels or the dedicated tools), or with neither add nor remove. SIDE EFFECTS: modifies up to maxMessages messages in one call (none with dryRun); label changes are reversible by the inverse call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
addNo
queryYes
dryRunNo
removeNo
maxMessagesNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
cappedYes
dryRunYes
failedYes
labelsToCreateNo
matchedThreadsYes
matchedMessagesYes
modifiedThreadsYes
modifiedMessagesYes
matchedThreadCountYes
modifiedThreadCountYes
unverifiedPredicatesYes
Behavior5/5

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

Annotations already flag destructiveHint=true and readOnlyHint=false, but the description adds substantial behavioral context: label auto-creation with '/' nesting, unknown removes being ignored, result lists capped at 500 with true totals via counts, per-chunk partial failure reporting, and the 'capped' flag for maxMessages. It also candidly discloses the unverified search index caveat with a measurement. No contradiction with annotations; the description deepens the agent's understanding of edge cases.

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 long but highly structured with clear USE WHEN/DO NOT USE/SIDE EFFECTS sections and a front-loaded synopsis. The detailed index-staleness measurement (132 threads, 114 stale, 19 hits) is relevant but somewhat verbose for an agent-facing description; trimming that aside, every other sentence earns its place.

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 complex mutating tool with 5 parameters and a rich output schema, the description covers use cases, exclusions, side effects, reversibility, partial success reporting, result limits, dryRun behavior, and the index freshness caveat. It even addresses the 'capped' condition and offers a fallback path (resolve with search) for read-state-precise outcomes. Nothing critical is 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?

Schema description coverage is 0%, so the description fully compensates. It explains that add/remove accept names or ids, that unknown names in add are created and unknown names in remove are ignored, that maxMessages limits processing with a 'capped' flag, and that dryRun rehearses without touching messages or labels. This is far richer than the bare schema types and defaults.

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 opens with a specific verb and resource: 'Bulk-apply label changes to every message matching a Gmail query, batched at 1000 messages per API request.' It clearly distinguishes from siblings by explicitly stating 'DO NOT USE: for a single thread (use modify_labels or the dedicated tools).' The purpose is unambiguous and differentiates the tool from the surrounding list.

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?

A dedicated 'USE WHEN' section provides concrete scenarios ('archive all newsletters older than 30 days') and a 'DO NOT USE' section names alternatives. It also advises 'dryRun first when the query is broad or the user should see the set before it changes,' giving actionable selection guidance beyond the basic alternative naming.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/csitte/mailwarden'

If you have feedback or need assistance with the MCP directory API, please join our Discord server