Skip to main content
Glama

Dock

by ai.trydock

bulk_update_rows

Update many existing rows in ONE call — the bulk version of update_row. Use this instead of looping update_row when changing more than a few rows (much lower latency + token cost for sheet edits). Pass updates as an array of { id, data }: id is the row id (from get_rows / query_rows), data is a column-name → value map of just the cells to change. Each row's data is MERGED into the existing row (last-write-wins per field), so you only send the cells you're changing. Up to 500 rows per call. ALL-OR-NOTHING: if any id is missing or in another workspace the whole batch is rejected and nothing is written, so on error you can safely resend the entire batch. Values are coerced to each column's type. Returns { updated, rows }.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
slugYesThe workspace slug (bare or org-prefixed).
updatesYesRows to update. Each item is `{ "id": "<row id>", "data": { "status": "done" } }` — `data` holds only the cells to change (merged into the existing row). 1-500 items.

TDQS

A5/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden, and it delivers: it discloses merge semantics per field, last-write-wins behavior, the 500-row cap, all-or-nothing atomicity, invalid-id rejection, safe resend on error, and type coercion. It also states the return shape, which is not available in an output schema.

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 dense but every sentence earns its place: core purpose, comparison to update_row, parameter shape, merge semantics, batch limit, failure behavior, type coercion, and return value. The most decision-relevant facts about bulk behavior are front-loaded.

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 mutation tool with no annotations and no output schema, this description is complete: it specifies when to use it, how to construct parameters, what the atomicity guarantees are, what causes rejection, how to retry, and what the response contains. Nothing an agent needs to invoke it correctly 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?

Despite 100% schema coverage, the description adds significant value beyond the raw schema: it explains that `id` comes from get_rows/query_rows, that `data` is a column-name-to-value map of only changed cells, that updates are merged rather than replaced, and that the array allows 1-500 items. This is exactly the practical parameter semantics an agent needs.

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 'Update many existing rows in ONE call' and explicitly labels itself 'the bulk version of update_row,' giving a specific verb, resource, and scope. It is immediately distinguishable from siblings like update_row and bulk_create_rows.

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 to use this 'instead of looping update_row when changing more than a few rows' and cites lower latency and token cost. It also covers when a call is rejected and how to safely retry, so the agent receives clear decision and error-recovery guidance.

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

All Dock toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.8/5.0
Disambiguation4/5

Most tools have clearly distinct purposes, with detailed descriptions that prevent confusion. The main ambiguity arises from send_message vs. the referenced but missing message_teammate tool, and add_column vs. update_surface for schema changes, but these are mostly clarified by the descriptions.

Naming Consistency4/5

The naming convention is predominantly verb_noun with underscores (e.g., create_workspace, list_rows, update_doc). Exceptions like 'search' and 'address_book' (no noun) and the two-word 'react_to_comment' are minor deviations in an otherwise consistent pattern.

Tool Count1/5

With 68 tools, the surface is far too large for an MCP server, exceeding the 50+ threshold for extreme mismatch. This volume creates excessive selection overhead for agents and suggests the tool set could be consolidated or split into focused servers.

Completeness3/5

The server covers broad functionality across workspaces, docs, tables, HTML, comments, files, webhooks, and billing. However, notable gaps exist: the explicitly referenced message_teammate tool is missing (preventing agent-to-agent waking), and there is no create/upload file tool or create API key tool, which creates dead ends in workflows.

Resources