Technische Dokumentation gehört zu den Aufgaben, die in Projekten selten laut scheitern, aber häufig leise liegen bleiben. Ein neues Werkzeug namens Blume setzt an genau dieser Stelle an: Es genügt eine einzige Markdown-Datei, um daraus eine komplette Dokumentation im Web zu erzeugen – inklusive Navigation, Suchfunktion und einer Anbindung über MCP.

Was das Tool laut Ankündigung leistet

Der Ansatz ist bewusst schlank. Ausgangspunkt ist Markdown, also eine einfache Textauszeichnungssprache, in der Überschriften, Listen und Codebeispiele mit wenigen Sonderzeichen strukturiert werden. Aus dieser Quelldatei generiert Blume eine HTML-Dokumentation, die im Browser aufgerufen werden kann.

Zwei Bestandteile machen aus der reinen Textkonvertierung ein nutzbares Portal: eine Navigation, die sich aus der Struktur des Dokuments ergibt, und eine Suche, mit der Leserinnen und Leser gezielt Passagen finden. Damit fällt jener Aufwand weg, der bei Doku-Projekten oft am Anfang steht – Seitenbaum aufsetzen, Templates bauen, Suchindex konfigurieren.

Die MCP-Anbindung als eigentlicher Unterschied

Bemerkenswert ist der zweite Ausgabekanal. Blume stellt die Dokumentation zusätzlich über MCP bereit. MCP steht für Model Context Protocol, eine Schnittstellenkonvention, über die KI-Assistenten externe Inhalte und Werkzeuge abfragen können, ohne dass für jedes System eine eigene Integration programmiert werden muss.

Praktisch heißt das: Die Dokumentation ist nicht nur eine Website für Menschen, sondern gleichzeitig eine abfragbare Quelle für Assistenzsysteme. Wer in einer Entwicklungsumgebung oder einem Chat-Assistenten arbeitet, kann Inhalte der Doku dort abrufen, statt sie in einem zweiten Fenster zu suchen und per Copy-and-paste zu übertragen.

Diese Doppelnutzung ist der eigentliche Punkt. Bisher waren Dokumentationsportale und KI-Workflows getrennte Welten: Auf der einen Seite ein statischer Site-Generator, auf der anderen Seite Inhalte, die man mühsam in einen Index oder eine Vektordatenbank überführt, damit ein Assistent damit arbeiten kann. Wenn die Doku selbst als MCP-Quelle auftritt, entfällt dieser Zwischenschritt.

Warum eine einzelne Datei ein Argument ist

Auf den ersten Blick klingt es nach einer Einschränkung, eine Dokumentation in nur einer Datei zu pflegen. In vielen mittelständischen Projekten ist es das Gegenteil. Ein einzelnes Textdokument lässt sich versionieren, im Pull Request reviewen und ohne Redaktionssystem bearbeiten. Es gibt keine Ordnerkonventionen, die man kennen muss, und keine Konfigurationsdateien, die nach einem halben Jahr niemand mehr versteht.

Genauso wichtig: Die Einstiegshürde für Beiträge sinkt. Wer eine Fehlermeldung dokumentieren oder einen Deployment-Schritt ergänzen will, öffnet eine Datei und schreibt zwei Absätze. Erfahrungsgemäß entscheidet gerade diese kleine Hürde darüber, ob eine Dokumentation aktuell bleibt oder nach dem Projektabschluss veraltet.

Die Grenzen des Ansatzes liegen auf der Hand und sollten realistisch eingeschätzt werden. Eine Datei bleibt überschaubar, solange der Umfang überschaubar ist. Für umfangreiche Produktdokumentationen mit mehreren Sprachversionen, Zielgruppen und Freigabeprozessen bleibt ein strukturiertes Redaktionssystem die passendere Wahl.

Typische Einsatzfelder im Projektalltag

Für welche Fälle sich ein derart schlanker Ansatz anbietet, lässt sich gut abgrenzen:

  • Technische Projektdokumentation: Architekturentscheidungen, Setup-Anleitungen und Betriebshinweise, die im Repository neben dem Code leben.
  • Interne Handbücher: Abläufe, Zuständigkeiten und Checklisten für ein Team, die keine Corporate-Website brauchen, aber durchsuchbar sein müssen.
  • Schnittstellen- und Integrationsdokumentation: Beschreibungen, die Entwicklerinnen und Entwickler ohnehin während der Arbeit im Editor benötigen – hier zahlt sich die MCP-Anbindung besonders aus.
  • Übergaben: Alles, was am Projektende an Kundenseite oder ein internes Team übergeht und dort ohne Spezialwissen weitergepflegt werden soll.

Was vor der Einführung zu klären ist

Wer ein solches Werkzeug erprobt, sollte einige organisatorische Fragen vorab beantworten. Wo liegt die Quelldatei, und wer darf sie ändern? Wird die HTML-Ausgabe automatisch bei jeder Änderung neu erzeugt, oder ist das ein manueller Schritt, den irgendwann niemand mehr ausführt?

Bei der MCP-Anbindung kommt die Zugriffsfrage hinzu. Interne Dokumentation enthält häufig Angaben, die nicht in einen öffentlich erreichbaren Assistenten gehören – Serveradressen, Prozessdetails, Namen von Ansprechpersonen. Es lohnt sich also, von Beginn an zu trennen zwischen dem, was öffentlich dokumentiert wird, und dem, was intern bleibt.

Einordnung

Blume ist kein neues Paradigma, sondern ein Hinweis darauf, wohin sich Dokumentationswerkzeuge bewegen: weg von aufwendigen Portalen, hin zu Inhalten, die gleichzeitig für Menschen lesbar und für Assistenzsysteme abfragbar sind. Für Web- und Softwareprojekte heißt das, MCP künftig als regulären Ausgabekanal mitzudenken – so wie heute HTML und Suchindex. Wer Dokumentation ohnehin als Textdatei im Repository pflegt, kann diesen zweiten Kanal mit geringem Aufwand ergänzen und spart sich später den Umbau gewachsener Doku-Landschaften.

Quellen