Eine Steckdose für KI: Was MCP für das Bauwesen bedeutet

Ihr KI-Assistent entwirft die Antwort auf eine Rückfrage zu den Plänen, fasst einen Abschnitt der Leistungsbeschreibung zusammen und bringt das Besprechungsprotokoll in Form. Fragen Sie ihn aber, welcher Unterzug im 3. Geschoss die höchste Ausnutzung hat, dann rät er. Nicht, weil er nicht klug genug wäre, sondern weil er keinen Zugang zu Ihrem Modell hat.

Diese Lücke schließt sich. Das Model Context Protocol, kurz MCP, ist ein offener Standard, über den sich KI-Anwendungen mit der Software und den Daten verbinden, mit denen Ingenieure ohnehin arbeiten. Stellen Sie es sich als Steckdose für KI vor: eine genormte Steckdose, und jedes Werkzeug, das Sie einstecken, wird zu etwas, mit dem die KI tatsächlich arbeiten kann.

Ich betrachte das Thema von zwei Seiten. Durch meine Arbeit für Dlubal Software bewege ich mich in einem Umfeld, in dem MCP bereits Teil des Produkts ist, und ich entwickle eine eigene Software für die Modellprüfung auf Basis von IFC. Dieser Beitrag erklärt, was MCP ist, wofür es im Bauwesen taugt und warum es meist sinnvoller ist, unsere Werkzeuge mit den KI-Plattformen zu verbinden, die Ingenieure bereits nutzen, als einen weiteren Chatbot zu bauen.

MCP macht KI nicht klüger. Es gibt der KI einen genormten Weg zu Dingen außerhalb ihrer selbst: zu Ihren Modellen, Ihren Berechnungsprogrammen, Ihren Projektdaten.

Denken Sie an den Baustromverteiler auf der Baustelle. Ihm ist es egal, ob Sie eine Säge, einen Winkelschleifer oder einen Baustrahler einstecken, denn jedes Werkzeug hat denselben Stecker. Vor MCP bedeutete die Anbindung einer KI an eine Anwendung eine eigene Verkabelung für jedes Paar: Fünf KI-Apps und zwanzig Programme ergaben bis zu hundert einzelne Integrationen. Mit MCP braucht jedes Programm einen Server und jede KI-App einen Client. Fünfundzwanzig Teile statt hundert, auch wenn jede Verbindung weiterhin die richtige Einrichtung und die passenden Berechtigungen braucht.

Jede KI-Anwendung braucht einen Client und jedes Programm einen Server; den Rest erledigt der Standard in der Mitte.

Anthropic hat MCP im November 2024 als offenen Standard veröffentlicht. Im Dezember 2025 übergab das Unternehmen den Standard an die von OpenAI, Google, Microsoft, AWS und weiteren Unternehmen getragene Agentic AI Foundation unter dem Dach der Linux Foundation. Heute unterstützen ihn ChatGPT, Claude, Gemini, Microsoft Copilot, GitHub Copilot und Cursor.

Drei Rollen, einfach erklärt:

• Host: die KI-Anwendung, in die Sie Ihre Fragen eingeben, etwa ChatGPT, Gemini, Claude oder der eigene Chatbot Ihres Unternehmens.
• Client: der Konnektor im Host, der die Verbindung zu einem Server hält.
• Server: ein kleines Programm auf der Seite der Software, das der KI sagt, was es kann. RFEM, Revit oder ein Werkzeug zur IFC-Prüfung bekommen jeweils ihren eigenen.

Was ein Server anbietet:

• Tools sind Aktionen, die die KI aufrufen kann: ein Modell anhand der Datenanforderungen des Projekts prüfen, zwei Modellversionen vergleichen, eine Berechnung starten.
• Resources sind Daten, die die KI lesen kann: eine Modellübersicht, eine Liste der Lastfälle.
• Prompts sind vorbereitete Abläufe: „Prüfe die Änderungen zwischen den Versionen A und B.“

Entscheidend ist, wie die KI die Werkzeuge findet. Jedes Werkzeug bringt eine Beschreibung und eine strukturierte Definition seiner Eingaben mit. Wenn Sie eine Frage stellen, wählt die KI anhand dieser Angaben ein Werkzeug und liefert die Informationen, die es braucht. Niemand legt im Code fest, welcher Knopf gedrückt wird; welche Werkzeuge überhaupt verfügbar sind, entscheidet aber die Anwendung.

Ein Server kann lokal laufen, direkt neben Ihrer Desktop-Anwendung. Die Modelldatei bleibt auf Ihrem Rechner; an die KI gehen nur die Antworten, die die Werkzeuge zurückgeben. Oder er läuft remote, über HTTPS mit sauberer Authentifizierung; das passt zu Cloud-Plattformen. Wenn IFC die Art ist, wie ein Modell ein Gebäude beschreibt, dann ist MCP die Art, wie eine KI diesem Modell Fragen stellt.

