Табуля

files_add_table

Destructive

Creates a structured data table from a 2D array of values in one call (named, with headers). Data tables are discouraged by default — only use this when the user explicitly requests a data table or the file already uses data tables; otherwise write plain cells with files_write (or files_write_batch) and style the header row. cell: the table's top-left anchor. table_name: the table's name. values: a 2D array of strings (first row is the column headers when first_row_is_header is true, the default). Don't place over existing data (check with files_has_data). For plain non-table cells use files_write; to turn existing cells into a table use files_convert_to_table. Requires edit permission. Signature: files_add_table(file_uuid, cell, table_name, values, sheet?, first_row_is_header?).

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>",
      "cell": "<cell>",
      "table_name": "<table_name>",
      "values": "<values>"
    },
    "name": "files_add_table"
  }
}

Input Schema

Name	Required	Description
`cell`	Yes	Top-left anchor in A1, e.g. 'A1'.
`sheet`	No	Sheet name (defaults to the first sheet).
`values`	Yes	2D array of values; first row = headers when first_row_is_header.
`file_uuid`	Yes
`table_name`	Yes	Name for the table.
`first_row_is_header`	No	Treat the first row as column headers (default true).

Output Schema

Name	Required	Description	Default
`cell`	Yes
`file_uuid`	Yes
`sequence_number`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 31, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already cover destructiveHint, idempotentHint, and openWorldHint, but the description adds two pieces of context the annotations cannot: it requires edit permission and warns not to place over existing data (check with files_has_data). It doesn't spell out overwrite consequences explicitly, but the destructive hint plus the has-data warning is sufficiently clear.

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?

The key constraint (tables discouraged; prefer plain cells) is front-loaded, and every sentence carries routing or safety value. The trailing signature line restating the params is somewhat redundant filler.

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 6-parameter mutation tool with an output schema and full annotations, the description covers routing, alternatives, permission prerequisite, and a placement safety check. Nothing an agent needs 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.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 83%, so the schema already documents every parameter. The description restates cell, table_name, values, and first_row_is_header largely in line with the schema and adds little syntax or edge-case guidance beyond confirming the default. Baseline 3 applies when schema does the heavy lifting.

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: creates a structured data table from a 2D array in one call. It explicitly distinguishes itself from siblings files_write, files_write_batch, and files_convert_to_table, so an agent can route correctly without opening other schemas.

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?

Gives an explicit when-not rule (data tables discouraged by default; use only when the user explicitly requests one or the file already uses tables), names the fallback (files_write / files_write_batch), and names the alternative for converting existing cells (files_convert_to_table).

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?