Табуля

files_write_batch

Destructive

Applies MULTIPLE value-writes AND/OR format-changes to a Tabulya file in ONE call: the file is loaded once and everything ships as a SINGLE atomic collaboration transaction — either all of it applies, or (on any error) none does. Far cheaper than N separate calls, and lets you write data and style it atomically (writes apply first, then formats). Provide 'writes' and/or 'formats' (at least one). Each write: { cell (A1 anchor), values[][] (2D literals), sheet? } (same rules as files_write: literals only; no writes over/adjacent to data tables, except writes within the data rows of a server table: those go to the tables service, each write within one table; copies of a table sorted or filtered differently go in separate calls). Each format: { range (A1), sheet?, and any of bold/italic/underline/strikethrough/text_color/fill_color/align/wrap/number_format/custom_format/decimals/currency_symbol } (same as files_format). A top-level 'sheet' is the default for entries that omit one. Requires edit permission. Signature: files_write_batch(file_uuid, writes?[], formats?[], sheet?).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "file_uuid": "<file_uuid>"
    },
    "name": "files_write_batch"
  }
}

Input Schema

Name	Required	Description
`sheet`	No	Default sheet for entries that omit one (defaults to the first sheet).
`writes`	No	Value-writes applied first, in order, as part of the atomic transaction (max 200).
`formats`	No	Format-changes applied after the writes, in order, in the same transaction (max 200).
`file_uuid`	Yes

Output Schema

Name	Required	Description	Default
`file_uuid`	Yes
`writes_applied`	Yes
`formats_applied`	Yes
`sequence_number`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 31, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the destructive/non-idempotent annotations, the description discloses the atomic all-or-nothing transaction semantics, the internal ordering of writes before formats, the edit-permission requirement, and non-obvious constraints (no writes over/adjacent to data tables, server-table writes routed to the tables service, sorted/filtered table copies in separate calls). This is substantive behavioral context an agent cannot infer from annotations.

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 atomic single-call value proposition and the writes/first-then-formats ordering before the structured detail. The long parenthetical on table rules is dense but each clause carries operative constraint information, so it earns its space despite being heavy.

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?

With annotations covering the safety profile and an output schema handling returns, the description supplies everything else an agent needs: atomicity guarantees, ordering, permission requirements, per-entry shape, default sheet resolution, and table-adjacency restrictions. Nothing material is missing 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 coverage is 75%, and the description adds real meaning: it documents the nested shape of each write (cell anchor, 2D literals, optional sheet) and format entry, and clarifies that the top-level 'sheet' is a fallback default for entries that omit one. It largely mirrors rather than extends the schema's field list, so it edges above baseline but not to a 5.

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 ('Applies MULTIPLE value-writes AND/OR format-changes to a Tabulya file in ONE call') and explicitly positions itself against the sibling primitives by referencing 'same rules as files_write' and 'same as files_format'. An agent can distinguish batch from single-call variants without opening a 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 clear selection logic: 'Far cheaper than N separate calls', 'Provide writes and/or formats (at least one)', and 'writes apply first, then formats'. It does not explicitly say when to prefer files_write or files_format for single operations, so it stops short of full when-not guidance.

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

All Табуля 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?