Mit MCP wird aus einer KI, die selbstbewusst rät, ein Koordinator, der jede Aufgabe an ein Werkzeug übergibt, dem Ingenieure bereits vertrauen. Dieser Unterschied zählt in unserer Branche mehr als fast überall sonst.

Ein universelles Sprachmodell sagt plausiblen Text voraus. Bitten Sie es, einen Träger nachzuweisen, und Sie bekommen eine sauber formatierte, selbstsichere Antwort, die schlicht falsch sein kann, weil nie gerechnet wurde. Mit MCP delegiert die KI: Die Berechnung geht an das Berechnungsprogramm, die Frage zum Modell geht an das Modell, und die KI macht, was sie wirklich gut kann. Sie versteht die Frage, führt die Schritte in der richtigen Reihenfolge aus und erklärt das Ergebnis verständlich. Sie kann trotzdem den falschen Filter wählen oder ein Ergebnis falsch deuten; deshalb macht die Verbindung allein eine Antwort nicht zuverlässig. Sie macht sie überprüfbar.

MCP ist nicht der einzige Weg, Projektinformationen in eine KI zu bringen, deshalb lohnt ein Blick darauf, wo es sich einordnet. Eine Ergebnistabelle in den Chat zu kopieren funktioniert, ist aber eine manuelle Momentaufnahme, die veraltet, sobald sich das Modell ändert. Retrieval-Augmented Generation (RAG) lässt die KI Dokumente durchsuchen, etwa eine Norm, einen BIM-Abwicklungsplan oder ein Produkthandbuch, und zitieren, was sie findet.

Das sind keine konkurrierenden Technologien. MCP ist die Verbindung; eine Dokumentensuche ist eine Art von Werkzeug, die Sie anschließen können. Sie kann genauso hinter einem MCP-Server sitzen wie ein Werkzeug, das ein geöffnetes Modell abfragt oder eine Prüfung startet. Der nützliche Unterschied liegt darin, was das jeweilige Werkzeug kann. Eine Dokumentensuche beantwortet die Frage „Was steht in der Norm?“. Ein Modellwerkzeug beantwortet die Frage „Was steht in meinem Modell, und besteht es die Prüfung?“. Die meisten ernsthaften Abläufe im Bauwesen werden beides nutzen.

Individuelle Integrationen, etwa ein im Programm eingebauter Assistent, greifen ebenfalls auf aktuelle Daten zu, aber jede verbindet genau eine KI mit genau einer Anwendung. Mit MCP lassen sich dieselben Werkzeuge in jeder KI-App wiederverwenden, die den Standard unterstützt, in den Grenzen, die die jeweilige App setzt. Die KI kann genau das, was die Werkzeuge erlauben, nicht mehr.

Wie sieht das in einem echten Projekt aus? Diese Anfragen sind mit heute verfügbaren Servern bereits möglich:

• Modellabfragen: „Finde alle Feuerschutztüren im 2. Geschoss ohne Beschlagsatz und wähle sie aus.“ Der offizielle Revit-Server von Autodesk kann das Modell durchsuchen und die Ergebnisse auswählen.
• Mengen: „Wie viele Kubikmeter Beton stecken in den Decken, Geschoss für Geschoss?“ Open-Source-Server lesen das direkt aus einer IFC-Datei, sofern das Modell verlässliche Mengen enthält.
• Koordination: „Welche Punkte aus der Koordinationsbesprechung der letzten Woche sind noch offen?“ Koordinationsplattformen wie Revizto bieten inzwischen MCP-Server an, und Community-Server greifen auf offene Punkte und Rückfragen in der Autodesk Construction Cloud zu.
• Berechnungsergebnisse: „Wie groß ist die maximale Durchbiegung der Deckenträger für die Lastfallkombinationen im Grenzzustand der Gebrauchstauglichkeit, und hält sie L/360 ein?“ Die Antwort kommt aus dem Berechnungsprogramm, nicht aus dem Gedächtnis der KI.

Die KI-Firmen sollen sich um Sprache kümmern, die Bausoftware um das Ingenieurwesen. Alle paar Monate kündigt jemand in unserer Branche einen eigenen Assistenten an. Ein eigener Chatbot bedeutet aber kein eigenes Sprachmodell. Die meisten maßgeschneiderten Assistenten laufen auf denselben kommerziellen Modellen, nur hinter einer eigenen Oberfläche. Die eigentliche Frage ist, wo die Ingenieurwerkzeuge angesiedelt sind, und MCP hält sie wiederverwendbar, ganz gleich, welche Oberfläche Ihr Team am Ende nutzt. Für den Einstieg über die KI-Plattformen, die Ihr Team bereits verwendet, spricht meist Folgendes:

