Ich habe bereits mit dem Model Context Protocol (MCP) gearbeitet, bevor es offiziell veröffentlicht wurde in IBM Maximo Application Suite (MAS) 9.2. Ich habe sogar meinen eigenen MCP-Server für MAS entwickelt, über den ich in einer Blog-Serie geschrieben habe (Das Problem bei der Kommunikation mit Maximo), um KI-Agenten mit Maximo Manage zu verbinden. Seitdem haben viele Mitglieder der Community nach Lösungen für Maximo-Teams gesucht.
‍

Die meisten Diskussionen drehen sich um die Einführung von MCP in MAS 9.2. Ich möchte hier jedoch erläutern, wie der MCP-Server funktioniert, wie seine Architektur aufgebaut ist und wie er KI-Agenten eine sichere Arbeit mit Maximo ermöglicht. Ich werde die wichtigsten Konzepte vorstellen und aufzeigen, was sie für Teams bedeuten, die MCP in ihren eigenen Maximo-Umgebungen einsetzen möchten.
‍

Wo sich der MCP-Server einfügt

Falls Sie meine Blog-Serie noch nicht gelesen haben und nicht wissen, was ein MCP ist, fasse ich es kurz zusammen.
‍

Der MCP-Server fungiert als Schnittstelle zwischen KI-Agenten und den Maximo Manage-APIs. In MAS 9.2 kann er den integrierten Asset Lifecycle Management (ALM) -Agenten bedienen – wobei sich ALM auf die KI-Komponenten bezieht, die innerhalb des AI Service bereitgestellt werden, sowie auf weitere KI-basierte Lösungen wie Insights, Reliability und mehr. ALM und die zugehörigen Ressourcen sind die eigentlichen KI-Dienste, die über MCP mit Maximo interagieren und intelligente Funktionen in der gesamten Suite bereitstellen.
‍

Es ist jedoch nicht auf diesen integrierten Agenten beschränkt. Es unterstützt auch externe Agenten, einschließlich kundeneigener Agenten oder anderer Agenten-Frameworks wie IBM Bob, Claude und OpenAI, sofern sie über die unterstützte Route und das Authentifizierungsmodell verbunden sind.
‍

Am einfachsten lässt es sich so zusammenfassen: Manage bleibt die zentrale Datenquelle, und der MCP-Server fungiert als Schnittstelle für Agenten zu ausgewählten Manage-Funktionen.
‍

Manage stellt bereits OpenAPI-Spezifikationen bereit. In MAS 9.2 nutzt der MCP-Server diese Spezifikationen, um zu erkennen, welche Funktionen als KI-Tools verfügbar sind. Manage verwaltet die Tool-Definitionen, und der MCP-Server fragt Manage regelmäßig nach Aktualisierungen ab. Standardmäßig erfolgt dieses Polling alle 10 Minuten, wobei das Intervall konfiguriert werden kann.
‍

Der Abfrageprozess verwendet ETags. Manage speichert ein eigenes ETag für Änderungen an den Tool-Spezifikationen. Der MCP-Server speichert ein ETag im Arbeitsspeicher. Wenn diese Werte voneinander abweichen, aktualisiert der MCP-Server seine Tool-Liste und ruft die aktuellen OpenAPI-Spezifikationen ab. Auf diese Weise werden Ergänzungen, Aktualisierungen und Entfernungen in den Tool-Katalog für Agenten übernommen.
‍

Die Tools verwenden zudem strukturierte Ein- und Ausgabedefinitionen. Die Präsentation verweist auf Pydantic-Ein- und -Ausgabeobjekte, die Agenten ein präziseres Schema vorgeben (ich habe dies bereits in The Operations Layer: From Discovery to Actionerwähnt). Das ist nicht nur ein Implementierungsdetail. Agenten arbeiten zuverlässiger, wenn sie einen eng gefassten, expliziten Vertrag erhalten, anstatt eine große API-Oberfläche bedienen zu müssen.

Sicherheit nach dem Maximo-Modell

Eine der besseren Designentscheidungen ist, dass MCP keine separate Sicherheitsumgebung neben Maximo schafft. Authentifizierung und Autorisierung erfolgen weiterhin über die gewohnten MAS- und Manage-Muster.
‍

