Atwork

Update Items

item.update_many

Destructive

Update a LISTED set of rows (by id) in one sheet in ONE call — use it instead of repeated item.update_humanized whenever you change more than one row. Each row is { itemId, fields }; only the given fields change and values are HUMAN VALUES resolved as in item.update_humanized. Up to 200 rows per call. Rows that are not in the sheet, archived, read-only or have an unresolvable value are skipped with a reason and never changed; the rest are updated. Workflows on the sheet run for every updated row, as for an edit by hand. The whole call is one batch: item.undo_batch with the returned batchId and sheetId restores the previous values. Returns { batchId, updated, skipped, skippedCount, url } — tell the user the counts and the skip reasons.

Input Schema

Name	Required	Description	Default
`rows`	Yes	The rows to change, 1–200, each by id with only the fields that change
`sheetId`	Yes

Output Schema

Name	Required	Description
`url`	Yes	Panel link to the sheet
`batchId`	Yes	Id of the batch; pass it with sheetId to item.undo_batch to undo the whole batch. Null when nothing was written
`created`	Yes	Rows created
`sheetId`	Yes	Sheet the rows are in
`skipped`	Yes	Rows left unchanged and why; at most 20 are listed
`spaceId`	Yes	Space of that sheet; null for a sheet outside a space
`stopped`	No	Set when a row failed unexpectedly: rows after it were not attempted; the rest stay written
`updated`	Yes	Rows updated
`skippedCount`	Yes	All rows skipped, including ones not listed

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 6, 2026

changedOutput schema / properties / batchId / description

Previous value: -"Id of the batch; pass it to item.undo_batch to undo the whole batch. Null when nothing was written"New value: +"Id of the batch; pass it with sheetId to item.undo_batch to undo the whole batch. Null when nothing was written"

Changed4 schema fields changedNov 4, 2026

removedOutput schema / properties / batchId / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / batchId / type
```
Added value: +[
+  "string",
+  "null"
+]
```

removedOutput schema / properties / spaceId / anyOf

Removed value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / spaceId / type
```
Added value: +[
+  "number",
+  "null"
+]
```

Changed3 schema fields changedOct 27, 2026

addedOutput schema / properties / sheetId

Added value: +{
+  "description": "Sheet the rows are in",
+  "type": "number"
+}

addedOutput schema / properties / spaceId

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Space of that sheet; null for a sheet outside a space"
+}

changedOutput schema / required

Previous value: -[
-  "batchId",
-  "created",
-  "updated",
-  "skipped",
-  "skippedCount",
-  "url"
-]New value: +[
+  "batchId",
+  "created",
+  "updated",
+  "skipped",
+  "skippedCount",
+  "url",
+  "sheetId",
+  "spaceId"
+]

First observedOct 20, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the destructive/non-idempotent hints: partial-failure semantics (skipped rows with reasons, rest still updated), the 200-row cap, the side effect that sheet workflows run for every updated row, and the explicit recovery path via item.undo_batch with the returned batchId and sheetId. That is exactly the context an agent needs before a destructive bulk write.

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 what it does and the alternative, then limits, then failure semantics, then undo and return shape — a sensible narrative order with no filler sentences. The enumerated return object is somewhat redundant given an output schema exists, but it is a single clause and does not bloat the text.

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?

Covers scope, limits, partial-failure behavior, side effects, reversibility, and the post-call action (report counts and skip reasons). With an output schema present, no further return-value explanation is needed for an agent to call this correctly.

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 50%, and the description compensates well: it states the row shape `{ itemId, fields }`, that only supplied fields change, that values are human values resolved as in item.update_humanized, and that this holds up to 200 rows. It adds resolution behavior (select/status/member matching, unresolvable values skipped) that the schema cannot express, though sheetId semantics remain unstated.

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?

Names a precise verb+resource (update a listed set of rows by id in one sheet, in one call) and explicitly contrasts itself with repeated item.update_humanized. An agent can distinguish it from item.update_humanized and item.update_where without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit trigger ("whenever you change more than one row") and routes to the alternative bulk path by name. It does not address the other bulk sibling, item.update_where (filter-based selection), so the boundary on how rows are chosen is left to the agent to infer from the name.

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

All Atwork tools Inspect

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

Need Help?