MCP im FM-Konzern: Wie ein offenes Protokoll Datensilos überbrücken kann

Stellt euch vor, ihr fragt eure KI: „Zeig mir alle Kälteanlagen an Standort München, die in den letzten sechs Monaten mehr als drei ungeplante Ausfälle hatten, samt Wartungshistorie und aktuellem Vertragsstatus.” Heute braucht ihr dafür drei Systeme: das CAFM für die Anlagendaten, das Ticketsystem für die Ausfallhistorie und das ERP für den Vertragsstatus. Drei Logins, drei Exporte, eine Excel-Tabelle zum Zusammenführen. Zwei Stunden Arbeit für eine Frage, die in 30 Sekunden beantwortbar sein sollte.

Dieses Problem adressiert das Model Context Protocol, kurz MCP. Für FM-Konzerne könnte es relevanter werden, als die meisten heute ahnen.

Was MCP ist und was es von einer normalen API unterscheidet

MCP ist ein offener Standard, den Anthropic entwickelt hat und der seit Ende 2024 als Open-Source-Protokoll verfügbar ist. Er schafft eine einheitliche Schnittstelle zwischen KI-Anwendungen und beliebigen Datenquellen. Statt für jedes System eine eigene Integration zu programmieren, sprechen alle Systeme dasselbe Protokoll.

Die Architektur hat drei Komponenten. Der MCP-Host ist die KI-Anwendung, mit der der Nutzer arbeitet, etwa Claude Desktop oder eine eigene WebApp. Der MCP-Client stellt die Verbindung zu einem bestimmten System her. Der MCP-Server sitzt vor der Datenquelle und macht deren Inhalte für die KI zugänglich, seien es Datenbanken, APIs, Dateisysteme oder Sensordaten.

Bei einer REST-API muss der Entwickler vorher genau wissen, welche Daten er abrufen will, und für jeden Anwendungsfall eine eigene Abfrage programmieren. Bei MCP beschreibt der Server seine Fähigkeiten selbst, also welche Daten er liefern kann und welche Aktionen er unterstützt, und die KI entscheidet zur Laufzeit, welche Informationen sie braucht. Starre Vorprogrammierung wird so durch dynamische Interaktion ersetzt.

Warum das für FM-Konzerne relevant ist

Die FM-Systemlandschaft ist ein Paradebeispiel für das Problem, das MCP löst. Ein typischer FM-Konzern betreibt fünf bis zehn Kernsysteme: ein CAFM für Flächen- und Anlagenverwaltung, ein ERP (oft SAP) für Finanzen und Beschaffung, ein Ticketsystem für Störmeldungen und Serviceaufträge, eine Gebäudeleittechnik für Sensordaten und Steuerung, Dokumentenmanagementsysteme für Verträge und Wartungsanleitungen, dazu diverse Excel-Listen und Spezialanwendungen.

Diese Systeme sind historisch gewachsen, stammen von verschiedenen Anbietern und haben verschiedene Datenmodelle. Sie zu integrieren ist der Dauerbrenner jeder FM-IT-Abteilung. Klassische Integrationen über Middleware, ETL-Strecken oder Punkt-zu-Punkt-APIs sind teuer, wartungsintensiv und bei jeder Systemaktualisierung fragil.

MCP geht anders vor: Man verbindet jedes System einmal mit MCP, statt alle Systeme miteinander zu verbinden. Die KI wird zur Integrationsschicht, befragt jedes angebundene System, kombiniert die Informationen und gibt dem Nutzer eine konsolidierte Antwort.

Ein konkretes MCP-Konzept für FM

So könnte eine MCP-Architektur in einem FM-Konzern aussehen. Das Konzept basiert auf realen Systemlandschaften.

MCP-Server 1 bindet das CAFM an (z. B. Archibus, planon, TRIRIGA) und liefert Stammdaten: Anlagen, Standorte, Flächen, Wartungspläne. Die KI kann fragen: „Welche Anlagen am Standort Hamburg stehen im nächsten Quartal zur Wartung an?” Technisch läuft das über den PostgreSQL-MCP-Server, wenn das CAFM eine relationale Datenbank nutzt, oder über einen Custom-MCP-Server, der die CAFM-API anspricht.

MCP-Server 2 bindet das ERP an (z. B. SAP) und liefert Kostendaten, Bestellungen, Verträge und Lieferanten. Die KI kann abfragen: „Wie hoch waren die ungeplanten Instandhaltungskosten an Standort München im letzten Quartal?” Die Umsetzung erfolgt über einen REST-API-Adapter, der SAP-Schnittstellen in MCP übersetzt.

MCP-Server 3 bindet das Ticketsystem an (z. B. ServiceNow, JIRA Service Management) und liefert Störmeldungen, Serviceaufträge, Reaktionszeiten und Lösungsquoten. Die KI kann analysieren: „Welche Anlagentypen verursachen die meisten Wiederholungsstörungen?” Für gängige Ticketsysteme gibt es bereits Community-MCP-Server.