Beim integrierten Agentenpfad sendet die Benutzeroberfläche ein x-access-token JWT mit der Tool-Anfrage. Der MCP-Server sendet dieses Token zur Authentifizierung an den Core IDP, empfängt den Benutzerkontext und leitet die Benutzer-ID an Manage weiter, wenn das Tool aufgerufen wird. Manage entscheidet weiterhin, ob der Benutzer die Aktion ausführen darf.
‍

Das bedeutet, dass ein berechtigter Benutzer nicht automatisch dazu berechtigt ist, jedes MCP-Tool aufzurufen. Wenn ein Benutzer ein Tool nicht aufrufen oder auf eine bestimmte KI-Konfiguration nicht zugreifen darf, gilt diese Einschränkung auch dann, wenn die Anfrage über MCP erfolgt.
‍

Für externe Agenten unterstützt MAS 9.2 die Authentifizierung über Maximo-API-Schlüssel oder JWT-Token. API-Schlüssel sind wahrscheinlich die gängige Wahl für Integrationsszenarien, bei denen ein einzelner Agent einen konsistenten Berechtigungssatz benötigt. JWT-Token sind sinnvoller, wenn der Agent im Namen verschiedener Benutzer agieren muss.
‍

Die interne Kommunikation zwischen MCP, Manage und Core erfolgt über MAS-Zertifikate. Es geht nicht darum, dass MCP Unternehmenskontrollen umgeht. Es bietet Agenten einen Zugang zu Maximo, während die gewohnten Kontrollmechanismen beibehalten werden.

Externe Agenten sind Teil des Konzepts

Der „Bring Your Own Agent“-Ansatz ist einer der interessantesten Aspekte dieser Version.
‍

Einige Kunden werden den integrierten ALM-Agenten von IBM nutzen. Andere haben bereits in eigene Agenten investiert oder bevorzugen ein hybrides Modell, bei dem sowohl IBM-Agenten als auch externe Agenten mit Maximo interagieren. Der MCP-Server unterstützt dieses breitere Modell – und das ist eine sehr spannende Entwicklung!
‍

Um einen externen Agenten anzubinden, benötigt der Kunde zwei Dinge: die extern zugängliche MCP-Route und eine Authentifizierungsmethode. Die Route wird automatisch über OpenShift bereitgestellt, und der Agent sendet je nach Authentifizierungsmuster entweder einen Maximo-API-Schlüssel oder einen x-access-token-Header.
‍

Das bedeutet, dass Maximo-Funktionen externen Agenten über ein Industriestandard-Protokoll zur Verfügung gestellt werden können, anstatt über eine individuelle Einzellösung. Für Kunden mit bestehenden KI-Plattformen ist dies wahrscheinlich einer der praktischsten Aspekte von MAS 9.2. Sie können ihre Agentenstrategie beibehalten und Maximo weiterhin als kontrolliertes System of Record nutzen.

MCP-Tools sind APIs, aber nicht jede API ist ein Tool

Ein interessanter Aspekt dieses Designs ist, dass alle MCP-Tools in Manage zwar REST-APIs sind, aber nicht alle Maximo-APIs auch MCP-Tools sind.
‍

Diese Unterscheidung ist wichtig. Maximo verfügt über eine sehr große API-Oberfläche. Diese einem Agenten vollständig zur Verfügung zu stellen, wäre aufwendig, fehleranfällig und riskant. Der Agent müsste zu viele Schemata verarbeiten, hätte zu viele mögliche Pfade und zu viele Gelegenheiten, eine falsche Wahl zu treffen.
‍

MCP-Tools bilden eine selektivere Ebene. Sie stellen Funktionen bereit, die für die Nutzung durch Agenten vorgesehen sind, ergänzt durch Beschreibungen, Schemata und Annotationen, die dem Agenten bei der Entscheidung helfen, wann und wie er diese aufrufen soll.
‍

MAS 9.2 unterteilt Manage MCP-Tools in fünf Hauptkategorien.

KI-Konfigurationstools

KI-Konfigurationstools basieren auf aktivierten KI-Konfigurationen in Manage. Zu den unterstützten Inferenztypen der installierten KI-Dienste gehören Klassifizierung, Ähnlichkeit, Assistent, Dokumentensuche und Condition Insight.
‍

