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 eigentlich in 30 Sekunden beantwortbar sein sollte.

Genau dieses Problem adressiert das Model Context Protocol – kurz MCP. Und es könnte für FM-Konzerne relevanter werden, als die meisten heute ahnen.

Was MCP ist – und was es von einer normalen API unterscheidet

MCP ist ein offener Standard, entwickelt von Anthropic und seit Ende 2024 als Open-Source-Protokoll verfügbar. Das Grundprinzip: MCP schafft eine einheitliche Schnittstelle zwischen KI-Anwendungen und beliebigen Datenquellen. Statt für jedes System eine eigene Integration zu programmieren, sprechen alle Systeme das gleiche Protokoll.

Die Architektur besteht aus drei Komponenten: Der MCP-Host ist die KI-Anwendung, mit der der Nutzer interagiert – zum Beispiel 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.

Der entscheidende Unterschied zu klassischen API-Integrationen: Bei einer REST-API muss der Entwickler vorher genau wissen, welche Daten er abrufen will, und für jeden Anwendungsfall eine eigene Abfrage programmieren. MCP funktioniert anders. Der Server beschreibt seine Fähigkeiten selbst – welche Daten er liefern kann, welche Aktionen er unterstützt – und die KI entscheidet zur Laufzeit, welche Informationen sie braucht. Das ist ein fundamentaler Unterschied, weil es die starre Vorprogrammierung 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 verschiedene Kernsysteme: CAFM für Flächen- und Anlagenverwaltung, 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, plus diverse Excel-Listen und Spezialanwendungen.

Diese Systeme sind historisch gewachsen, von verschiedenen Anbietern, mit verschiedenen Datenmodellen. Sie zu integrieren ist der Dauerbrenner jeder FM-IT-Abteilung. Klassische Integrationen – ob Middleware, ETL-Strecken oder Punkt-zu-Punkt-APIs – sind teuer, wartungsintensiv und bei jeder Systemaktualisierung fragil.

MCP bietet einen anderen Ansatz: Statt alle Systeme miteinander zu verbinden, verbindet man jedes System einmal mit MCP. Die KI wird zur Integrationsschicht – sie kann jedes angebundene System befragen, Informationen kombinieren und dem Nutzer eine konsolidierte Antwort geben.

Ein konkretes MCP-Konzept für FM

Wie könnte eine MCP-Architektur in einem FM-Konzern aussehen? Hier ein Konzept, das auf realen Systemlandschaften basiert:

MCP-Server 1 – CAFM-Anbindung (z.B. Archibus, planon, TRIRIGA): Zugriff auf Stammdaten: Anlagen, Standorte, Flächen, Wartungspläne. Die KI kann Fragen stellen wie: „Welche Anlagen am Standort Hamburg stehen im nächsten Quartal zur Wartung an?” Technisch umgesetzt ü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 – ERP-Anbindung (z.B. SAP): Zugriff auf Kostendaten, Bestellungen, Verträge, 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 – Ticketsystem (z.B. ServiceNow, JIRA Service Management): Zugriff auf Störmeldungen, Serviceaufträge, Reaktionszeiten, Lösungsquoten. Die KI kann analysieren: „Welche Anlagentypen verursachen die meisten Wiederholungsstörungen?” Hier gibt es bereits Community-MCP-Server für gängige Ticketsysteme.

MCP-Server 4 – Gebäudeleittechnik und IoT: Zugriff auf 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 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 – Dokumentenmanagement: Zugriff auf Verträge, Wartungsanleitungen, Prüfprotokolle, 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 über einen Filesystem-MCP-Server kombiniert mit RAG für die inhaltliche Suche.

Wann MCP Sinn macht – und wann nicht

MCP ist kein Allheilmittel, und es ist wichtig, die Grenzen ehrlich zu benennen.

MCP macht Sinn wenn: ihr fünf oder mehr Systeme betreibt, die heute nicht oder schlecht miteinander kommunizieren. Wenn eure Mitarbeiter regelmäßig Informationen aus mehreren Quellen manuell zusammenführen müssen. Wenn ihr KI-Anwendungen plant, die auf Daten aus verschiedenen Systemen zugreifen sollen. Und wenn ihr perspektivisch flexibel bleiben wollt – MCP vermeidet Vendor-Lock-in, weil es ein offener Standard ist.

MCP macht weniger Sinn wenn: ihr nur zwei bis drei Systeme integrieren wollt – da ist eine direkte API-Integration einfacher und schneller. Wenn eure Systeme bereits über eine funktionierende Middleware verbunden sind. Oder wenn ihr keine KI-Anwendungen plant, denn MCP ist primär als Schnittstelle zwischen KI und Datenquellen gedacht.

Noch ein ehrlicher Punkt: MCP ist Stand heute ein junges Protokoll. Die Spezifikation entwickelt sich weiter, das Ökosystem wächst, aber es ist noch nicht so ausgereift wie etablierte Integrationsstandards. Für einen FM-Konzern bedeutet 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 ermöglicht feingranulare Zugriffssteuerung: Jeder MCP-Server kann eigene Authentifizierung und Autorisierung implementieren. Der Objektleiter sieht nur die Daten seiner Standorte, der Controller sieht die Kostendaten, der Techniker die Wartungshistorien.

Wichtig ist dabei ein zentrales MCP-Server-Registry: Eine interne Übersicht, welche MCP-Server existieren, welche Daten sie bereitstellen und wer Zugriff hat. Ohne dieses 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 die gleichen Regeln wie bei jeder anderen Schnittstelle: Datenminimierung, Zweckbindung, Löschkonzept.

Mein Fazit: Beobachten, vorbereiten, pilotieren

MCP hat das Potenzial, die Art, wie FM-Konzerne ihre Datensilos überbrücken, grundlegend zu verändern. Statt teurer Punkt-zu-Punkt-Integrationen eine flexible, KI-native Schnittstelle. Statt starrer Abfragen dynamische Interaktion über Systemgrenzen hinweg.

Aber wir sind noch früh. Mein Rat: Identifiziert 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 eure Dokumentenablage. Testet, ob die Qualität der Antworten euren Anforderungen genügt. Und dann entscheidet, ob und wann ihr skaliert.

Die FM-Unternehmen, die jetzt anfangen, MCP zu verstehen und zu testen, werden in zwei bis drei Jahren einen echten Vorsprung haben – nicht weil sie die neueste Technologie haben, sondern weil sie ihre Daten endlich systemübergreifend nutzbar machen.

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