Why so many?

Readings you still understand six months later

Drawing a temperature curve is no great feat. Drawing one where you can still tell months later what happened on Tuesday night is: that takes thresholds, zones, markers and annotations — precisely the part that makes up the real work in an incident analysis.

MLTimeGraph draws the same curve in the browser and on the server, in TypeScript and in Go. That both really draw the same chart is checked on every test run. For occupancy and distribution across an area, the isometric heatmap followed.

Every probe needs a label

Measuring points, devices, calibration certificates — all of it needs to be labelled unambiguously and read back later. The libraries for that were written for our own use first.

Then an LLM got an MCP server alongside them, so it could create and read codes itself. And the interface we had originally built only for testing turned out to be useful to other people too — so today it exists for iPhone, iPad and Android, as a desktop app and on the command line.

A report an inspector believes

Producing an audit report as a PDF is easy. Producing one where you can still prove months later that it has not been altered takes a signature and a timestamp — and for that, a certificate somebody has to issue.

For our customers that used to be a product of its own: a contract with a certificate authority, monthly fees, and a piece of software they used maybe five per cent of. For signing a temperature report, that is the wrong arithmetic.

So we issue the certificates ourselves. They come with the products, with no annual fee and no second contract. The same machinery seals photographs on the other side of the house — parts of OpticScript use it.

A tool we barely need ourselves any more

The audit reports started life as HTML and were poured into PDF from there. That is a sound approach, and the service doing it still does it well.

Our reporting engine now runs on Markdown instead. We generate the PDFs from that directly — considerably faster than going through an embedded Chrome. Which has left the PDF Server largely out of work here.

We released it anyway rather than mothballing it. It still solves the problem it was built for; that we solve it differently today does not make it any worse for anyone else.

Talking is not enough

A model that can only answer is of limited help in a working day. The moment it should actually do something — generate a code, draw a series of readings, file something away — it has no way to get there. The Model Context Protocol is that way, but somebody has to write the servers.

So we wrote them. First for what we needed ourselves every day — the barcode server further up was one of the first — then for what turned out to be useful beyond that.

Explaining was harder than building

Writing an MCP server is not hard. Writing one a model then uses the way you intended is. So that this knowledge would not sit in a few heads, we wrote down what we had learned.

From the basics to agentic servers and sampling — including the part that cost us the most: how to design a server so that it explains itself.

The tests cost more than the server

Our MCP servers did not always do what they were supposed to. Worse: some stopped working with newer clients from one day to the next — without anything having changed on our side. So we needed something that checks against the current specification, not the one that applied when the code was written.

Unit tests for MCP servers were laborious and cost LLM calls on every run. So the tester got a query language of its own: a script describes what a call should return, and checks it without a single model. And because writing the documentation by hand was just as tedious, it produces a document showing how an LLM sees the server.

Three servers, one dataset — and none of it belongs in the model

A question like “show me this table as a chart” passes through several hands: one server fetches the data, one computes, one draws. The intermediate results have to travel from one to the next — but not through the model.

The large providers have dedicated services for exactly this. Locally there are none. And passing data along through the context is not merely expensive: with a database on one side and an image generator on the other, it is a security problem.

mlcartifact is the store in between. One server files its result and passes on an identifier; the next one fetches it with that. The model sees the identifier, not the data.

Models cannot do arithmetic

“How long was the sensor outside the permitted range?” sounds like an easy question. For a language model it is not: the answers were often plausible and wrong. Asking for the average of a series of readings between two dates gave the same picture.

Rather than teaching the model to calculate, we let it write a function. It states the problem as TypeScript, the function runs, and what comes out is a number from a calculation rather than one from a prediction. In practice this works remarkably well.

The machine we build on is somewhere else

Development here happens almost entirely remotely, on a server reachable only over SSH. A terminal alone is not enough: you want to see files, change one quickly, watch the containers running beside it — and preferably in one window rather than six.

The first attempt was called MLCRemote and worked the way VS Code does: an agent is installed on the remote machine and everything else talks to it. That worked excellently — just not on small servers, and certainly not at a customer site. Nobody wants something installed on their production system merely because we are supposed to take a look at it.

So we started again, this time over plain SSH: MLC Terminal. Because the same thing makes it easy to support customer systems, the Docker and server-monitoring parts followed. Building on that came a small tray icon showing who is currently connected to a machine.

Manuals get written in Markdown

We document almost everything in Markdown — manuals, standard operating procedures, internal notes. What was missing was an editor that also turns them into something you can hand to someone, and that keeps the documents on your own machine while doing it.

Adjusting images by hand is busywork

Good documentation needs images, and images want cropping, scaling, labelling and saving in three formats. By hand that is the same half hour every time.

OpticScript turns it into a script: crop, scale, label, write out as PNG, JPEG or WebP — repeatably and without a mouse. Our unit tests use it for image comparison. And Photo Protection, which sits on the same engine, seals and marks images so it can later be shown who they came from.

Images without taking a weekend off

There are very good tools for generating images locally — ComfyUI and others. But not everyone wants to, or can, spend hours reading up on how to set such a thing up. And it should run on an employee laptop, not only on a machine with an expensive graphics card.

That produced two prototypes built on open models, plus a studio that makes the generated images findable again through tags and styles. And because such images turned out to pick up artefacts when enlarged for print, a service of its own for upscaling followed.

Did I forget to commit something?

Anyone working on several projects at once has a dozen working copies on disk by Friday afternoon and no idea any more which of them is clean. The question is trivial; the answer, across twelve directories, is tedious.

GitPulseMLC answers it at a glance, for local and remote repositories at the same time. The smallest tool here — and one everybody in the house uses.