Die Assistenten-Funktion ist besonders interessant, da sie als Bootstrap-Tool fungieren kann. Sie kann eine natürlichsprachliche Anfrage entgegennehmen und daraus ableiten, wie der REST-API-Aufruf aussehen muss. In manchen Fällen ist dieser Ablauf in zwei Tools unterteilt: eines zur Ableitung der API-Anfrage und eines zur Ausführung. Diese Trennung ermöglicht es dem Agenten, dem Benutzer den geplanten Schritt anzuzeigen, bevor er ihn tatsächlich ausführt.
‍

KI-Konfigurationstools nutzen eine Whitelist, die in der Tabelle MAXAICFGTOOL gepflegt wird. Sobald eine unterstützte KI-Konfiguration aktiviert ist, kann sie automatisch als Tool verfügbar gemacht werden. Dies unterscheidet sich von anderen Tool-Typen, bei denen ein expliziter Bereitstellungsschritt erforderlich ist.
‍

Beschreibungen sind hier von großer Bedeutung. Die Beschreibung der KI-Konfiguration wird zur Tool-Beschreibung, und der Agent nutzt diesen Inhalt, um zu entscheiden, ob das Tool zur Anfrage des Benutzers passt. Eine vage Beschreibung erschwert die Planung, während eine präzise Beschreibung dem Agenten eine bessere Orientierung bietet.

Objektstruktur-Tools

Objektstrukturen sind leistungsstark, ihre Schemata können jedoch sehr umfangreich sein. Eine Objektstruktur für Arbeitsaufträge, Anlagen oder Standorte kann zahlreiche Operationen und Felder enthalten. Das gesamte Schema an einen Agenten zu übergeben, ist für diese Aufgabe meist nicht sinnvoll. Ich bin beim Aufbau meines eigenen MCP-Servers selbst häufig auf Probleme mit dem Kontextfenster gestoßen.
‍

OS-Tools lösen dieses Problem, indem sie aus dem umfassenden Objektstrukturmodell spezifischere Tools ableiten. Anstatt den gesamten Funktionsumfang einer Anlagen-Objektstruktur offenzulegen, kann ein OS-Tool eine fokussierte Operation bereitstellen, wie etwa das Verschieben einer Anlage oder das Melden von Ausfallzeiten.

Skript-Tools

Automatisierungsskripte sind eine der gängigsten Methoden, mit denen Kunden und Partner Maximo erweitern. MAS 9.2 integriert dieses Erweiterungsmuster nun in das MCP-Modell.
‍

Skript-Tools folgen demselben allgemeinen Ansatz wie das Scripting für REST-APIs. Literale Skriptvariablen werden zum Request-Schema. Wenn das Skript strukturierte Ausgaben zurückgibt, kann über den Parameter responseBody ein Response-Schema hinzugefügt werden. Nur aktive Skripte werden als MCP-Tools bereitgestellt.  

Workflow-Tools

Workflow-Tools bieten Teams eine grafischere Möglichkeit, Geschäftsprozesse für Agenten bereitzustellen. Dies ist in Maximo-Szenarien nützlich, in denen wichtige Aktionen bereits als Workflows und nicht als Code modelliert sind.
‍

Unterstützt werden ausschließlich nicht-interaktive Workflows. Das bedeutet Workflows, die aus Knoten, Bedingungsknoten und Aktionen bestehen. Workflows, die auf Pop-up-Dialoge oder interaktive Abfragen angewiesen sind, sind in dieser ersten Version nicht enthalten.
‍

Das Request-Schema ist einfach: ein href-Element, das den Datensatz identifiziert, auf den der Workflow angewendet werden soll. Wie bei Skripten und OS-Tools kann dieser Datensatz aus einer vorherigen Assistentenabfrage stammen.
‍

Aktive und aktivierte Workflows können als MCP-Tools bereitgestellt werden, und ihre Beschreibungen tragen dazu bei, dass der Agent versteht, wann er sie einsetzen muss.

API-Route-Tools

Der letzte Tool-Typ sind API-Route-Tools. Dabei handelt es sich um von IBM bereitgestellte Tools, die hauptsächlich für administrative oder systemweite Funktionen gedacht sind und nicht für kundendefinierte Geschäftslogik.
‍

Ein Beispiel ist das API-Schema-Tool. Zukünftige Tools dieser Art könnten von IBM als systemweite Tools entwickelt werden, etwa ein Agent, der Fragen zu installierten Produkten, Add-ons, Branchenlösungen, Sprachen oder Upgrade-Informationen beantworten kann.