1. Sie bekommen die leistungsfähigsten KI-Modelle, und die werden immer besser. Kein Ingenieurbüro und kein Anbieter von Bausoftware kann mit den Forschungsbudgets von Anthropic, Google, OpenAI oder Microsoft mithalten. Mit besseren Modellen werden in der Regel auch die Werkzeugauswahl und die Erklärung der Ergebnisse besser. Das geschieht aber nicht bei jedem Ablauf von selbst, testen Sie deshalb erneut, was Ihnen wichtig ist, wenn sich das KI-Modell ändert.
2. Ingenieure arbeiten schon dort. Viele Büros zahlen bereits für Microsoft 365 Copilot, ChatGPT, Claude oder Gemini. Ein neuer eigenständiger Chatbot ist ein weiterer Zugang, den nach der zweiten Woche niemand mehr nutzt. Wenn der KI-Assistent, für den Ihr Büro schon zahlt, die nötige Verbindung unterstützt, erscheint ein MCP-Server dort, wo die Leute ohnehin arbeiten.
3. Einmal bauen, überall einstecken. Derselbe Server lässt sich in Claude, ChatGPT, Gemini, Copilot und in KI-Assistenten wiederverwenden, die ein Büro selbst baut. Jede App braucht weiterhin ihre eigene Einrichtung der Verbindung, und nicht jedes Produkt unterstützt jede Funktion. Wechselt Ihr Büro aber den KI-Anbieter, müssen die Ingenieurwerkzeuge nicht neu gebaut werden. Sogar direkte Konkurrenten wie OpenAI, Google und Microsoft unterstützen den Standard.
4. Werkzeuge beginnen zusammenzuarbeiten. In einem Gespräch lässt sich das Modell abfragen, eine Berechnung starten, eine Tabelle füllen und das Ergebnis im Dokumentenmanagement ablegen. Ein solcher werkzeugübergreifender Ablauf brauchte früher für jeden Schritt ein eigenes Skript.
5. Ihr Fachwissen bleibt Ihres. Der Anbieter behält den validierten Solver, die Normnachweise und das Datenmodell. Die KI-Plattform liefert die Gesprächsebene obendrauf. Das Fachwissen bleibt der Wettbewerbsvorteil, und so soll es auch sein.

Es gibt einen sechsten, leiseren Vorteil. Die großen Plattformen bringen eine Unternehmensinfrastruktur mit, die ein kleines Werkzeug für das Bauwesen nie selbst bauen würde: Freigabe von Konnektoren durch Administratoren, Bestätigungsabfragen vor dem Ausführen eines Werkzeugs und Anmeldung über Standardprotokolle. In Microsoft 365 Copilot und Gemini Enterprise kann ein IT-Administrator zum Beispiel einen eigenen MCP-Server einmal für die gesamte Organisation registrieren.

Die richtige Frage ist nicht, ob Sie die KI in Ihr Modell lassen, sondern was sie dort tun darf. Das entscheidet Ihr Büro, nicht die KI. MCP macht die Grenze sichtbar, weil jeder Server genau angibt, welche Werkzeuge es gibt. Entscheidend ist, was diese Werkzeuge können und welche Berechtigungen dahinterstehen, nicht das Etikett auf dem Server.

Lesen. Die KI fragt Modelle und Daten ab: Sie listet die Feuerschutztüren eines Geschosses auf oder ruft die Eigenschaften eines einzelnen Elements ab. Lesezugriff begrenzt Änderungen am Modell. Er macht die Informationen nicht weniger sensibel, und er verhindert keine irreführende Antwort.

Prüfen. Die KI führt Prüfungen aus: eine IDS-Validierung, einen Kollisionsbericht, einen Vergleich zwischen Revisionen. IDS ist ein Standard von buildingSMART, der ausgewählte Informationsanforderungen in maschinenprüfbarer Form beschreibt. Sie legen fest, welche Elemente welche Daten brauchen, und ein Prüfwerkzeug prüft das Modell anhand dieser Regeln. Es prüft die Informationen, nicht, ob das Gebäude richtig geplant ist. Die Ergebnisse fließen in Entscheidungen ein, deshalb prüft sie ein Mensch.

Schreiben. Die KI ändert das Modell selbst: Sie füllt Parameter aus, verschiebt Elemente oder erstellt neue. Das braucht kontrollierte Berechtigungen, eine Prüfung jeder Änderung und eine Möglichkeit, sie rückgängig zu machen.

Die Revit-Server von Autodesk zeigen, wie Anbieter diese Grenzen ziehen. Der erste MCP-Server für Revit, im Juni als Technical Preview veröffentlicht, war schreibgeschützt. Im September hat Autodesk einen Trusted-Write-Server ergänzt, mit dem Sie jede Änderung eines Agenten prüfen können, sowie einen Experimental-Server mit weitergehenden Bearbeitungswerkzeugen, dessen Nutzung laut Autodesk auf eigenes Risiko erfolgt. Beide sind Technical Previews für Revit 2027. Für die meisten Büros ist Lesen der richtige Einstieg, und zwar an einem Testmodell, das das Büro freigegeben hat.

