Skip to main content
Glama

Change a table in a document

edit_table
Destructive

Modify a document's table by row and column names: set cells, add or remove rows or columns, sort, rename, and assign column types without editing Markdown.

Instructions

Read or change one table of a document by what its rows and columns are called, never by its Markdown: set a cell, add or remove a row, sort, rename a column, give it a type, add or remove a column. A row is named by the words of its first cell and a column by its title, as show hands them back. A value is written the way its column's type reads it — 1234.5 for a number, 2026-10-28 for a date, true for a checkbox — and one that does not fit is kept as sent and named in the answer. What the document said before is kept, as with edit_doc.

Input Schema

NameRequiredDescriptionDefault
doNoWhat to do. Defaults to show, which changes nothing and hands back the columns with their types and the rows by their first cell
docYesThe document's id, as `docs` hands it back — an opaque name like `q7ntmzbm-0001`, not its title
rowNoFor set and remove: the row, by the words of its first cell or its number from 1
downNoFor sort: from the largest down. Defaults to from the smallest up
typeNoFor type and add_column: the column's type as written between braces in its head, such as `number`, `money USD sum`, `date`, `check` or `select`; `language` with the topic `tables` lists them. Empty takes the type away
tableNoWhich table, by its number from 1 or by the heading over it. Left out when the document holds only one
titleNoFor rename and add_column: the column's title
valueNoFor set: what goes in the cell. Empty clears it
columnNoFor set, sort, type, rename and remove_column: the column, by its title or its number from 1
valuesNoFor add: each column's title with what goes in it. Columns left out stay empty
keep_compactionNoOnly when the person told you in this conversation to keep a compaction of this document that waits for their word: it is kept, and this write goes ahead

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.39.1

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and non-idempotent, and the description adds context they don't cover: prior document state is preserved as with `edit_doc`, and values that don't parse against the column type are kept as sent and reported back in the answer. It does not restate safety hints, which is correct.

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-loaded with the verb and resource, then the operation list, then addressing, then value typing, then history behavior — each sentence adds a new fact. The prose is dense but idiomatic; no sentence is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter, mutation-capable tool with no output schema, the description covers addressing, value coercion, failure handling, history preservation, and deferral to `language` for type names. Only the response shape is left implicit (partially indicated by the 'named in the answer' remark).

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 100%, so the baseline is 3; the description goes beyond it by specifying how values must be formatted per column type (1234.5 for a number, 2026-10-28 for a date, true for a checkbox) and what happens when they don't fit — detail the schema does not carry.

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 — read or change one table of a document — and enumerates the exact operations (set a cell, add/remove row, sort, rename column, set a type, add/remove column). That maps cleanly onto the enum values and separates it from doc-level siblings like edit_doc and write_doc.

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?

Explains the addressing convention clearly (rows by the words of their first cell, columns by title, both interchangeable with numbers per the schema) and points to `show` as the way to obtain those names and to `language` with topic `tables` for the type vocabulary. It never explicitly says when to use edit_doc vs edit_table, so routing guidance is implied rather than stated.

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