Mehr als Prompts: Wie MCP die Möglichkeiten von Automic Automation.AI erweitert

Ähnlich wie in der klassischen Automatisierung ist auch für den Einsatz der Automic KI der Zugriff auf externe Daten und Lösungen essenziell. Zu diesem Zweck hat sich das MCP (Model Context Protocol) innerhalb kurzer Zeit zu einem weit verbreiteten offenen Standard entwickelt. Der technische Ansatz ähnelt dem von Webservices: Auch hier werden Dienste für andere Lösungen bereitgestellt.

Die von MCP bereitgestellten Dienste können sowohl Daten liefern als auch verändern. Zudem teilt ein MCP nach der Konfiguration der Automation.AI eine Liste seiner Fähigkeiten mit. Somit erweitert jeder neu hinzugefügte MCP die Fähigkeiten der Automation.AI.

Dieses Bild zeigt den Aufbau eines MCP Servers.

MCP Server Automic

Die in dem Bild beschrieben MCP-Möglichkeiten (Capabilities) können in drei verschiedenen Konzepten ausgeführt sein:

Tools
führen Aktionen aus, sie erlauben auch die Definition von Übergabeparametern.

create_ticket(...)

Ressources

liefern adressierbare Informationen.

invoice://2026/12345

Prompts

stellen serverseitig definierte Prompt-/Workflow-Vorlagen bereit.

summarize_customer

Für den praktischen Einsatz in Automic eignen sich vor allem „Tools“. Letztendlich ist dies jedoch nicht relevant, da ein MCP der Automation.AI mitteilt, wie ein Dienst angesprochen werden muss.

Automation.AI kann externe Funktionen auf zwei grundsätzlich unterschiedlichen Wegen bereitstellen. Eine vorhandene REST-API kann über einen OpenAPI-Provider automatisch in MCP-Tools übersetzt werden. Alternativ kann Automation.AI eine Verbindung zu einem echten MCP-Server herstellen. Für solche MCP-Verbindungen werden STDIO, SSE und Streamable HTTP unterstützt.

automation.ai.mcp.openapi

Diese Variante kommuniziert mit dem MCP über HTTP. Sie bietet die Möglichkeit, zu definieren, welche der vom MCP zur Verfügung gestellten Tools verwendet werden können. Damit wäre diese Variante zu bevorzugen. Leider konnte ich keine Möglichkeit finden, wie eine Authentifizierung über Bearer Tokens konfiguriert werden kann. Übrigens wird diese Variante auch für die Automic-MCP-Anbindung eingesetzt.

spring.ai.mcp.client.streamable-http.connections

Die „streamable-http“-Variante erlaubt die Authentifizierung über Bearer-Tokens. Es ist jedoch nicht dokumentiert, wie die von den MCP zur Verfügung gestellten Tools eingegrenzt werden können. Ich hoffe, dass in zukünftigen Automation.AI-Versionen eine entsprechende Möglichkeit bereitgestellt wird.

spring.ai.mcp.client.stdio.connections

Bei der dritten Variante wird dieser direkt von Automation.AI gestartet. Dabei müssen der MCP und Automation.AI auf derselben Maschine abgelegt sein. Dieser MCP-Typ nennt sich „STDIO”, da die Kommunikation zwischen Automation.AI und dem MCP über „stdio” erfolgt, also lokal. Auch wenn es technisch möglich ist, darüber agentische KI-Assistenten wie Claude Code anzubinden, sollte davon abgesehen werden, da der KI-Assistent die Betriebssystem-Berechtigungen des Automation.AI Prozesses erbt. Gerade bei Tools, die Dateien verändern oder Programme starten können, sollte dieser Account daher möglichst restriktiv berechtigt sein.

Für die Konfiguration der MCPs in der application.properties habe ich einen der bekannten KI-Anbieter verwendet. Dabei ist es hilfreich, im Prompt zu erwähnen, dass es sich um eine Anbindung an Spring.AI im Automation.AI-Kontext handelt. Zudem habe ich eine exemplarische application.properties an meinen Prompt angehängt. So wurden mir die notwendigen Konfigurationseigenschaften geliefert. Die application.properties beinhaltet außerdem einige hilfreiche Beispiele.

Nachdem der MCP in der application.properties konfiguriert wurde, muss die Automation.AI-Komponenete neu gestartet werden, damit die Konfiguration wirksam wird.