Um zu sehen, wie hoch die Hürde wirklich ist, habe ich einen schreibgeschützten MCP-Server für die Software zur Modellprüfung gebaut, die ich entwickle. Die Software prüft IFC-Modelle bereits gegen IDS-Anforderungen und vergleicht Modellversionen. Die Validierung selbst ist nicht neu; die Software konnte sie schon vorher. Neu durch den Server ist die Möglichkeit, Folgefragen zu stellen, die Schritte zu verbinden und direkt zu den betroffenen Elementen zu springen.

server.registerTool(
  "get_properties",
  {
    title: "Element properties",
    description:
      "Returns all property sets, quantities with units and the material " +
      "of one element. Use it to inspect an element found with list_elements.",
    inputSchema: z.object({
      version,
      guid: z.string().describe("IFC GlobalId of the element, 22 characters."),
    }),
    outputSchema: z.looseObject({
      summary: z.string(),
      guid: z.string(),
      property_sets: z.array(z.unknown()),
    }),
    annotations: { readOnlyHint: true, idempotentHint: true },
  },
  async ({ version, guid }) =>
    run("get_properties", { version, guid }, () =>
      elementProperties(catalog, version, guid),
    ),
);

Der Server heißt ifc-review und stellt sechs Werkzeuge bereit, alle schreibgeschützt:

• get_model_summary: Projekt, Versionen, Geschosse, Anzahl der Elemente
• list_elements: Elemente nach IFC-Klasse, Geschoss oder dem Merkmal „tragend“ finden
• get_properties: Eigenschaftssätze, Mengen und Materialien eines Elements
• run_ids_check: eine Version gegen eine IDS-Datei validieren
• compare_versions: was zwischen zwei Versionen hinzugefügt, entfernt oder geändert wurde
• get_viewer_link: ein Link, der den 3D-Viewer öffnet und die betreffenden Elemente hervorhebt

Dann habe ich den Test an einem echten Modell durchgeführt: dem Konzeptmodell eines Wohngebäudes in Prag mit einer Garage auf Straßenebene, drei Wohngeschossen und einem Dachgeschoss, geprüft gegen eine IDS-Datei mit 14 Informationsanforderungen. Ich habe gefragt, welche Anforderungen nicht erfüllt sind und welche Elemente betroffen sind. Zwei Anforderungen waren nicht erfüllt, betroffen waren 13 Elemente: zwei Dachfenster ohne U-Wert und elf Türen ohne Feuerwiderstandsklasse. Laut den Türbezeichnungen wird die Feuerwiderstandsklasse erst im Brandschutzkonzept festgelegt. Das erklärt, warum der Wert fehlt. Es liefert ihn aber nicht, und ob der Wert in dieser Phase erforderlich ist, entscheidet das Projektteam.

Für den Test habe ich dann eine zweite Revision vorbereitet, in der ein Teil der Lücken geschlossen war, und die Frage gestellt, die jedes Team nach einer Revision stellt: Was wurde behoben, und was fehlt noch? Die KI rief die Vergleichs- und Validierungswerkzeuge auf, und die Ergebnisse wurden über die Element-ID abgeglichen. Zehn der dreizehn Elemente waren behoben. Drei Türen im 3. Wohngeschoss hatten weiterhin keine Feuerwiderstandsklasse. Anschließend gab mir die KI einen Link, der das Modell mit genau diesen drei Türen hervorgehoben öffnete.

Die ganze Demo habe ich in zwei verschiedenen KI-Apps durchgespielt: in ChatGPT und in Gemini in Google Antigravity. In diesem Test kamen beide mit demselben Server und denselben Werkzeugen zu denselben Ergebnissen. Das heißt nicht, dass sich jede KI-App gleich verbindet; jedes Produkt hat seine eigene Einrichtung und eigene Grenzen. Aber der Server musste nicht wissen, welche KI fragt. Genau darum geht es bei einem Standard.

Den Code zu schreiben war der einfache Teil. Drei Dinge waren wichtiger:

• Werkzeugbeschreibungen sind die Benutzeroberfläche. Die KI wählt Werkzeuge, indem sie deren Beschreibungen liest, also verdienen sie dieselbe Sorgfalt wie Beschriftungen von Schaltflächen.
• Zusammenfassungen statt Datenberge. Geben Sie Anzahlen und die wichtigsten Ergebnisse zurück, Details auf Anfrage. Wer der KI ein ganzes Modell schickt, überlastet ihr Arbeitsgedächtnis und verschlechtert die Antworten.
• Einheiten und IDs, immer. Jede Zahl trägt ihre Einheit und jedes Element seine GUID. Wo es mehrdeutig wird, fängt die KI wieder an zu raten.

Nichts davon ersetzt das Prüfwerkzeug. Es lässt sich nur leichter befragen.

In weniger als zwei Jahren ist MCP von einem Experiment zu einer Funktion geworden, die große Anbieter von Bausoftware mit ihren Produkten ausliefern.

