andon MCP server

andon

<!-- mcp-name: io.github.gulmezeren2-byte/andon -->

Stop the line when the numbers don't add up.

andon re-checks the numbers in finished analysis — the report your AI agent just drafted, the workbook a colleague "quickly updated" — against the data they came from and against themselves. It does this with arithmetic, not with another LLM: reconciliation, internal consistency, schema contracts and Excel workbook integrity, written down as a small YAML spec and enforced with exit codes.

That screenshot is real output. The example it runs on is in examples/quarterly-report/, staged by a script that plants the defects I keep meeting in real reporting work: a count taken from a stale snapshot, a revenue total typed over by hand, shares that sum to 101.2, a total row nobody updated after a data refresh, a #REF!, and freight numbers stored as text.

Why this exists

I'm an industrial engineer. I build and run operations reporting — delivery KPIs, forecast accuracy, inventory analytics — and over the last two years an increasing share of the first drafts around me has been written by AI agents. They are fast, tireless, and confidently wrong in ways a tired human is not: the filter that silently dropped cancelled orders, the percentage column that almost sums to 100, the total row that survived three edits of its parts.

The common answer is to ask a second model to review the first one. I think that is the wrong tool. Whether 539 rows really sum to 257,060.48 is not a matter of opinion, and no amount of model capability makes an opinion the right instrument for it.

Manufacturing solved this problem decades ago. On a Toyota line, any worker who spots a defect pulls a cord — the andon — and the line stops until the problem is understood. The machine equivalent, jidoka, is a machine that stops itself when it detects an abnormal condition. This tool is that cord for spreadsheets and reports: a small, deterministic gate between "the analysis is written" and "the analysis is sent."

The iron rules

andon's behavior is easier to trust because it is constrained. These rules are enforced in code, not just promised here:

plausibility bounds) can raise a REVIEW flag; the engine will not let them FAIL, even if a buggy check tries.

1. Only arithmetic can fail the build. Heuristic checks (distribution shifts,

which worksheets were never touched (the report calls this the honesty block). A PASS covers the listed assertions and nothing else.

1. No silent blessings. Every report ends with what was read, what was skipped, and

text in a numeric column — the run continues, the check is recorded as ERROR, and the exit code is non-zero. "Not verified" must never be readable as "fine."

1. A check that can't run is a finding, not a pass. Missing file, unreadable range,

1. Read-only by construction. There is no code path that writes to your data.

Install

pip install andon-verify

The PyPI distribution is named andon-verify (the bare andon name was already taken); the command and the import stay andon — andon run ..., import andon. From source: pip install git+https://github.com/gulmezeren2-byte/andon.

Quick start

Point andon at data and claims:

# andon.yaml
version: 1

sources:
  orders: data/orders.csv
  report: out/weekly.xlsx#Summary

Shortened. The full README is on GitHub.