Skip to main content
Glama
iTvX

Google Workspace MCP — Gmail edition

by iTvX

queue_operations

Run multiple Google Workspace operations in one call: sequentially with result chaining, or batch one operation across many resources in a single API request.

Instructions

RENAMED to bulk_operations, which does the same thing. This name still works and will be removed in a future release. Do many things in one call, two ways. mode:'queue' (default) runs different operations in sequence, chaining results with $N.field — works for every tool. mode:'batch' does ONE operation across many resources in a single Google request — far fewer round trips, but only where Google publishes a batch method.

Input Schema

NameRequiredDescriptionDefault
modeNoqueue (default): N operations, N API calls, in order, with $N.field references between them. batch: ONE operation across many resources in a single API call — no $N references, because there is no 'between'.
toolNobatch only — the tool to call, e.g. 'manage_contacts'.
emailNobatch only — the account to act as.
itemsNobatch only — one entry per resource. A bare id string is enough when that is all that differs, e.g. ['people/c1', 'people/c2']; use objects when items carry more, e.g. [{name: 'Ada Lovelace', contactEmail: 'ada@example.com'}]. Anything shared by the WHOLE batch — labels to add, a field mask — goes at the top level of this call, not in here.
detailNosummary: one-line status per operation (default) | full: include complete output from each operation
operationNobatch only — the operation to apply to every item, e.g. 'delete'. Ask for one that cannot batch and the error names the ones that can.
operationsNoOperations to execute sequentially

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv4.8.0

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does disclose real behavioral traits: batch mode's hard constraint ('only where Google publishes a batch method'), queue mode's universal applicability ('works for every tool'), and failure behavior ('the error names the ones that can'). It is silent on auth requirements and partial-failure semantics beyond what onError already documents in the schema.

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-loads the deprecation/rename fact, which is the most decision-relevant information, then the purpose and mode distinctions. Three tight sentences with little waste; a minor overlap with schema text on mode semantics keeps it from a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter, no-annotation, no-output-schema tool, the description covers the routing decision, both execution modes, chaining semantics, and batch eligibility. Missing only auth/permission expectations and explicit return-shape guidance, though the detail enum in the schema covers output verbosity.

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 description coverage is 100%, so the baseline is 3, but the description adds framing the schema does not: the queue-vs-batch tradeoff (round trips vs chaining), the meaning of $N.field references, and that batch mode permits no $N references 'because there is no between'. That is genuine added meaning on top of already-complete parameter docs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific capability ('Do many things in one call, two ways') and immediately identifies itself as a deprecated alias for bulk_operations, which lets an agent distinguish it from all other siblings. The purpose is slightly muddled by leading with the rename notice, but the underlying function (sequenced vs batched multi-operation execution) is unambiguous.

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?

Names the alternative (bulk_operations) and the condition that selects it (this name still works but will be removed), then gives explicit when-to-use guidance for each mode: 'queue' for different operations in sequence with $N chaining, 'batch' for ONE operation across many resources where Google publishes a batch method. When-not conditions are stated for batch mode.

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