Anthropic hat den Standard im November 2024 veröffentlicht. Seitdem haben Anbieter von Bausoftware begonnen, MCP-Verbindungen auszuliefern, jede mit eigenem Umfang und eigenen Bedingungen:

• Revit (Autodesk): ein schreibgeschützter MCP-Server seit Juni, zu dem im September Trusted-Write- und Experimental-Server hinzukamen. Alle sind Technical Previews für Revit 2027.
• Revu (Bluebeam): verbindet sich über MCP mit Claude. Voraussetzung sind ein Bluebeam-Max-Abonnement, Revu 21.9 oder neuer und die Desktop-App von Claude.
• SketchUp (Trimble): ein Claude-Konnektor, der aus einem Gespräch neue SketchUp-Modelle erstellt. Bestehende Dateien kann er nicht bearbeiten, und Claude ist derzeit der einzige unterstützte KI-Anbieter.
• RFEM 6 (Dlubal Software): seit Januar 2026 ein MCP-Server in der Standardinstallation, der über die Dlubal API arbeitet. Details stehen im Knowledge-Base-Beitrag und in der API-Dokumentation von Dlubal.

Diese Produkte ändern sich schnell, prüfen Sie also die aktuellen Bedingungen, bevor Sie mit ihnen planen, und gehen Sie nicht davon aus, dass sich eines davon ohne Weiteres mit jeder KI-App verbindet.

Anbieter treffen auch unterschiedliche Designentscheidungen. Manche Server stellen wenige, eng gefasste Werkzeuge für bestimmte Zwecke bereit. Andere lassen die KI Skripte für die API des Programms schreiben, ähnlich wie ein Dynamo- oder Grasshopper-Skript, nur dass die KI es schreibt. Was möglich ist, hängt davon ab, was der Server freigibt und welche Berechtigungen dahinterstehen. Eng gefasste Werkzeuge geben allen sichere Standardeinstellungen; Skripting gibt erfahrenen Anwendern mehr Spielraum, um den Preis, dass sie den von der KI geschriebenen Code prüfen und testen müssen. Mein eigener Server steht klar am eng gefassten Ende.

Lang laufende Aufgaben, etwa eine große Berechnung oder eine aufwendige Modellprüfung, haben in MCP ein eigenes Muster: Tasks. Sie begannen als experimentelle Funktion, und die Spezifikation vom Juli 2026 hat sie in eine offizielle Erweiterung überführt. Sie helfen nur, wenn sowohl die KI-App als auch der Server sie umsetzen.

MCP beseitigt die Reibung zwischen dem fachlichen Urteil des Ingenieurs und seiner Umsetzung. Es ersetzt das Urteil nicht, und es bringt ein paar eigene neue Risiken mit.

• Die Verantwortung bleibt, wo sie ist. Der Einsatz von KI nimmt dem Ingenieur nicht die Verantwortung, das Ergebnis zu prüfen. Die KI unterschreibt keine Pläne, und wie die Haftung verteilt ist, ist eine Frage für Ihre Verträge und Ihre Rechtsberatung.
• Schlechte Daten rein, schlechte Ergebnisse raus, nur schneller. MCP automatisiert einen chaotischen Prozess genauso treu wie einen geordneten. Uneinheitliche Parameter und fehlende Klassifikationscodes (UniFormat, OmniClass) tauchen früher auf, sie verschwinden nicht.
• Von der KI geschriebener Code muss geprüft werden. Wenn ein Server Skripte ausführt, die die KI schreibt, kann die KI auch ein fehlerhaftes schreiben. Prüfen Sie den Code, testen Sie an einer Kopie und halten Sie Berechnungsergebnisse unter Versionskontrolle.
• Wissen Sie, wohin die Daten gehen. Ein lokaler Server hält das Modell auf Ihrem Rechner, aber der KI-Host sieht weiterhin alles, was die Werkzeuge zurückgeben, und Lesezugriff ändert daran nichts. Prüfen Sie die Bedingungen Ihres KI-Anbieters zu Datenspeicherung und Training, bevor Sie laufende Projekte anbinden.
• Modelldaten können Anweisungen enthalten. Ein Eigenschaftswert oder ein Kommentar in einem Dokument kann Text enthalten, der versucht, die KI zu steuern. Lesezugriff begrenzt Änderungen am Modell; er verhindert weder irreführende Antworten noch den Abfluss von Daten. Beginnen Sie mit einem vertrauenswürdigen Server, eingeschränktem Zugriff und einem Testmodell, das Ihr Büro freigegeben hat.
• Es ist nicht umsonst. Planen Sie Budget für KI-Abonnements, API-Zugang oder Zusatzlizenzen auf der Softwareseite und für ausreichend leistungsfähige Workstations ein.

So starten Sie am Montag

Fangen Sie klein an: ein Projekt, eine Aufgabe nur mit Lesezugriff, eine neugierige Person. Stellen Sie vorher Ihren Softwareanbietern fünf Fragen:

