KI im BIM-Autorenwerkzeug über MCP — warum der lesbare Quelltext den Unterschied macht

Worum es geht: KI-Assistenten wie Claude, die in einem BIM-Programm nicht nur Fragen beantworten, sondern selbst mitarbeiten — Bauteile auslesen, Ansichten erzeugen, Pläne ableiten. Der Weg dafür hat einen Namen: das Model Context Protocol, kurz MCP, ein offenes Protokoll, das Anthropic am 25. November 2024 vorgestellt hat. Ein MCP-Server bietet dem Sprachmodell Werkzeuge an — lies die Eigenschaften dieses Bauteils, exportiere diese Ansicht —, und das Modell ruft sie auf, statt nur darüber zu reden. Autodesk, Graphisoft und Trimble bauen solche Server für ihre Programme; für Bonsai, die quelloffene BIM-Erweiterung für das 3D-Programm Blender, gibt es sie aus der Gemeinschaft.

Wer mit BIM plant, trifft solche Assistenten also zunehmend im eigenen Werkzeug an — und die naheliegende Frage ist, was sie dort tatsächlich leisten. Dieser Text fragt genauer: Was entscheidet darüber, wie weit ein Sprachmodell in einem BIM-Werkzeug kommt? Untersucht habe ich das an einer Aufgabe aus dem Planungsalltag, der Ableitung eines Plans aus dem Modell, angelehnt an die DIN-Norm für Bauzeichnungen.

Gemessen habe ich an einem Minimodell: eine zweischichtige Außenwand von fünf Metern Länge aus Ziegel und Wärmedämmverbundsystem, ein Fenster, eine Tür, später eine Stütze. Daraus sollte ein Blatt DIN A3 quer im Maßstab 1:50 entstehen, Grundriss und Schnitt, dargestellt in Anlehnung an DIN 1356-1, nicht in jedem Punkt nach ihr. Diese Norm ist zurückgezogen — an ihre Stelle ist im Januar 2025 DIN EN ISO 7519 getreten —, in der Praxis aber noch weit verbreitet; deshalb bezieht sich dieser Text auf sie. Gearbeitet wurde in 16 Sitzungen zwischen dem 16. und dem 21. September 2026, mit Blender 5.2.0 LTS und Bonsai samt IfcOpenShell 0.8.5, in der letzten Sitzung mit der Entwicklungsfassung 0.9.0-alpha260921. Ein Vergleichslauf in einem anderen Programm gehört nicht dazu — was hier über kommerzielle Werkzeuge steht, stammt aus deren Dokumentation, nicht aus einer Messung.

Die naheliegende These lautet: Die Hersteller geben dem Sprachmodell einen festen Werkzeugsatz, Bonsai gibt ihm alles, also kann es in Bonsai mehr. Das ist nicht falsch, aber es trifft den Punkt nicht. Freien Code ausführen lassen, Stand September 2026, auch kommerzielle Werkzeuge. Was Bonsai davon unterscheidet, ist etwas anderes: Das Sprachmodell kann nachlesen, was die installierte Fassung tatsächlich tut.

Ein Beispiel, bevor es allgemein wird. Eine Maßzahl nach DIN schreibt 74,5 Zentimeter als 74⁵. Bonsai schreibt 0.745, und es bietet eine Einstellung für die Nachkommastellen. Stellt man sie auf zwei, steht auf dem Plan 0.74 — nicht 0.75, weil die Gleitkommazahl knapp unter 0,745 liegt. Die Zahl sieht richtig aus und ist fünf Millimeter falsch. Kein Handbuchsatz hätte das verraten; die Bonsai-Dokumentation zu Zeichnungen war bei unserer Recherche am 15. September 2026 ausdrücklich als unvollständig gekennzeichnet. Die Antwort stand an anderer Stelle: in der Funktion format_distance der installierten Fassung, die Meter fest mit drei Nachkommastellen formatiert. Nach diesem einen Blick war die Frage nicht mehr, wie man die Einstellung überlistet, sondern dass man die Maßzahl selbst schreiben muss.

Warum überhaupt ein Sprachmodell am Zeichnungsweg

