** Настоящий движок электронной таблицы, в котором ваш агент может мыслить.** Совместимые с Excel формулы Это не обязательно делать в голове, таблица, к которой он обращается по имени, а не по имени. Координация и подлинное .xlsx в конце, которое человек может открыть, проверить и проверить. Продолжай использовать.

MCP сервер над LogiSheets, двигатель электронной таблицы в ржавчине. MIT, работает на вашей машине, не открывает розетки.

Проблемы с сеткой

Попросите модель для пятилетней проекции, и она напишет двадцать формул. Номер строки корректируется вручную. Вот где живет молчаливая ошибка: одна из Они читают [[Т1]], где это означало [[Т2]], в целом выглядит правдоподобно, и ничего. Вызывает ошибку.

Затем лист перемещается. Кто-то вставляет строку вверху, удаляет год, добавляет колонна. Каждая координата, которую держала модель, теперь выключена одной, и у нее нет способ замечать, поэтому он тратит следующие обороты перечитывая ячейки, чтобы выяснить, где Вместо того, чтобы отвечать на вопрос, который вы задали.

И каждое «что, если» стоит круглой поездки — напишите ввод, пересчитайте, прочитайте выход, положи обратно. Шестнадцать сценариев — шестнадцать из них, и сканирование, которое умирает. Полпути оставляют сценарий позади в вашей модели.

Блоки

block — таблица с именами на листе.

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 field’s formula is stated once, for the whole column — not per cell. Add a row and it computes. There is no twentieth formula to get wrong.
• A reference names what it means: the pv field of the row keyed Y3. Insert a row above it and the reference still says the same thing, because it never said “row 8”.
• The engine owns computed values. A formula field cannot be overwritten with a number the model worked out itself.

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 — convert_to_block 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