Skip to main content
Glama
aaronsb

Google Workspace MCP Server

by aaronsb

queue_operations

Run Google Workspace operations in one call: chain operations sequentially with $N references, or batch one operation across many resources.

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

TableJSON 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
Install Server

TDQS

A4.1/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the two execution modes, the default mode, result chaining with $N.field, and the deprecation status. However, it does not mention potential side effects, permissions required, or what the operation result/return shape looks like, which are relevant for a tool that can execute arbitrary operations.

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?

The description is compact and front-loaded with the most important information: the rename and deprecation. Each sentence earns its place by explaining mode selection, sequencing, chaining, and batch limitations without repetition or fluff.

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 complex tool with seven parameters, two modes, and no output schema, the description covers the core decision points: mode choice, chaining mechanics, batch constraints, and deprecation. The parameter schema fills the remaining details. It is slightly incomplete only because it does not discuss output/return behavior or authorization/side-effect considerations, but overall it is sufficient for correct invocation.

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. The text adds meaningful context beyond the schema by explaining that 'queue' works for every tool, that 'batch' is beneficial due to fewer round trips but only where batch methods exist, and that $N.field references chain results. This goes beyond the enum descriptions in the schema.

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?

The description clearly states that the tool does many things in one call and explains the two modes ('queue' and 'batch'). It also identifies this as a deprecated alias of 'bulk_operations', which gives the agent a concrete point of reference, though it does not distinguish itself from that sibling because it is the same tool.

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?

The description explicitly says when to use each mode: 'queue' for sequential operations with chaining, 'batch' for one operation across many resources with fewer round trips. It also warns that batch is only available where Google publishes a batch method, and it tells the agent the preferred alternative name is 'bulk_operations' since this name will be removed.

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

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/aaronsb/google-workspace-mcp'

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