Ein Plan, der aus einem Modell abgeleitet wird, statt gezeichnet zu werden, folgt Änderungen von selbst — so das Versprechen. Bonsai erzeugt dafür je Zeichnung eine SVG-Datei und gestaltet sie über eine CSS-Datei. Nach DIN 1356-1 sieht das Ergebnis ab Werk nicht aus. Es fehlen Linienstärken je Bauteilschicht, Materialschraffuren, die deutsche Maßzahlschreibweise mit hochgestellter Millimeterstelle, Höhenkoten mit den richtigen Dreiecken, eine Legende.

Man kann all das nachrüsten — über eigene CSS-Regeln, eigene Muster und ein Skript, das die erzeugte Zeichnung nach dem Export überarbeitet. Nur muss man dafür wissen, welche Klassen Bonsai in die SVG schreibt, woher es sie nimmt, wie es mehrere Zeichnungen zu einem Blatt zusammensetzt und was dabei mit der eigenen CSS geschieht. Das ist Wissen über das Innere eines Werkzeugs, und es steht nicht in der Oberfläche.

Wer so etwas ohne eigenen Programmierer baut, braucht jemanden, der dieses Innere kennt oder es kennenlernen kann. Genau das habe ich einem Sprachmodell übertragen.

Die These, wie sie in der Literatur steht

Die Hersteller setzen auf einen begrenzten Zugang, und sie begründen das. Autodesk hat am 17. Juni 2026 einen öffentlichen MCP-Server für Revit beschrieben: sieben Werkzeuge, darunter Modellabfrage, Elementdaten, Auswahl, Ansicht öffnen und Ansicht exportieren — ausschließlich lesend, und zwar ausdrücklich mit Absicht. Schreibzugriff soll später über einen eigenen Server kommen, getrennt vom lesenden. Der Autodesk Assistant in Revit 2027 läuft laut Autodesk als Technologievorschau für eine festgelegte Menge unterstützter Abläufe. Graphisoft führt MCP für Archicad in seiner öffentlichen Planung als „Coming soon", Stand 7. August 2026, geplant sind ein eingebauter Zugang über den AI Assistant und ein öffentlicher Server. Trimble hat am 28. April 2026 einen Connector für SketchUp und Claude vorgestellt, den ersten MCP-Connector des Hauses, der Geometrie aus einer Beschreibung erzeugt. Für Allplan 2026 nennt Nemetschek in einer Mitteilung vom 15. Oktober 2025 einen AI Assistant, der auch beim Programmieren unterstützt.

Die Logik dahinter ist nachvollziehbar: Ein benanntes Werkzeug lässt sich prüfen, protokollieren und zurücknehmen. Ein Gemeinschaftsprojekt für Revit mit rund neunzig Werkzeugen schreibt diesen Grundsatz sogar ausdrücklich in seine Beschreibung: keine Hintertür für beliebigen Code, jeder Schreibvorgang eine benannte Transaktion, die man einsehen und zurücknehmen kann.

Die Gegenposition kommt, bemerkenswerterweise, vom Hersteller des Sprachmodells selbst. Anthropic hat am 4. November 2025 beschrieben, wie ein Modell MCP-Werkzeuge als Code benutzt statt als Einzelaufrufe: Es liest die Definitionen nur bei Bedarf und verarbeitet Daten, bevor sie überhaupt im Gespräch landen. Im Beispiel des Beitrags sinkt der Verbrauch von 150.000 auf 2.000 Token. Derselbe Beitrag nennt den Preis: Code, den ein Modell erzeugt, braucht eine abgeschottete Ausführungsumgebung, Grenzen und Überwachung — Aufwand, den feste Werkzeugaufrufe nicht haben.

Und es gibt die grundsätzliche Skepsis. Im OSArch-Forum, dem Treffpunkt der Bonsai-Gemeinschaft, wurde im März 2025 gefragt, ob sich Claude über MCP an Bonsai anbinden lässt. Einer der Einwände dort, gerichtet auf das Umschlüsseln und Prüfen von Modelldaten: Prüfung müsse vollständig verlässlich und deshalb algorithmisch sein; in komplexen Fällen wisse man sonst nie, ob die Arbeit richtig erledigt wurde. Die Diskussion ist öffentlich nachzulesen.

Die These dieses Textes steht zwischen beiden: Offenheit zählt — aber nicht, weil das Sprachmodell mehr darf, sondern weil es nachsehen kann. Ob das trägt, sollte die Planableitung zeigen.