Starten Sie dann ein Pilotprojekt. Wählen Sie eine wiederkehrende Aufgabe und ein Testmodell, das Ihr Büro freigegeben hat, etwa die Prüfung einer Modellrevision anhand der Informationsanforderungen des Projekts. Vergleichen Sie Ihren heutigen Ablauf, einschließlich eines Prüfwerkzeugs, das Sie bereits nutzen, mit der KI-gestützten Variante. Erfassen Sie neben der eingesparten Zeit auch den Prüfaufwand, übersehene Probleme und Fehlalarme, und wiederholen Sie das an einer weiteren Revision, bevor Sie entscheiden. Dieser Vergleich sagt Ihnen mehr als jede Demo eines Anbieters.

MCP plant kein Gebäude. Es lässt die KI aber an die Werkzeuge heran, die die Ingenieurarbeit schon erledigen, sodass die Stunden zwischen einer Frage und ihrer Antwort schrumpfen.

Stellen Sie sich den nächsten Schritt vor. Eine Steckdose findet die Elemente, die sich in der letzten Modellrevision geändert haben. Eine zweite schickt sie weiter an das nächste Werkzeug, ein Berechnungsprogramm oder eine Koordinationsplattform, sofern die Modelle und ihre Element-IDs verknüpft sind, was nach wie vor einer der schwierigsten Teile der Arbeit ist. Die KI verbindet die Schritte und legt das Ergebnis der Person vor, die entscheidet. Die Bausteine gibt es heute schon; jeder Schritt braucht aber weiterhin jemanden, der das Ergebnis prüft.

Die Bausoftware, auf die wir uns verlassen, ist stark in der Ingenieurarbeit. Die KI-Plattformen sind stark in Sprache und logischem Denken. MCP ist die Steckdose dazwischen, und es lohnt sich, zu verstehen, wie es funktioniert, bevor Ihre Wettbewerber es tun.

Meine Sicht: Wenn KI-Modelle Baudaten bekommen, lernen sie unsere Arbeit besser kennen, und ich vertraue diese Daten den großen US-Anbietern an. Welche Regeln für ein Projekt gelten, bestimmen aber weiterhin Ihre Verträge. In ein paar Jahren wird es so selbstverständlich sein, der KI Fragen zum Modell zu stellen, wie etwas zu googeln.

Lieber hören? Zu diesem Beitrag gibt es eine Folge des Insights-Podcasts (auf Englisch), die auf demselben Test aufbaut.

Insights-Podcast · EP 02 · 14:05

Hören Sie das Gespräch

Martin und Co-Moderatorin Sarah gehen diesen Artikel an einem Praxisfall durch, auf Englisch.

Folge abspielen Alle Folgen →

Kapitel

1. 0:00The doors that don't exist
2. 0:21Welcome
3. 0:57An outlet, not a brain
4. 2:19Guessing vs. checking
5. 3:49"Have you actually tried it?"
6. 5:36Thirteen elements, three doors
7. 6:52One server, two AI apps
8. 8:03"Why give our data to big tech?"
9. 9:25The weekend GitHub server
10. 10:50Who's actually shipping this?
11. 11:43What do I tell my boss?
12. 13:09Close

TranskriptSynchron zum Audio

