A paper temperature log takes any line you write on it. On a sheet taped to a walk-in door, "fine" fits as easily as "38", and the sheet can't tell you which of the two was actually measured.
I built Tolsey for the Alexa+ track of Amazon's Build, Ship, Shape hackathon. It's a food safety log for small restaurant kitchens, and a cook fills it in by voice.
## How a reading gets logged
A cook with gloved hands says "the walk-in reads 38". Tolsey works out which check point that is, which rule applies to it and whether 38 passes, then appends one line to the kitchen's record for the day, with the cook's initials and the rule's source. The reply is a few words for Alexa to say, "Walk-in, 38, in range, AB", and the screen shows the line. Say "the soup well reads 120" and it comes back OUT OF RANGE, because the Food Code wants hot food held at 135°F or more.
Under that sits a self-hosted MCP server (spec 2025-11-25, Streamable HTTP) on Cloudflare Workers, with the record in D1 and two tools, log_reading and due_now. The Alexa+ MCP toolkit is a preview for select partners, so the Echo Show in the demo is a simulated page. It is still a real MCP client of the deployed server, and it sends initialize, tools/list and tools/call the way any host would.
## What it won't log
Tolsey turns down three kinds of answer: a check with no number ("reach-in two is fine"), a number wrapped in a hedge ("under 41", "about 40", "38 or 39"), and a number whose commonly misheard twin would flip the verdict. Each refusal is saved as an open question with its own id. If the cook answers within two minutes, "38" on its own closes it. A paper log has nowhere to put a question like that.
## Notes from the build
The voice host fills in the value for you. Before it calls a tool, a host pulls the number out of the sentence, and for "under 41" it may well send 41. A server that only read the value would store a limit as a reading, so Tolsey keeps the cook's own words beside the value and checks them a second time.
Asking for digits only pays off when the answer would change. Fifteen and fifty sound alike across a loud kitchen, and at 50°F the walk-in fails, so "walk-in 15" gets "say it one digit at a time". On hot food, 160 and 116 get the same treatment. A log that asked every time would be ignored by lunch.
Mutation testing is slow, about four and a half hours for a full run, and I'd still keep it. Stryker injected 2,350 bugs into the decision and server code, and the tests caught 2,329 of them, 99.11%. The same conformance suite runs in process, in local workerd and against the live Worker with no changes between them, and on 2026-10-18 it passed 30 of 30 against the deployed server.
One surprise came from Cloudflare. I serve the MCP endpoint and the web page from one Worker, in single-page-app mode with a run_worker_first list. A POST to any path that isn't on that list never reaches the Worker: the asset layer answers 405 with an empty body, and the Worker logs nothing. The docs don't mention it, so I opened a pull request that adds a note: https://github.com/cloudflare/cloudflare-docs/pull/34475
The cut I mind most: an out-of-range reading should open a fix with a deadline, and the record should follow it to closed or overdue. That's the next build.
Links
- Live, no install (type numbers as digits): https://tolsey.taranity.com
- Demo video: https://youtu.be/zx2u-TCy7jI
- Code, MIT licence: https://github.com/voyagi/tolsey
- Devpost: https://devpost.com/software/tolsey
Top comments (1)
how do you plan to reliably flag a valid temperature reading versus a free‑form note like "fine", are you thinking of a required prefix, a checksum, or a separate metadata column?