Der Aufbau

Die Werkzeuge und wem sie gehören. Bonsai ist ein Projekt der IfcOpenShell-Gemeinschaft und steht unter GPL-3.0-or-later, die darunterliegende Bibliothek IfcOpenShell unter LGPL-3.0-or-later. Der MCP-Server ist ein drittes, eigenständiges Gemeinschaftsprojekt — Bonsai_mcp von Jota de Rodriguez, MIT-Lizenz, aufgebaut auf MCP for Blender (vormals BlenderMCP) von Siddharth Ahuja. Die Skripte, die in den Sitzungen entstanden sind, sind eigene, unveröffentlichte Arbeit: geschrieben von Claude im Gespräch mit mir, geprüft am Blatt.

Der Werkzeugsatz des Servers umfasst 17 Einträge. Die meisten sind fest umrissen: Projektinformationen, räumliche Struktur, Eigenschaften, Mengen, Beziehungen, die ausgewählten Elemente, ein Bildschirmfoto der aktuellen Ansicht, ein Zeichnungsexport als Bild, die Georeferenzierung lesen und setzen. Einer ist es nicht: execute_blender_code führt beliebigen Python-Code im laufenden Blender aus. Das Projekt schreibt selbst dazu, man solle ihn mit Vorsicht benutzen und vorher speichern.

Die Arbeitsweise. execute_blender_code liefert keine Rückgabe an das Sprachmodell. Jeder Aufruf schreibt deshalb sein Ergebnis in eine Protokolldatei, die danach gelesen und gelöscht wird. Vor jedem Eingriff ins Modell wird gespeichert.

Die eine Regel, die für diesen Text zählt: Fragen zum Verhalten werden an die installierte Fassung gestellt — nicht an Foren, nicht an den Entwicklungszweig auf GitHub. Wo Quelltext gelesen wird, steht in der Sitzungsnotiz die Fassung und die Zeile, und die Zeilennummern werden am Gerät ausgegeben, nicht aus dem Gedächtnis zitiert. Zu jedem Befund ist festgehalten, auf welchem Weg er erhoben wurde: am erzeugten Blatt, in einer Probe am Modell oder im Quelltext.

Die Messungen

Fünf Fälle aus den Sitzungsnotizen. Sie zeigen nicht alles, was entstanden ist, sondern die Stellen, an denen eine Frage über das Werkzeug erst im Quelltext zu beantworten war. Jeder Fall folgt demselben Muster: was am Blatt auffiel, was im Quelltext stand, was daraus wurde. Wo das im Quelltext jeweils steht, zeigt eine Liste mit Links am Ende des Abschnitts.

Die Maßzahl. Der Fall aus dem Vorspann: Bonsai schreibt Maße immer in Metern mit drei Nachkommastellen, und die Einstellung für zwei Stellen macht aus 0,745 den Wert 0.74. Eine Einstellung, die das DIN-Format liefert, gibt es nicht. Daraus folgte ein kleines Skript, das nach jeder Erzeugung der Zeichnung die Maßzahlen in die deutsche Schreibweise umsetzt — 74⁵ statt 0.745.

Das Blatt, das in zwei Programmen verschieden aussah. Im Browser stimmte das Blatt. In Inkscape fehlte die Hälfte: keine Unterscheidung der Linienstärken, die Schraffuren grau statt schwarz. Eine Fehlermeldung gab es nirgends, und die erste Vermutung — zu verschachtelte Regeln — war falsch. Im Quelltext stand der Grund: Wenn Bonsai mehrere Zeichnungen zu einem Blatt zusammensetzt, schreibt es deren Gestaltungsregeln um — und ein Kommentar, der zwischen zwei Regeln steht, klebt danach an der schließenden Klammer der vorigen. Inkscape überspringt die Regel, die darauf folgt; der Browser nicht. Claude hat diesen Umbau außerhalb von Blender nachgebaut und kam zeichengenau auf dieselbe Datei wie das echte Blatt. Die Abhilfe war danach schnell gemacht: Kommentare stehen nur noch innerhalb der Regeln. Ohne den Quelltext hätte nur Ausprobieren geholfen.