Nach dem Neustart sollte in dem ‚logs‘ Verzeichnis die automation-ai.log überprüft werden, ob sich der neue MCP erfolgreich registriert hat.

Damit stehen die Funktionen des MCP nun auch Automation.AI zur Verfügung und können für die Automatisierung genutzt werden.

Um den neuen MCP dafür nutzen zu können, muss zuerst ein AI-Connection-Objekt definiert werden. Dieses erlaubt die Auswahl des MCP und dessen exportierten Tools. Damit bietet das Connection-Objekt die Möglichkeit, den Zugriff auf MCP-Tools durch AI-Jobs bewusst zu beschränken. Es ist sinnvoll, für einzelne Anwendungsfälle unterschiedliche Connection-Objekte zu definieren, da ein Analyse-Job nur auf Daten liefernde Tools, wie z. B. getReport oder listExecutions, zugreifen kann.

Die Definition der KI-Prompts erfolgt durch den AI-Job-Typ. Dort werden der User-Prompt und der System-Prompt definiert sowie das AI-Connection-Objekt hinterlegt.

Der System-Prompt dient zur Beschreibung der Rolle, die der KI-Job einnehmen soll. Dies beeinflusst den Stil und den Umfang der KI-Antwort. Die Antworten für einen Administrator fallen technisch detaillierter aus als die für einen Fachanwender, da dieser mehr an einer Lösung als an den technischen Details interessiert ist.

Innerhalb des AI-Jobs sind zwei weitere Eigenschaften von Interesse. Mit den „Konversationseinstellungen” wird festgelegt, ob es sich um eine eigenständige Anfrage handelt oder ob die Anfrage den Beginn oder einen Bestandteil einer Konversation darstellt. Innerhalb einer Konversation werden die Ergebnisse der vorherigen KI-Anfrage weiterverwendet. Dazu generiert der erste AI-Job eine Conversation ID und speichert sie in einer Automic Variable. Diese wird dann dem Folgejob entsprechend mitgegeben.

Mithilfe der AI-Ausgabe-Eigenschaft kann der Name einer Automic-Variable mit dem Ergebnis der Anfrage festgelegt werden. Das ist ein nettes Komfort-Feature. Es wird aber auch klassisch ein REP-Report erzeugt und es stehen weiterhin Pre- und Post-Scripts für die Vor- und Nachbearbeitung zur Verfügung.

Beim Festlegen des Connection-Objekts innerhalb der AI-Jobs gibt es eine weitere Möglichkeit, die Liste der verfügbaren MCP-Tools einzuschränken.

Damit ist der AI-Job fertiggestellt, da unter Job-Attribute nichts eingetragen werden muss.

Abschließend noch einige Worte zum Aufbau der KI-Prompts. Ein AI-Job besitzt dafür einen System- und einen User-Prompt. Im System-Prompt sollten die grundsätzliche Rolle, Regeln und Grenzen des Jobs beschrieben werden. Hier kann beispielsweise festgelegt werden, welche Aufgaben die KI übernehmen darf, was sie nicht tun soll und wie sie mit unklaren Situationen umgehen muss.

Der User-Prompt beschreibt dagegen die konkrete Aufgabe des jeweiligen Job-Laufs und enthält die dafür benötigten Informationen. Vereinfacht gesagt: Der System-Prompt definiert die Spielregeln, der User-Prompt den aktuellen Arbeitsauftrag.

Dabei gilt nicht unbedingt: Je ausführlicher der Prompt, desto besser. Viel wichtiger sind eindeutige Anweisungen, ein klar definiertes Ergebnis und möglichst wenig Interpretationsspielraum. Insbesondere sollte beschrieben werden, welches Ergebnisformat erwartet wird und was bei Fehlern oder fehlenden Informationen passieren soll.

Das Gleiche gilt für die verfügbaren MCP-Tools. Ein AI-Job sollte nur die Tools erhalten, die er für seine Aufgabe tatsächlich benötigt. Anders als bei der klassischen Automatisierung kann ein KI-Modell auch mal links und rechts schauen. Dieser Freiheitsgrad ist durchaus gewollt, muss bei produktiven Geschäftsprozessen aber bewusst begrenzt werden. Denn hier bleiben Zuverlässigkeit und Nachvollziehbarkeit wichtiger als Kreativität.