Für diese Kategorie gibt es keine Benutzeroberfläche zur Konfiguration durch Kunden. Kunden und Partner verfügen bereits über Skripting-, Workflow- und Objektstruktur-Tools für ihre eigenen Erweiterungen. API-Route-Tools sind eher als von IBM bereitgestellte Bausteine für Funktionen zu verstehen, die im Hintergrund ablaufen.

Ein Muss für jeden Tool-Typ

Bei allen Tool-Typen zeigt sich dasselbe Muster: Die Tool-Beschreibung ist das Handbuch, das der Agent liest.
‍

Das klingt einfach, ist aber wahrscheinlich der Punkt, an dem viele Implementierungen stehen oder fallen. Ein Agent benötigt nicht nur einen Endpunkt. Er muss wissen, wofür das Tool gedacht ist, wann es eingesetzt werden soll, welche Informationen es benötigt und welche Varianten es unterstützt.
‍

Es lohnt sich, bei Annotationen sorgfältig vorzugehen. Administratoren können ein Tool als schreibgeschützt oder destruktiv kennzeichnen, und der Agent kann diese Information nutzen, bevor er entscheidet, was als Nächstes zu tun ist. Wenn ein Tool nur Daten abruft, kann der Agent es als risikoarm einstufen. Wenn das Tool einen Datensatz ändert, einen Workflow startet oder ein Skript ausführt, hat der Agent einen guten Grund, innezuhalten und eine Bestätigung anzufordern. Die Annotation steuert zwar nicht jeden externen Agenten, gibt aber gut konzipierten Agenten eine klare Warnung, bevor sie handeln.
‍

Hier zahlt sich Maximo-Erfahrung nach wie vor aus. Die besten MCP-Tool-Kataloge entstehen nicht dadurch, dass man alles offenlegt. Sie entstehen durch die Auswahl der richtigen Vorgänge, die Bereitstellung präziser Schemata und das Verfassen von Beschreibungen, die wie Anweisungen von jemandem klingen, der den Prozess versteht.

Warum das für Maximo-Kunden nützlich ist

Beim MCP-Server in MAS 9.2 geht es nicht nur darum, Maximo um KI zu erweitern. Es geht darum, KI-Agenten ein kontrolliertes Betriebsmodell innerhalb von Maximo zu bieten.
‍

Ohne MCP muss ein Kunde, der einen Agenten mit Maximo verbinden möchte, entscheiden, wie viel der API-Oberfläche offengelegt werden soll, wie jede Aktion zu beschreiben ist, wie die Authentifizierung gehandhabt wird, wie Tool-Definitionen aktuell gehalten werden und wie verhindert wird, dass der Agent auf falsche Vorgänge zugreift. MCP verleiht diesen Anforderungen einen standardisierten Rahmen.
‍

Für Teams, die bereits KI-Konfigurationen nutzen, kann der Weg zur Tool-Bereitstellung automatisch erfolgen, sobald die Konfiguration aktiv und unterstützt ist. Für Teams mit ausgereiften Maximo-Anpassungen können Skripte und Workflows zu vom Agenten aufrufbaren Tools werden, ohne dass bewährte Erweiterungsmuster aufgegeben werden müssen. Für Teams, die ihre eigenen Agenten entwickeln, machen der externe Pfad sowie das Authentifizierungsmodell über API-Schlüssel oder JWT die Einbindung von Maximo in eine umfassendere KI-Architektur einfacher.
‍

Das Ergebnis ist eine praktische Brücke zwischen der bestehenden Geschäftslogik von Maximo und der neuen Agenten-Ebene. Das macht Governance nicht weniger wichtig. Im Gegenteil: Es macht eine gute Governance sichtbarer. Tool-Beschreibungen, Schemata, Berechtigungen und Annotationen werden zu einem Teil der Arbeitsplanung des Agenten.
‍

Das ist der richtige Weg. Unternehmens-Agenten brauchen mehr als nur Antworten. Sie benötigen begrenzte Aktionen, klare Verträge und einen Zugriff, der das System of Record respektiert. Der MCP-Server von MAS 9.2 bietet Maximo-Teams eine solide Grundlage für diese Art von agentenbasierter Arbeit.