Die Schraffur, die nicht kam. Eine Schraffur hängt in Bonsai an der Materialkategorie — Mauerwerk, Beton, Dämmung. Der Quelltext zeigt: Die Kategorie wird nur bei Schichtmaterial an die Zeichnung weitergegeben. Ein Bauteil aus einem einzigen Material oder einem Profil geht leer aus und bekommt keine Schraffur. Der naheliegende Ausweg wäre ein Flächenstil in der IFC-Datei selbst gewesen; eine Suche im Quelltext der Zeichnungsmodule findet ihn nirgends — er wird nicht gezeichnet. Die Kategorie wird deshalb für diese Bauteile vom Skript nachgetragen, und die Schraffur kommt aus der Gestaltungsdatei.

Bemaßen wie im CAD. Bonsais eigener Knopf legt ein Maß an und öffnet danach sofort den Bearbeitungsmodus, in dem man die Punkte einzeln setzt. Im Quelltext steht, dass die Funktion darunter auch ohne diesen Schritt auskommt, und wo Bonsais Objektfang sitzt. Daraus wurde ein eigenes Werkzeug: die Punkte am Bauteil nacheinander anklicken, und die Kette steht. Beim Bau fiel noch etwas auf: Während man fängt, legt Bonsai für jede Linie unter der Maus ein Hilfsobjekt an und räumt es nicht wieder weg — nach einer Probe waren es 398. Das eigene Werkzeug übergeht diese Linien. Mein Satz nach der ersten Probe: „ich habe alle Maßketten in 30 Sekunden neu angelegt".

Wo die Zeichnung auf dem Blatt sitzt. Die Lage jeder Zeichnung steht allein in einer kleinen Layoutdatei des Blattes, als zwei Zahlenpaare; der Blattbau liest sie und passt nur die Größe an. Verschieben heißt also: zwei Zahlen ändern und das Blatt neu bauen. Das klingt unscheinbar und hat das sichtbarste Ergebnis getragen.

Die Anmerkungen einer Zeichnung sind im 3D-Fenster von Bonsai schwer zu beurteilen; man sieht erst am erzeugten Blatt, ob eine Maßzahl richtig sitzt. Auf meine Frage, ob so etwas wie ein Vorschaufenster denkbar sei, ist ein eigenes Werkzeug entstanden. Ein Reiter in der Seitenleiste von Blender erzeugt auf Knopfdruck die Zeichnung, lässt die Nachbearbeitung laufen und zeigt das Ergebnis im Browser. Später kam die Blattansicht dazu: Zeichnungen und Legende lassen sich mit der Maus verschieben, ein Knopf Übernehmen schreibt die neue Lage in die Layoutdatei zurück, sichert die alte und baut das Blatt neu. Drucken und ein PDF über Inkscape 1.4.4 folgten. Nichts davon ist im Werkzeugsatz des MCP-Servers vorgesehen. Möglich wurde es, weil sich im Quelltext nachsehen ließ, wo Bonsai die Lage einer Zeichnung speichert und welcher Teil des Blattbaus sie liest.

Der Stand am Ende der Messreihe, 21. September 2026: Grundriss und Schnitt der zweischichtigen Wand mit Linienstärken je Schicht, Schraffuren als echte Linien, Maßzahlen nach DIN, Höhenkote und Legende auf einem Blatt. Mein Urteil am Bildschirm: „passt so."

Zum Nachlesen im Quelltext von Bonsai 0.8.5. Wer einen der Fälle selbst nachprüfen will, findet die Stellen hier. Jeder Link führt auf die Datei in der veröffentlichten Fassung, bei Zeilenangaben direkt auf die Zeilen.