MartinImagine asking an AI which doors are missing a fire rating. It gives you a perfect table. There's just one problem: none of those doors exist in your model.0:00 SarahThen how do you get an answer you can actually check?0:11 MartinWelcome back to Insights. I'm Martin Motlík. I work where software meets structural engineering. Today we're looking at the Model Context Protocol, or MCP, through a model-review test I built myself.0:21 MartinSarah is back as our fictional marketing lead at an engineering firm in Portland. Her boss has a question.0:36 SarahHe's forwarded another vendor email: "Should we be doing this MCP thing?" I need an answer I can take back to the team.0:43 MartinLet's work through it. What can it do, what still needs checking, and where would you start?0:51 SarahOkay, start from zero. What is it?0:57 MartinMCP is an open standard that lets AI apps connect to the software and data you already use. It doesn't make the AI smarter. It gives it a way to reach things outside itself. Your models, your analysis software, your project data.1:00 SarahSo, a plug.1:17 MartinPretty much. Picture the temporary power spider box on a jobsite. It doesn't care if you plug in a saw, a grinder or a work light, because every tool has the same plug. Before MCP, connecting an AI to a program meant custom wiring for every single pair.1:18 SarahAnd now?1:35 MartinNow software can expose its tools through an MCP server, and compatible AI apps can connect to it. You still need the right connection and permissions. Anthropic introduced the standard in late 2024.1:36 SarahWe pay for Copilot. So in that picture, Copilot is...1:49 MartinThe host. The app you type into. On the other side, a small server sits next to Revit, or next to the tool that reads your IFC files, and tells the AI what it can do.1:54 SarahTells it how?2:05 MartinEach tool has a description and a structured definition of its inputs. The AI uses those to choose a tool and supply the information it needs. The application controls which tools are available.2:06 SarahSo back to the doors. What would have been different?2:19 MartinThe AI would have a way to query the actual model. A tool can open the IFC file, find the doors and return their properties. We can check those results. The AI can still choose the wrong filter or misread an answer, so the connection alone doesn't make it reliable.2:22 SarahSo the AI is more of a coordinator.2:41 MartinExactly. Like a good BIM coordinator, actually. It doesn't author the model. It knows where to look, and it brings back the answer.2:44 SarahBut here's the thing. Copilot already reads our documents. Our BIM Execution Plan, our standards. Isn't that the same?2:53 MartinThat's a different tool, and a good one. The AI searches documents and quotes them. It answers "what does the BIM Execution Plan say?"3:01 SarahAnd MCP?3:10 MartinMCP can connect both kinds of tools. One searches your documents; another queries the model or runs a check. The useful difference is what the tool can do. Most serious workflows will use both.3:12 SarahGive me something real. What would our team actually ask?3:25 MartinFind the doors on level two with a missing fire-rating property, and show me where they are. Or total the concrete quantities in the slabs, floor by floor, if the model contains reliable quantities. Those are questions the connected tools can answer.3:29 SarahAnd the doors would have been real doors.3:45 SarahCan I be honest? Everything I read about this is a vendor demo. Have you actually tried it yourself?3:49 MartinI have. I'm building a model-review prototype, a web app for IFC models. It already checks models against information requirements and compares versions. So I wrote a small MCP server for it. Six tools, all read-only.3:56 SarahRead-only meaning...4:13 MartinIt can look, it can't touch. List elements, read their properties, run a check, compare two revisions, and hand me a link into the 3D viewer. That's it.4:15 SarahBut couldn't your model checker already do that without AI?4:26 MartinYes. The checker already did the validation. What I added was a way to ask follow-up questions, connect the steps, and jump straight to the affected elements.4:29 SarahAnd what did you test it on?4:39 MartinA real model. A residential building in Prague, a concept model with a garage, three apartment floors and an attic. Plus an IDS file with the project's data requirements.4:41 SarahIDS. Remind me?4:53 MartinIDS is a buildingSMART standard for expressing selected information requirements in a machine-checkable form. You specify which elements need which data. A checker then tests the model against those rules. It checks the information, not whether the building is correctly designed.4:56 SarahOh. That's literally what our BIM coordinator does every Friday before a submittal. By hand.5:14 MartinThen she'll like this part. I asked: check the model against the IDS file. Which requirements fail, and which elements are affected? Two requirements failed. Thirteen elements, mostly doors without a fire rating.5:21 SarahDoors with no fire rating. That sounds bad.5:36 MartinThe door names said the fire rating would be set in the fire safety design. That explained why the value was missing. It didn't actually provide a fire rating.5:40 SarahSo the check found a real gap, but it didn't tell you whether the design was wrong.5:50 MartinExactly. You also need to know whether that information is required at this project stage. The check flags the missing value. A person decides what it means.5:55 SarahThen what?6:06 MartinThen I prepared a second revision for the test, with some of the gaps filled in. And I asked the question every team asks after a revision: what got fixed, and what's still missing? Show me the rest in the model.6:07 SarahAnd?6:21 MartinThe AI called the comparison and validation tools, and the results were matched by element ID. Ten of thirteen fixed. Three doors on residential level three still without a fire rating. Then it gave me a link that opened the model, and there they were. Three doors highlighted, the rest of the building dimmed.6:22 SarahSo the doors in the chat and the doors on screen are the same doors.6:41 MartinSame element IDs. That's the part I'd show any project team first.6:46 SarahOkay, but which AI did you use? We're a Copilot shop.6:52 MartinI tested the same server with ChatGPT and with Gemini in Google Antigravity. In that test, both reached the same findings. That doesn't mean every AI app connects in the same way. With Copilot, you need to check the specific product and your company's setup.6:57 SarahWas building the server the hard part?7:15 MartinWriting the code wasn't the hard part.7:17 SarahWhat was?7:19 MartinThree things. First, the tool descriptions. The AI picks tools by reading them, so they're really the user interface. They deserve the same care as button labels.7:20 SarahCopywriting. Finally something in my lane.7:31 MartinHonestly, yes. Second, summaries beat data dumps. Return counts and the top results, with details on request. Send an AI a whole model and you overload its working memory. The answers get worse.7:35 SarahAnd third?7:50 MartinUnits and IDs, always. Every number carries its unit, every element its ID. Ambiguity is exactly where the AI starts guessing again.7:51 SarahHere's where I push back a bit. Why would we connect our projects to OpenAI or Google or Microsoft? Wouldn't it be safer to build our own chatbot?8:03 MartinFair question. Let me separate two things: where the model lives, and where the answers go. A local server keeps the model file on your machine. Only what the tools return goes to the AI.8:13 SarahWhich can still be a lot.8:27 MartinIt can. So check your provider's terms on data retention and training before you connect live projects. And some clients and contracts don't allow commercial AI services at all. Then you don't.8:29 SarahOkay. And the chatbot idea?8:43 MartinBuilding your own chatbot doesn't mean building your own language model. You can use the same commercial models behind a custom interface. The question is whether that interface solves a real problem for your team. MCP lets you reuse the engineering tools either way.8:45 SarahAnd my engineers already have Copilot open all day.9:03 MartinThen it makes sense to start with the interface they already use, if it supports the connection you need. A custom assistant may still be useful for a specific workflow.9:07 SarahSo it's not either-or.9:17 MartinNo. Keep the engineering tools reusable, then choose the interface that works for your team.9:19 SarahOkay, confession number two. One of our younger engineers found a community Revit server on GitHub and hooked it up to ChatGPT over the weekend. On a live project.9:25 MartinOf course he did.9:38 SarahOur IT guy is not amused.9:39 MartinYour IT guy has a point. I separate three kinds of access. First, reading: querying the model and pulling properties. That limits changes to the model, but the information can still be sensitive.9:42 SarahAnd the second?9:56 MartinChecking: IDS checks, clash reports, comparisons between revisions. People need to review the findings because they inform decisions. Third is writing: changing parameters or moving and creating elements. That needs controlled permissions and a way to review and undo changes.9:57 SarahAnd the GitHub server?10:16 MartinYou need to inspect what that particular server can do and what access it has. Autodesk now offers separate read, write and experimental server options as technical previews. The capabilities and permissions matter more than the label.10:18 SarahAnything else I should tell IT?10:32 MartinModel data can contain text that tries to steer the AI. Read-only limits changes to the model; it doesn't prevent misleading answers or data exposure. Start with a trusted server, restricted access and a test model your firm has approved.10:34 SarahWho is actually shipping this in our industry?10:50 MartinAutodesk has Revit servers in technical preview. Bluebeam connects Revu with Claude. Trimble has a SketchUp connector, and Dlubal provides access to its analysis applications. The capabilities, supported clients and licenses differ. But these are actual products you can evaluate.10:53 SarahDo they all give the AI the same kind of access?11:14 MartinNo. Some expose a few defined actions. Others let the AI write scripts against an API. The reach depends on what the server exposes and the permissions behind it.11:17 SarahWhich would you start with?11:29 MartinA small set of read-only tools for one task. Scripting can go further, but you need to review and test the code. I've linked the product details in the article, because those are changing quickly.11:31 SarahOkay. That email from my boss. And our senior engineer asked me to ask you one thing: who's liable if the AI gets it wrong?11:43 MartinUsing AI doesn't remove the engineer's responsibility to review the result. The AI doesn't stamp drawings. How liability is allocated is a separate question for the firm's contracts and legal advice.11:53 SarahSo we still need a review process. What else do I write back?12:07 MartinThat it won't clean up your data. It automates a messy process just as faithfully as a clean one. If your parameters are inconsistent, you'll just find out faster. And that it isn't free. AI subscriptions, and sometimes API access or add-on licenses on the software side.12:12 SarahAnd then?12:30 MartinThen a few questions for every vendor. Do you ship an MCP server, official or community? Is it read-only, and are read and write separated? Where does project data go? The full list is in the article.12:31 SarahAnd how do we know if it's worth it?12:44 MartinChoose one recurring task and a test model your firm has approved. Compare your current workflow, including any checker you already use, with the AI-assisted version. Count the review time, missed issues and false alarms as well as the time saved. Repeat it on another revision before deciding.12:46 SarahThat's our Friday model check.13:04 MartinThat's your Friday model check.13:06 SarahIf you had to sum it up in one sentence?13:09 MartinMCP lets AI reach the engineering tools we already use. We still need to verify the result.13:12 SarahAnd personally? Would you share your own models with these AI companies?13:20 MartinI would. Sharing building data with AI models is how they get better at our work, and I trust the large U.S. providers with it. Your contracts still set the rules for each project. In a few years, asking an AI about a model will be as ordinary as searching Google.13:24 SarahAnd the first question to take back to the office?13:41 MartinPick one question you ask about a model every week. Check whether your existing software can expose the answer, and how your team would verify it.13:44 SarahIn the article, you can see the tool result and the same three doors highlighted in the model. It's on martinmotlik.com, under Insights.13:53 MartinThanks for listening. See you in the next one.14:01

Folge mit KI-Stimmen aus diesem Artikel produziert. Skript von Martin geprüft.

Martin Motlík

Unabhängiger AEC-Digitalstratege und Leiter Web-Content bei Dlubal Software. Schreibt über KI, BIM und Marketing für Ingenieursoftware.

Weiterlesen

KI im Bauwesen Werden Sie zur Quelle: AEC-Daten fit für die KI-Suche machen 6. Oktober 2026 · 8 Min. Lesezeit · Podcast 14 min

Alle Beiträge →