LogiSheets MCP server

logisheets-mcp

A real spreadsheet engine your agent can think in. Excel-compatible formulas it doesn't have to do in its head, a table it addresses by name instead of by coordinate, and a genuine .xlsx at the end that a person can open, audit and keep using.

An MCP server over LogiSheets, a spreadsheet engine written in Rust. MIT, runs on your machine, opens no sockets.

The trouble with a grid

Ask a model for a five-year projection and it writes twenty formulas, each with the row number adjusted by hand. That is where the silent mistake lives: one of them reads B7 where it meant B8, the total looks plausible, and nothing raises an error.

Then the sheet moves. Someone inserts a row at the top, deletes a year, adds a column. Every coordinate the model was holding is now off by one and it has no way to notice, so it spends the next turns re-reading cells to work out where things went instead of on the question you asked.

And every "what if" costs a round trip — write the input, recalculate, read the output, put it back. Sixteen scenarios is sixteen of those, and a scan that dies half way leaves a scenario behind in your model.

Blocks

A block is a named table on the sheet. Rows have keys, columns have names, and everything is addressed by those rather than by position.

a row and it computes. There is no twentieth formula to get wrong.

• A field's formula is stated once, for the whole column — not per cell. Add

Insert a row above it and the reference still says the same thing, because it never said "row 8".

• A reference names what it means: the pv field of the row keyed Y3.

a number the model worked out itself.

• The engine owns computed values. A formula field cannot be overwritten with

create_block     proj    fields: year, fcf, df, pv
set_field_rule   proj.pv = fcf × df          ← once, for the column
add_block_rows   Y1 … Y5
describe_block   proj
  →  Y1 147.2727   Y2 144.5950   Y3 141.9660   Y4 139.3848   Y5 136.8506

… the sheet is then reshaped: two rows inserted at the top, a column at the left …

describe_block   proj
  →  Y3 141.9660               ← same answer, same address, nothing re-derived

Blocks are created by the agent as it works, so nothing needs preparing. Point it at a blank workbook or at a spreadsheet someone emailed you — converttoblock adopts a table that is already in ordinary cells, reading the field names off the header row and working out which column is the key.

The second session

The conversation that builds a spreadsheet is almost never the conversation that has to answer a question about it. A week later there is a new session, with none of the context, holding only the file — and what the file records is what that session can know.

A grid records coordinates. =B11$B$3(1-$B$4) is correct and means nothing until the agent fetches the label column and infers that A3 describes B3. The schema is where the meaning goes instead, and it is written into the .xlsx: field names, the key column, which fields the engine computes, and the rule behind each one. One listblocks call and the workbook introduces itself; one describeblock and the rules come back as #FIELD("revenue")*BLOCKREF("assum","margin","v") — an explanation rather than a second lookup problem.

Shortened. The full README is on GitHub.