Warum so viele?

Messwerte, die man ein halbes Jahr später noch versteht

Einen Temperaturverlauf zu zeichnen ist keine Kunst. Einen zu zeichnen, an dem man Monate später noch erkennt, was in der Nacht zum Dienstag passiert ist, schon: dafür braucht es Schwellen, Zonen, Marker und Anmerkungen — genau das, was bei einer Störungsanalyse die eigentliche Arbeit ausmacht.

MLTimeGraph zeichnet dieselbe Kurve im Browser und auf dem Server, in TypeScript und in Go. Dass beide wirklich dasselbe zeichnen, prüft ein Test bei jedem Lauf. Für Belegungen und Verteilungen über eine Fläche kam die isometrische Heatmap dazu.

Jeder Fühler braucht einen Aufkleber

Messstellen, Geräte, Kalibrierscheine — alles will eindeutig gekennzeichnet und später wieder eingelesen werden. Die Bibliotheken dafür entstanden zuerst für den Eigenbedarf.

Dann bekam eine LLM einen MCP-Server dazu, damit sie Codes selbst erzeugen und lesen kann. Und die Oberfläche, die wir ursprünglich nur zum Testen gebaut hatten, war sichtbar auch für andere nützlich — also gibt es sie heute für iPhone, iPad und Android, als Desktop-App und auf der Kommandozeile.

Ein Bericht, dem ein Prüfer glaubt

Ein Prüfbericht als PDF ist schnell erzeugt. Einer, bei dem sich Monate später belegen lässt, dass er seitdem nicht verändert wurde, braucht eine Unterschrift und einen Zeitstempel — und dafür ein Zertifikat, das jemand ausstellt.

Für unsere Kunden war das bisher ein eigenes Produkt: ein Vertrag mit einer Zertifizierungsstelle, monatliche Kosten, und dazu ein Programm, von dem sie vielleicht fünf Prozent benutzten. Für die Unterschrift unter einen Temperaturbericht ist das die falsche Rechnung.

Also stellen wir die Zertifikate selbst aus. Sie sind in den Produkten enthalten, ohne Jahresgebühr und ohne zweiten Vertrag. Dieselbe Technik versiegelt auf der anderen Seite des Hauses Fotos — Teile von OpticScript nutzen sie.

Ein Werkzeug, das wir selbst kaum noch brauchen

Die Prüfberichte entstanden zuerst als HTML und wurden daraus in PDF gegossen. Das ist ein guter Weg, und der Dienst, der das tut, kann es bis heute.

Inzwischen läuft unsere Berichts-Engine auf Markdown. Daraus erzeugen wir die PDFs direkt — erheblich schneller als über ein eingebettetes Chrome. Der PDF Server ist damit bei uns intern fast arbeitslos geworden.

Freigegeben haben wir ihn trotzdem, statt ihn einzumotten. Er löst das Problem, für das er gebaut wurde, nach wie vor gut; dass wir es heute anders lösen, macht ihn für andere nicht schlechter.

Reden reicht nicht

Ein Modell, das nur antworten kann, hilft im Arbeitsalltag begrenzt. Sobald es etwas tun soll — einen Code erzeugen, eine Messreihe zeichnen, eine Datei ablegen —, fehlt ihm der Weg dorthin. Das Model Context Protocol ist dieser Weg, aber die Server dafür muss jemand schreiben.

Also schrieben wir sie. Erst für das, was wir selbst täglich brauchten — der Barcode-Server weiter oben war einer der ersten —, dann für das, was sich darüber hinaus als nützlich herausstellte.

Erklären war schwerer als bauen

Einen MCP-Server zu schreiben ist nicht schwer. Einen zu schreiben, den ein Modell auch so benutzt, wie man es sich gedacht hat, schon. Damit dieses Wissen nicht an einzelnen Köpfen hängt, haben wir aufgeschrieben, was wir gelernt hatten.

Von den Grundlagen bis zu agentischen Servern und Sampling — mit dem Teil, der uns am meisten gekostet hat: wie man einen Server so entwirft, dass er sich von selbst erklärt.

Die Tests waren teurer als der Server

Unsere MCP-Server taten nicht immer, was sie sollten. Schlimmer: manche hörten von einem Tag auf den anderen auf, mit neueren Clients zu arbeiten — ohne dass sich bei uns etwas geändert hätte. Wir brauchten also etwas, das gegen die aktuelle Spezifikation prüft, nicht gegen die, die beim Schreiben galt.

Unit-Tests für MCP-Server waren aufwendig und kosteten bei jedem Lauf LLM-Aufrufe. Deshalb hat der Tester eine eigene Abfragesprache bekommen: ein Skript beschreibt, was ein Aufruf zurückgeben soll, und prüft das ohne ein einziges Modell. Und weil die Dokumentation von Hand genauso mühsam war, erzeugt er ein Dokument, das zeigt, wie eine LLM den Server sieht.

