Skip to main content
Glama

batch

Run up to 200 ordered board operations in one request as a single undo step, with results reusable by later calls and optional all-or-nothing rollback.

Instructions

Runs several tool calls in ONE request (1 to 200 operations, in order), on one board, as a single undo step in the application. Use it to build or rework a board quickly instead of one call per object. Each operation is {"tool": "add_shape", "args": {...}} with the arguments the tool normally takes (but never path, output or source: the batch-level path applies to all). An operation can reuse what an earlier one returned: a string that is EXACTLY "$N.key" (N = index from 0 of an earlier operation, then keys or list indexes separated by dots, e.g. "$0.id" or "$3.ids.1") is replaced by that value of the result of operation N before the operation runs; text that only contains "$0.id" inside a longer string stays literal, and a text that is exactly like "$3.99" would be taken for a reference. An operation without page acts on the batch-level page (default: the first page), whatever the previous operations did. atomic (default true): at the first error everything already done is undone, the board is unchanged, and the error gives the operation index, its error and the results obtained before the rollback. With atomic: false the batch stops at the first error and keeps what succeeded, answering {applied, failed: {index, error}, results} (not an error). Success answers {results: [one result per operation], applied}. Not allowed inside a batch: batch, create_board, save_board, board_changes, export, render.

Input Schema

NameRequiredDescriptionDefault
pageNoPage: number (from 1) or name. Defaults to the first.
pathNoPath of the board file (.inkboard; .inkboard.json and .tableau.json also accepted). Optional when the application is open: the tool then acts live on the displayed board (undoable with Ctrl+Z).
atomicNoAll or nothing (default true). false: keep the operations done before the first error.
operationsYesOperations to run in order, e.g. [{"tool": "add_shape", "args": {"geom": "rect", "text": "A"}}, {"tool": "add_shape", "args": {"geom": "rect", "text": "B"}}, {"tool": "add_connector", "args": {"from": "$0.id", "to": "$1.id"}}].

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.7/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 burden and does: it discloses the single-undo semantics, atomic defaults and rollback behavior, both failure response shapes ({applied, failed, results} vs. an error with operation index), and the page-inheritance rule. It also specifies the reference-substitution rules precisely, including the edge cases (exact "$N.key" only, literal text stays literal, "$3.99" being misread as a reference).

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?

Purpose is front-loaded in the first clause and every sentence carries operational information. It is a dense single paragraph, though, and the substitution rules could be broken out for faster scanning; density borders on overwhelming.

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 orchestration tool with no annotations and no output schema, the description covers invocation shape, ordering, reference resolution, page inheritance, failure modes, rollback, and return values. Nothing an agent needs in order to call 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?

Schema coverage is already 100%, but the description still adds real meaning: args are the same arguments the tool normally takes except path/output/source (batch-level path applies to all), and it explains the $N.key substitution grammar with concrete examples. The page-defaulting rule is also clarified beyond the schema's "Defaults to the first."

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?

States a specific verb and resource — runs 1 to 200 tool calls in one request on one board as a single undo step — which no sibling tool does. It also names the scope (one board, ordered operations) that separates it from calling add_shape/add_connector individually.

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?

"Use it to build or rework a board quickly instead of one call per object" gives clear when-to-use guidance, and the closing sentence lists the tools that may not appear inside a batch (batch, create_board, save_board, board_changes, export, render). It stops short of an explicit when-not-to-use condition such as preferring direct calls for a single operation.

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