Phillip Pham | 11 Min. Lesezeit | 20.06.2026
TL;DR
Ein MCP Server für OPC UA ist eine Brücke, die einem KI-Agenten Live-Maschinendaten als aufrufbare Tools zur Verfügung stellt — statt sie in einen Data Lake zu kippen. Wir bei Pexon (80 Mitarbeiter, Microsoft Partner) bauen diese Brücke in Python mit asyncua und dem MCP-SDK. Ergebnis: Ein Agent liest in unter zwei Wochen Sensorwerte direkt von der SPS.
Worum es hier geht und worum nicht
Die kurze Antwort: Es geht um die Anbindung, nicht um die Speicherung. Wenn du Maschinendaten historisieren, modellieren und über Jahre auswerten willst, gehört das in ein Lakehouse — dazu haben wir einen eigenen Artikel. Hier bauen wir das Gegenteil: einen Weg, auf dem ein KI-Agent eine konkrete Frage stellt („Wie ist die aktuelle Spindeltemperatur an Linie 3?“) und in Sekunden eine Antwort vom Steuerungssystem bekommt.
Der Hebel dahinter heißt Model Context Protocol (MCP). MCP ist ein offener Standard, den Anthropic Ende 2024 vorgestellt hat. Er definiert, wie ein Agent externe Tools aufruft. Die Spezifikation steht aktuell auf Version 2025-11-25, ein Release Candidate für die nächste Version (2026-07-28) ist seit Ende Juli in Arbeit. OPC UA wiederum ist der etablierte Industriestandard für Maschinenkommunikation: Laut OPC Foundation liefern inzwischen über 850 Hersteller OPC-UA-fähige Produkte aus, und die Adoption in der Fertigung wächst rund 40 Prozent pro Jahr.
Beide Welten zusammenzubringen ist genau die Lücke, die ein MCP Server für OPC UA schließt. Die Wirtschaftlichkeit dahinter ist nicht klein: Der OPC-UA-FX-Markt lag 2025 bei rund 15,87 Milliarden US-Dollar und wird für 2026 auf etwa 17,15 Milliarden geschätzt.
Das Problem: Der Agent ist blind für die Halle
Ein LLM-Agent ist gut darin, Texte zu verstehen und Werkzeuge aufzurufen. Was er von Haus aus nicht kann: in eine Maschine hineinsehen. Die Sensordaten leben in der OT-Welt — auf SPSen, in OPC-UA-Servern, hinter Protokollen, die ein Sprachmodell nicht spricht.
Der naheliegende Reflex ist, alles erst in eine Datenbank zu schreiben und den Agenten dann auf die Datenbank loszulassen. Das funktioniert für historische Analysen, aber für eine Live-Frage ist es der falsche Weg. Du baust eine ETL-Pipeline, die in dem Moment, in dem der Agent fragt, längst veraltet ist. Wir sehen das in Projekten regelmäßig: Teams investieren Monate in ein Daten-Backend, nur damit ein Chatbot am Ende Werte von gestern ausliest.
Unsere klare Empfehlung: Trenne die zwei Use-Cases sauber. Historisierung in den Lake, Live-Zugriff über einen MCP Server. Wenn du noch grundsätzlich zwischen Integrationsmustern abwägst, lohnt vorab der Blick auf die Abgrenzung von MCP gegenüber klassischen APIs und iPaaS — das spart dir die Diskussion, ob ein Message-Bus nicht auch reicht (tut er für Agenten-Tooling selten).
So funktioniert die Brücke
Der MCP Server sitzt zwischen Agent und OPC-UA-Server und übersetzt in beide Richtungen. Konkret passieren drei Dinge:
- Verbindung zur OT-Welt: Der MCP Server hält einen OPC-UA-Client offen, der per
asyncuamit dem Server auf der Maschine oder dem Edge-Gateway verbunden ist. - Tools statt Rohdaten: Statt dem Agenten den ganzen OPC-UA-Adressraum zu zeigen, definierst du ein paar klar umrissene Tools — etwa
read_nodeoderbrowse_machine. Jedes Tool hat ein JSON-Schema, das dem Agenten sagt, welche Parameter es erwartet. - Aufruf zur Laufzeit: Fragt der Nutzer den Agenten etwas, entscheidet das Modell (z.B.
claude-sonnet-4-6) selbst, welches Tool es mit welchen Argumenten aufruft. Der MCP Server führt den OPC-UA-Read aus und gibt das Ergebnis als strukturierte Antwort zurück.
Wichtig ist das Datenmodell: OPC UA bringt Companion Specifications mit, die Maschinentypen semantisch beschreiben. Auf der Hannover Messe 2026 hat die OPC Foundation über 430 dieser Companion Specs in ein KI-lesbares Format überführt — genau das macht es einem Agenten leichter, einen Node nicht nur zu lesen, sondern auch zu verstehen, was er bedeutet.
Technische Umsetzung: Ein lauffähiger MCP Server für OPC UA
Wir bauen den Server in Python. Stack: das offizielle MCP-SDK (mcp, aktuell Version 1.28.0) plus asyncua (Version 2.0, veröffentlicht am 5. Juni 2026, rund 1,4k GitHub-Stars, Stand Juni 2026). Beide brauchen Python ≥ 3.10.
Installation:
# Virtuelle Umgebung + Abhängigkeiten (Python >= 3.10 erforderlich)
python -m venv venv && source venv/bin/activate
pip install "mcp[cli]" asyncuaDer eigentliche Server. Er stellt zwei Tools bereit: einen gezielten Read eines OPC-UA-Nodes und ein Browse, mit dem der Agent die verfügbaren Nodes unter einem Ordner entdeckt.
"""
MCP Server, der einem KI-Agenten OPC-UA-Nodes als Tools verfügbar macht.
Stack: mcp 1.28.0 + asyncua 2.0 (Python >= 3.10)
"""
import os
from contextlib import asynccontextmanager
from collections.abc import AsyncIterator
from dataclasses import dataclass
from asyncua import Client
from mcp.server.fastmcp import FastMCP, Context
# Endpunkt des OPC-UA-Servers auf Maschine oder Edge-Gateway
OPCUA_URL = os.environ.get("OPCUA_URL", "opc.tcp://192.168.10.5:4840")
@dataclass
class AppContext:
"""Hält die offene OPC-UA-Verbindung über die Server-Laufzeit."""
client: Client
@asynccontextmanager
async def lifespan(_server: FastMCP) -> AsyncIterator[AppContext]:
# Verbindung einmal beim Start aufbauen, am Ende sauber schließen
client = Client(url=OPCUA_URL)
# In Produktion: Zertifikat + Verschlüsselung setzen (siehe Sicherheits-Abschnitt)
await client.connect()
try:
yield AppContext(client=client)
finally:
await client.disconnect()
mcp = FastMCP("opcua-bridge", lifespan=lifespan)
@mcp.tool()
async def read_node(node_id: str, ctx: Context) -> dict:
"""Liest den aktuellen Wert eines OPC-UA-Nodes.
node_id: OPC-UA NodeId, z.B. 'ns=2;s=Linie3.Spindel.Temperatur'
"""
client: Client = ctx.request_context.lifespan_context.client
node = client.get_node(node_id)
value = await node.read_value()
name = await node.read_display_name()
return {
"node_id": node_id,
"name": name.Text,
"value": value,
}
@mcp.tool()
async def browse_machine(parent_node_id: str, ctx: Context) -> list[dict]:
"""Listet die untergeordneten Nodes unter einem Ordner-Node auf,
damit der Agent verfügbare Messpunkte entdecken kann.
parent_node_id: NodeId des Eltern-Knotens, z.B. 'ns=2;s=Linie3'
"""
client: Client = ctx.request_context.lifespan_context.client
parent = client.get_node(parent_node_id)
children = await parent.get_children()
result = []
for child in children:
display = await child.read_display_name()
result.append({"node_id": child.nodeid.to_string(), "name": display.Text})
return result
if __name__ == "__main__":
# Startet den MCP Server über stdio (lokal) oder als HTTP-Transport
mcp.run()Das ist kein Pseudo-Code, das läuft. Du startest ihn mit python server.py und registrierst ihn in deinem Agenten-Host (Claude Desktop, ein eigener LangGraph-Agent oder ein Custom-Client) als MCP-Server.
Das Tool-Schema, das der Agent sieht
Der entscheidende Punkt: Der Agent ruft keine Funktion blind auf, er liest das Schema. FastMCP generiert es automatisch aus der Typ-Annotation und dem Docstring. So sieht das read_node-Tool aus Sicht des Agenten aus:
{
"name": "read_node",
"description": "Liest den aktuellen Wert eines OPC-UA-Nodes.",
"inputSchema": {
"type": "object",
"properties": {
"node_id": {
"type": "string",
"description": "OPC-UA NodeId, z.B. 'ns=2;s=Linie3.Spindel.Temperatur'"
}
},
"required": ["node_id"]
}
}Je präziser die Beschreibung und je enger das Schema, desto zuverlässiger trifft das Modell die richtige Tool-Wahl. Ein typischer Fehler ist, dem Agenten ein einziges generisches execute-Tool zu geben — dann rät er. Lieber zwei, drei spitze Tools mit klaren Schemas. Für die Frage, wie man solche Tool-Schichten über mehrere Systeme hinweg sauber orchestriert, haben wir das Muster im Detail in unserem Leitfaden zur Anbindung von SAP-Daten per MCP an Copilot Studio beschrieben — die OPC-UA-Variante folgt derselben Logik, nur mit der Maschine als Datenquelle statt SAP.
Sicherheit: Wo es in der OT ernst wird
Hier wird es heikel, und das ist keine Formalie. Ein MCP Server, der schreibend auf eine SPS zugreifen kann, ist ein potenzieller Hebel für genau die Angriffe, vor denen sich jeder OT-Verantwortliche fürchtet. Unsere Regel: Read-only als Default, Schreibzugriff nur über separate, explizit freigegebene Tools mit Audit-Log.
Drei Dinge sind nicht verhandelbar:
- OPC-UA-Verschlüsselung und Zertifikate. Im Code oben ist die Verbindung der Klarheit halber unverschlüsselt. In Produktion gehört dort
Basic256Sha256plus Client-Zertifikat hin — niemals ein nackteropc.tcp-Endpunkt ohne Security-Policy. - Tool-Berechtigungen härten. Der Agent darf nur das aufrufen, was er für seinen Use-Case braucht. Manipulierte Tool-Beschreibungen sind ein realer Angriffsvektor — gib dem Agenten exakt die Tools, die er braucht, und kein generisches Mächtiges.
- Netzwerk-Segmentierung. Der MCP Server lebt im OT-Netz oder in einer DMZ, nicht im offenen IT-Netz. Der Agent spricht über einen kontrollierten Kanal mit ihm.
Wir raten in den meisten Erstprojekten dazu, komplett auf Read-only zu starten. Ein Agent, der Werte ausliest und interpretiert, liefert 80 Prozent des Geschäftsnutzens bei einem Bruchteil des Risikos. Schreibzugriff kommt, wenn überhaupt, in einer zweiten Ausbaustufe mit Vier-Augen-Freigabe.
Was das in der Praxis bedeutet
Ein konkretes Szenario aus dem Maschinenbau, ohne Kundennamen: Ein Schichtleiter fragt den Werks-Assistenten per Chat, warum Linie 3 langsamer läuft. Der Agent ruft browse_machine auf, findet die relevanten Nodes, liest über read_node Spindeltemperatur und Vorschub aus, vergleicht mit dem Sollwert und antwortet in Klartext — inklusive Hinweis, dass die Temperatur 12 Prozent über dem Normalbereich liegt.
Ohne MCP Server hätte derselbe Schichtleiter sich durch ein SCADA-Dashboard klicken müssen oder einen Techniker gerufen. Der Unterschied ist nicht die Magie des LLM, sondern dass es Echtzeit-Zugriff auf die Maschine hat.
Was du dafür brauchst, ist überschaubar: ein erreichbarer OPC-UA-Endpunkt, der MCP Server oben, ein Agenten-Host. Die schwierigen Teile sind nicht der Code, sondern die Tool-Modellierung (welche Nodes exponiere ich?) und die Sicherheitsarchitektur.
Kosten und Zeitrahmen
Die ehrliche Antwort auf „Was kostet das?“: Der MCP Server selbst ist in wenigen Tagen gebaut. Der Aufwand steckt in der Anbindung an die konkrete OT-Landschaft, der Auswahl der richtigen Nodes und der Sicherheitsabnahme.
Wir setzen so etwas typischerweise als 6-Wochen-Pilot auf: Woche 1-2 Anbindung an einen OPC-UA-Server und Read-only-Tools, Woche 3-4 Agenten-Integration und Tool-Tuning, Woche 5-6 Sicherheitshärtung und ein erster produktiver Use-Case. Budgetrahmen für einen solchen Piloten liegt im unteren fünfstelligen Bereich — deutlich unter dem, was eine vollständige Datenplattform kostet, eben weil wir hier nichts historisieren, sondern nur anbinden.
Häufig gestellte Fragen
Was ist ein MCP Server für OPC UA?
Ein MCP Server für OPC UA ist eine Software-Brücke, die Live-Maschinendaten aus einem OPC-UA-Server als aufrufbare Tools für einen KI-Agenten bereitstellt. Der Agent ruft zur Laufzeit ein Tool wie read_node auf, der MCP Server liest den Wert per OPC-UA-Client aus und gibt ihn strukturiert zurück. So bekommt das Sprachmodell Echtzeit-Zugriff auf die Steuerungsebene, ohne die Daten vorher in eine Datenbank schreiben zu müssen.
Was kostet die Anbindung von Maschinendaten an einen KI-Agenten per MCP?
Kommt auf die OT-Landschaft an, aber als Orientierung: Wir setzen die Anbindung als 6-Wochen-Pilot auf, der Budgetrahmen liegt im unteren fünfstelligen Bereich. Das ist deutlich günstiger als eine vollständige Datenplattform, weil ein MCP Server nur anbindet und nicht historisiert. Der teure Teil ist nicht der Code, sondern die Sicherheitsabnahme und die Auswahl der richtigen Nodes.
MCP Server oder Data Lake — was brauche ich?
Beides löst unterschiedliche Probleme. Ein Data Lake ist richtig, wenn du Maschinendaten über Monate historisierst und auswertest. Ein MCP Server ist richtig, wenn ein Agent in Sekunden eine Live-Frage an die Maschine stellen soll. In der Praxis ergänzen sie sich: Lake für die Historie, MCP für den Echtzeit-Zugriff. Wer beides in eine Pipeline zwingt, baut Latenz ein, wo keine sein darf.
Welche Python-Library nutze ich für OPC UA?
asyncua (Paketname auf PyPI: asyncua) ist die aktiv gepflegte Standard-Wahl für OPC UA in Python. Aktuell ist Version 2.0 vom 5. Juni 2026, das Repository hat rund 1,4k GitHub-Stars (Stand Juni 2026) und setzt Python ≥ 3.10 voraus. Sie ist asyncio-basiert, was gut zum MCP-SDK passt, das ebenfalls asynchron arbeitet.
Ist ein schreibender Zugriff auf die SPS über einen KI-Agenten sicher?
Nur mit harten Leitplanken. Wir starten Projekte grundsätzlich Read-only, weil ein lesender Agent bereits den größten Nutzen liefert. Schreibzugriff sollte über separate, explizit freigegebene Tools laufen, mit Audit-Log, OPC-UA-Verschlüsselung (Basic256Sha256), Client-Zertifikaten und Netzsegmentierung. Ein direkter, ungesicherter Schreibpfad vom LLM zur Steuerung ist ein klares No-Go.
Nächster Schritt
Wenn du einen konkreten Maschinen-Use-Case hast und wissen willst, ob ein MCP Server der richtige Weg dafür ist, klären wir das am schnellsten im Gespräch — inklusive einer ehrlichen Einschätzung, wann Read-only reicht und wo es doch eine Datenplattform braucht.
Verwandte Themen
→Orchestrierung mehrerer KI-Agenten im Unternehmen
→asyncua: OPC-UA-Library für Python (GitHub)