Drei Server, ein Datensatz — und nichts davon gehört ins Modell

Eine Frage wie „zeig mir diese Tabelle als Diagramm" geht durch mehrere Hände: ein Server holt die Daten, einer rechnet, einer zeichnet. Die Zwischenergebnisse müssen von einem zum nächsten — aber nicht durch das Modell hindurch.

Große Anbieter haben für genau das eigene Dienste. Lokal gibt es die nicht. Und Daten über den Kontext weiterzureichen ist nicht nur teuer: wenn auf der einen Seite eine Datenbank steht und auf der anderen ein Bildgenerator, ist es auch ein Sicherheitsproblem.

mlcartifact ist die Ablage dazwischen. Ein Server legt sein Ergebnis ab und gibt eine Kennung weiter, der nächste holt es sich darüber. Das Modell sieht die Kennung, nicht die Daten.

Modelle können nicht rechnen

„Wie lange war der Sensor außerhalb des zulässigen Bereichs?" klingt nach einer leichten Frage. Für ein Sprachmodell ist sie es nicht: die Antworten waren oft plausibel und falsch. Beim Durchschnitt einer Messreihe von–bis dasselbe Bild.

Statt dem Modell das Rechnen beizubringen, lassen wir es eine Funktion schreiben. Es formuliert das Problem als TypeScript, die Funktion läuft, und heraus kommt eine Zahl aus einer Rechnung statt eine aus einer Vorhersage. In der Praxis funktioniert das erstaunlich gut.

Der Rechner, auf dem gebaut wird, steht woanders

Entwicklung findet bei uns fast immer entfernt statt, auf einem Server, der nur über SSH erreichbar ist. Ein Terminal allein reicht dafür nicht: man will Dateien sehen, eine davon schnell ändern, die Container danebenlaufen sehen — und das am liebsten in einem Fenster statt in sechs.

Der erste Versuch hieß MLCRemote und arbeitete wie VS Code: ein Agent wird auf dem entfernten Rechner installiert, alles weitere spricht mit ihm. Das funktionierte ausgezeichnet — nur nicht auf kleinen Servern, und schon gar nicht beim Kunden. Niemand möchte, dass auf seinem Produktivsystem etwas installiert wird, bloß weil wir es uns ansehen sollen.

Also noch einmal von vorn, diesmal über reines SSH: MLC Terminal. Weil sich damit auch Kundensysteme bequem unterstützen lassen, kam der Teil für Docker und Server-Überwachung dazu. Darauf aufbauend entstand ein kleines Tray-Symbol, das zeigt, wer gerade mit einem Rechner verbunden ist.

Handbücher schreiben sich in Markdown

Wir dokumentieren fast alles in Markdown — Handbücher, Arbeitsanweisungen, interne Notizen. Was dabei fehlte, war ein Editor, der daraus auch etwas macht, das man jemandem in die Hand drücken kann, und der die Dokumente dabei auf dem eigenen Rechner lässt.

Bilder von Hand anzupassen ist Fleißarbeit

Zu guter Dokumentation gehören Bilder, und Bilder wollen zugeschnitten, skaliert, beschriftet und in drei Formaten abgelegt werden. Von Hand ist das jedes Mal dieselbe halbe Stunde.

OpticScript macht daraus ein Skript: zuschneiden, skalieren, beschriften, nach PNG, JPEG oder WebP schreiben — wiederholbar und ohne Maus. Unsere Unit-Tests nutzen es für Bildvergleiche. Und der Foto-Schutz, der auf derselben Engine sitzt, versiegelt und kennzeichnet Bilder so, dass sich später belegen lässt, von wem sie stammen.

Bilder, ohne sich ein Wochenende freizunehmen

Für lokale Bilderzeugung gibt es sehr gute Werkzeuge — ComfyUI und andere. Nur will und kann sich nicht jeder stundenlang einlesen, wie man so etwas aufbaut. Und es sollte auf einem Mitarbeiter-Laptop laufen, nicht nur auf einer Maschine mit teurer Grafikkarte.

Daraus wurden zwei Prototypen mit offenen Modellen, dazu ein Studio, das die erzeugten Bilder mit Stichwörtern und Stilen wieder auffindbar macht. Und weil sich zeigte, dass solche Bilder beim Vergrößern fürs Drucken Artefakte bekommen, kam ein eigener Dienst fürs Hochskalieren dazu.

Habe ich vergessen, etwas einzuchecken?

Wer an mehreren Projekten gleichzeitig arbeitet, hat am Freitagnachmittag ein Dutzend Arbeitskopien auf der Platte und keine Vorstellung mehr davon, welche davon sauber ist. Die Frage ist banal, und die Antwort über zwölf Verzeichnisse hinweg mühsam.

GitPulseMLC beantwortet sie auf einen Blick, für lokale und entfernte Repositories zugleich. Das kleinste Werkzeug hier — und eines, das jeder im Haus benutzt.