Everything else follows from that decision. Reads exist to mint hashes, which is why search_tables and list_tables return one alongside every hit rather than making you call read_table again, and why a successful write returns v:{new_hash} so consecutive edits chain without a re-read. The descriptions argue against grep for the same reason — a regex over raw text does not know a column from a cell, and an HTML table in a GitBook file does not look like a table to it. The narrow claim here is worth taking literally: this handles tables inside Markdown, addressed by index within one file, and stops there.
A table-editing server for Markdown files, exposing 11 tools that address tables by index within a file and guard every write with the version hash a read returned.
- Reads that hand back the handle a write needs: read_table returns one table as a clean pipe table whose first line carries v:{hash} with the format, row and column counts and section; list_tables enumerates a file's tables with column names, row counts, formats and version hashes; search_tables matches rows by case-insensitive substring or by regular expression, optionally inside one column or one table, and returns each hit with its table index, row index and version hash.
- Writes that refuse a stale read: update_cells, insert_row, delete_row, replace_table, insert_column, delete_column and rename_column all take the version hash, return only v:{new_hash} on success, and return a JSON error such as STALE_READ or EDIT_ERROR when the table moved underneath the read.
- Column addressing that survives reordering: a column can be given as a letter, as its header name, or as the composite of both, in update_cells and insert_row alike; insert_column fills existing rows with a default_value and rename_column changes a header while leaving row data untouched.
- Row indexing that ignores the header: update_cells takes a 0-based data row index with the header row not counted, and cell values accept inline Markdown formatting.
- Original file format preserved on write-back: replace_table writes a pipe table back as a pipe table and GitBook HTML back as GitBook HTML with its attributes intact, while create_table chooses between collapsed single-line HTML for GitBook and a GFM pipe table, and needs no version hash because nothing is being edited yet.
A Markdown file the server can write to, and a read before every edit — each write tool takes the version hash that read_table, list_tables or search_tables returned.
One command — uvx tablestakes