MCP-Server 4 bindet Gebäudeleittechnik und IoT an und liefert Sensordaten: Temperaturen, Verbräuche, Betriebsstunden, Alarme. Die KI kann korrelieren: „Gibt es einen Zusammenhang zwischen der Außentemperatur und den Störmeldungen an der Kälteanlage Gebäude C?” Technisch ist das anspruchsvoller, weil BMS-Systeme oft proprietäre Protokolle nutzen. Hier braucht es einen Custom-MCP-Server mit BACnet- oder OPC-UA-Anbindung.

MCP-Server 5 bindet das Dokumentenmanagement an und liefert Verträge, Wartungsanleitungen, Prüfprotokolle und Gefährdungsbeurteilungen. Die KI kann suchen: „Zeig mir die Wartungsanleitung für die Aufzugsanlage in Gebäude A und den aktuellen TÜV-Bericht.” Umsetzbar ist das mit einem Filesystem-MCP-Server in Kombination mit RAG für die inhaltliche Suche.

Wann MCP Sinn macht und wann nicht

MCP ist kein Allheilmittel, und die Grenzen gehören dazu.

MCP lohnt sich, wenn ihr fünf oder mehr Systeme betreibt, die heute nicht oder schlecht miteinander kommunizieren. Es lohnt sich, wenn eure Mitarbeiter regelmäßig Informationen aus mehreren Quellen manuell zusammenführen oder wenn ihr KI-Anwendungen plant, die auf Daten aus verschiedenen Systemen zugreifen sollen. Und es hilft, flexibel zu bleiben, denn als offener Standard vermeidet MCP Vendor-Lock-in.

Weniger sinnvoll ist MCP, wenn ihr nur zwei bis drei Systeme integrieren wollt, da ist eine direkte API-Integration einfacher und schneller. Ebenso, wenn eure Systeme bereits über eine funktionierende Middleware verbunden sind oder wenn ihr keine KI-Anwendungen plant, denn MCP ist primär eine Schnittstelle zwischen KI und Datenquellen.

MCP ist Stand heute ein junges Protokoll. Die Spezifikation entwickelt sich weiter, das Ökosystem wächst, aber ausgereift wie etablierte Integrationsstandards ist es noch nicht. Für einen FM-Konzern heißt das: Pilotprojekte ja, unternehmensweite Einführung eher 2027 als 2026.

Sicherheit und Governance

Für FM-Konzerne mit sensiblen Gebäude- und Kundendaten ist die Governance entscheidend. MCP erlaubt eine feingranulare Zugriffssteuerung, denn jeder MCP-Server kann eigene Authentifizierung und Autorisierung implementieren. Der Objektleiter sieht nur die Daten seiner Standorte, der Controller die Kostendaten, der Techniker die Wartungshistorien.

Wichtig ist ein zentrales MCP-Server-Registry, also eine interne Übersicht, welche MCP-Server existieren, welche Daten sie bereitstellen und wer Zugriff hat. Ohne Registry wachsen MCP-Server organisch und unkontrolliert, ein Sicherheitsrisiko, das man von Anfang an adressieren sollte.

Die Kommunikation zwischen MCP-Client und Server sollte verschlüsselt über TLS laufen, und alle Anfragen sollten geloggt werden. Für DSGVO-relevante Daten gelten dieselben Regeln wie bei jeder anderen Schnittstelle: Datenminimierung, Zweckbindung, Löschkonzept.

Mein Fazit: Beobachten, vorbereiten, pilotieren

MCP kann verändern, wie FM-Konzerne ihre Datensilos überbrücken. An die Stelle teurer Punkt-zu-Punkt-Integrationen tritt eine flexible, KI-native Schnittstelle, an die Stelle starrer Abfragen die dynamische Interaktion über Systemgrenzen hinweg. Wir sind allerdings noch früh.

Mein Rat: Sucht in eurem Unternehmen den einen Use Case, bei dem Mitarbeiter regelmäßig drei oder mehr Systeme abfragen müssen, um eine Entscheidung zu treffen. Baut dafür einen MCP-Prototyp, zum Beispiel mit einem PostgreSQL-MCP-Server für eure CAFM-Datenbank und einem Filesystem-MCP-Server für die Dokumentenablage. Testet, ob die Qualität der Antworten euren Anforderungen genügt, und entscheidet dann, ob und wann ihr skaliert.

Wer jetzt anfängt, MCP zu verstehen und zu testen, hat in zwei bis drei Jahren einen echten Vorsprung, weil er seine Daten dann systemübergreifend nutzen kann.

Hat euer Unternehmen schon mit MCP experimentiert? Oder steht ihr vor dem Problem fragmentierter Systemlandschaften? Ich freue mich auf den Austausch.