• Die Maßzahl: Meter werden fest mit drei Nachkommastellen geschrieben. Die Funktion, die Maßzahlen formatiert, Zeilen 384–386
• Das Blatt in zwei Programmen: Hier schreibt der Blattbau die Gestaltungsregeln jeder Zeichnung um, Zeichen für Zeichen. Der Umbau der Gestaltungsregeln, Zeilen 343–372
• Die Schraffur: Die Materialkategorie wird nur innerhalb einer Materialschicht weitergegeben. Wo die Kategorie an die Zeichnung gehängt wird, Zeilen 1344–1347. Einen Flächenstil aus der IFC-Datei liest keines der Module für Zeichnung, Stil und Material; eine Suche nach FillAreaStyle findet dort nichts.
• Bemaßen wie im CAD: Die Funktion, die ein Maß anlegt, macht den Bearbeitungsmodus nur auf Wunsch auf. Das Anlegen eines Maßes, Zeilen 468–503 · der Objektfang
• Die liegengebliebenen Hilfsobjekte: Um zu prüfen, ob eine Linie sichtbar ist, legt Bonsai eine Kopie als neues Objekt an und entfernt sie nicht wieder. Die Sichtbarkeitsprüfung, Zeilen 252–265
• Die Lage auf dem Blatt: Der Blattbau liest die Lage jeder Zeichnung aus der Layoutdatei des Blattes und passt nur ihre Größe an. Das Nachführen der Zeichnungsgrößen

Der Befund, der gegen die eigene These arbeitet

Erstens: Freier Code ist kein Merkmal offener Software. Der Tekla Model Assistant, in Tekla Structures 2026 als Vorschaufunktion, erzeugt auf Zuruf ein Makro, führt es aus und bessert es nach Rückfrage nach, wenn es scheitert. Für Revit gibt es einen Gemeinschaftsserver, der C#-Code an die laufende Anwendung übergibt; das Projekt ist seit dem 25. Februar 2026 archiviert. Der Gegensatz „fester Werkzeugsatz gegen volle Freiheit" hält also nicht — nicht als Grenze zwischen offen und geschlossen. Was bleibt, ist schmaler und genauer: Dort läuft der Code gegen eine dokumentierte Schnittstelle, deren Umsetzung verschlossen ist. Wo die Dokumentation schweigt, kann das Sprachmodell nur ausprobieren. Ausprobieren ging in Bonsai genauso, und es wurde reichlich getan. Der Quelltext hat die Probe nicht ersetzt; er hat gesagt, wo zu proben ist.

Zweitens: Lesen können heißt nicht, dass gelesen wird. Das Sprachmodell sieht nicht bei jeder Frage von selbst im Quelltext nach. An einer Stelle hat Claude einen Menüweg in Bonsai aus dem Gedächtnis genannt — als solchen gekennzeichnet, aber nicht nachgeprüft. Die Kennzeichnung sagt dem Leser, woran er ist; ein Beleg ist sie nicht. Der Quelltext ist nur dann ein Beleg, wenn er gelesen wird.

Drittens: Was das Sprachmodell baut, reist nicht mit der IFC. Maßzahlen nach DIN, Höhenkoten, Legende und Schraffurbild entstehen in der Nachbearbeitung. In der Modelldatei steht davon nur die Materialkategorie. Wer die IFC weitergibt, gibt die Darstellung nicht mit. Und die Maßpunkte selbst sind in Bonsai freie Punkte, sie ziehen nicht mit. In der ersten Sitzung ist die Ziegelschicht von 24 auf 30 Zentimeter gewachsen; das Schichtmaß darüber zeigte weiter 0,240 — für die Strecke zwischen seinen beiden Punkten richtig, nur lag der eine Punkt jetzt mitten in der Wand. Komfortabler wäre ein Messpunkt, der mit der Geometrie wandert. Es geht aber auch so, wenn man weiß, was nach einer Änderung zu tun ist: die Maßkette ansehen und die Punkte neu setzen.

Und eine Folge, die leiser ist: Je leichter sich ein Werkzeug erweitern lässt, desto schneller wächst neben ihm eine eigene Schicht aus Skripten, die nur ihr Urheber pflegen kann. In unserem Fall waren es am 21. September 2026 fünf. Offenheit verschiebt die Frage der Wartbarkeit vom Hersteller zum Anwender — und der Anwender merkt es erst, wenn eine neue Fassung eine Zeilennummer verschiebt.

Die Grenzen

Gemessen wurde an einem Minimodell, von einer Person, in sechs Kalendertagen. Das Blatt ist eines, nicht ein Plansatz; die Stiftsätze für 1:20, 1:100 und 1:200 fehlen noch.

Die kommerziellen Werkzeuge sind nicht gemessen, sondern nach ihrer Dokumentation und ihren Ankündigungen beschrieben, Stand 23. September 2026. Mehrere der genannten Funktionen sind Vorschau- oder Betafassungen, und dieser Stand ändert sich in Monaten, nicht in Jahren. Eine Kaufempfehlung folgt daraus nicht, in keine Richtung.

Das Sprachmodell selbst ist nicht Gegenstand der Messung. Ein anderes Modell hätte anders gelesen, anders geirrt, anders gebaut; die Befunde über Bonsai gelten unabhängig davon, die Arbeitsweise nicht.

Die Zeilennummern gelten für die genannten Fassungen und für keine anderen. Schon beim Wechsel auf die Entwicklungsfassung 0.9.0-alpha war die Funktion für die SVG-Klassen keine lose Funktion mehr, sondern eine Methode, und stand an anderer Stelle — die Sache selbst war gleich geblieben.

execute_blender_code arbeitet mit allen Rechten des laufenden Blender. Ich habe es lokal an einem Wegwerfmodell benutzt, nie an Projektdaten anderer, und immer an einem gespeicherten Stand. Kommen Zugriff auf eigene Daten, das Lesen fremder Inhalte und ein Weg nach außen zusammen, beschreibt die Sicherheitsliteratur genau diese Kombination als Einfallstor — Simon Willison hat sie am 16. Juni 2025 die lethal trifecta genannt. Das ist kein Randthema, und es ist nicht Teil dieser Messung.

Was daraus für die Praxis folgt

Fragen Sie bei der Werkzeugwahl nicht, ob ein Programm „KI kann". Fragen Sie, ob das Sprachmodell nachsehen kann, was die installierte Fassung tut — im Quelltext oder wenigstens in einer vollständigen, fassungsgenauen Dokumentation. Ein großer Werkzeugsatz ohne diese Möglichkeit ist eine Oberfläche mit mehr Knöpfen.

Halten Sie jede Werkzeugaussage mit Fassung und Fundstelle fest. Eine Zeile Quelltext mit Zeilennummer lässt sich in einem halben Jahr nachprüfen; ein Satz aus einem Chatverlauf nicht.

Behandeln Sie Nachbearbeitung als festen Schritt der Ausgabekette, nie als Handgriff. Ein einmal von Hand verbesserter Plan ist beim nächsten Export wieder roh. Das Skript muss bei jeder Neuerzeugung laufen, von selbst.

Leiten Sie Pläne immer aktuell aus dem Modell ab, und nutzen Sie das Ergebnis am besten gleich am Bildschirm. Ein gedrucktes Blatt ist ein Stand; ein Plan, der bei Bedarf neu aus dem Modell entsteht, ist der jeweils aktuelle. Für die Baustelle gibt es dafür schon voll funktionierende Lösungen.

Freien Code nur an einem gespeicherten Stand, lokal und mit Rückkanal über eine Datei. Wer das Protokoll liest, statt der Rückgabe zu vertrauen, sieht auch, was schiefging.

Und geben Sie zurück, was Sie finden. Aus dieser Messreihe sind fünf Stellen vorgemerkt, an denen Bonsai selbst eine Ergänzung oder einen Fehlerbericht vertragen könnte — von der Materialkategorie für Einzelmaterial bis zum festen Maßzahlformat. Für einen solchen Beitrag gilt die umgekehrte Regel: Er wird gegen den aktuellen Entwicklungszweig geprüft, nicht gegen die installierte Fassung. Das ist die andere Seite der Offenheit, und ohne sie bleibt das Lesen eine Einbahnstraße.

Wie es weitergeht

Offen bleiben die Stiftsätze für die übrigen Maßstäbe und die Frage, ob aus den fünf Skripten eine Erweiterung wird, die ein zweiter Anwender ohne Rückfrage pflegen kann. Das ist das eigentliche Abnahmekriterium — nicht, ob das Blatt schön aussieht.

Was bleibt, ist ein Satz. Ein Werkzeugsatz sagt, was ein Sprachmodell tun darf. Der Quelltext sagt, was das Werkzeug tut. Für die meisten Aufgaben reicht das Erste. Für die, an denen eine Zahl richtig aussieht und falsch ist, braucht es das Zweite.

Dass eine Anzeige etwas anderes sagen kann als die Datei, war der Befund des Beitrags zum Nordwinkel in IFC. Dass eine Erfolgsmeldung kein Beleg für ein Ergebnis ist, der des Messberichts zu Git als gemeinsamer Datenumgebung.