MCP-Anbindung für Claude, vom sicheren Server bis zur Maschinendaten-Integration

MCP ist ein offener Standard von Anthropic, über den Claude auf externe Systeme, Daten und Werkzeuge zugreift - ohne dass jede Anbindung einzeln programmiert werden muss. Ein MCP-Server kapselt den Zugriff auf ein System, zum Beispiel SAP oder eine Maschinensteuerung, und stellt ihn Claude als aufrufbares Werkzeug bereit. Claude ist dabei nicht der einzige Client, aber der Standard ist von Anthropic entwickelt und in Claude Code sowie im Claude Agent SDK nativ unterstützt.

Nur mit dokumentierter Absicherung. Im April 2026 meldete OX Security die kritische Schwachstelle CVE-2026-30623 (CVSS 9.8) in offiziellen Anthropic-SDKs, rund 200.000 Server galten als verwundbar. Produktiver Einsatz braucht seither mindestens Manifest-Hashing, eine Allowlist statt offener Discovery und einen Audit-Trail - alle acht Maßnahmen stehen im Artikel zu Tool Poisoning.

Die offizielle MCP Registry ist seit dem 8. September 2025 online und in zehn Wochen von 390 auf rund 2.000 Einträge gewachsen - offen für jeden, der einen Server veröffentlichen will. Für regulierte Branchen wie Banken oder Versicherer reicht das nicht als Freigabegrundlage. Eine eigene Subregistry kuratiert vorab, welche Server überhaupt zur Auswahl stehen.

Ja, das ist einer unserer häufigsten Fälle. Über einen MCP-Server für OPC UA liest ein Agent Sensorwerte direkt von der Steuerung, in der Praxis innerhalb von unter zwei Wochen bis zur ersten produktiven Anbindung. Für SAP-Prozesse zeigt unser Artikel zum LangGraph-Multi-Tool-Agenten, wie das Muster aussieht. Bei SAP gehört seit April 2026 ein zweiter Punkt dazu: Ziffer 2.2.2 der SAP API Policy 4.2026a untersagt die Anbindung generativer oder (teil-)autonomer KI-Systeme, die Abfolgen von SAP-API-Aufrufen planen, auswählen oder ausführen, außer über von SAP vorgesehene Wege. Deshalb legt bei SAP-Anbindungen der Integrationsflow die Aufruffolge fest und Claude liefert den Inhalt. Für OPC UA und interne Systeme gilt diese Einschränkung nicht.

Das hängt zu stark vom angebundenen System ab, um es hier seriös zu beziffern - ein OPC-UA-Server ist ein anderer Aufwand als eine SAP-Anbindung mit Berechtigungsprüfung. Nach einer kurzen Bestandsaufnahme Ihrer Systeme und Ihres Sicherheitsanspruchs bekommen Sie eine belastbare Einschätzung, vorher wäre jede Zahl geraten.

FastMCP baut auf dem Protokoll auf und reduziert den Boilerplate-Aufwand für einen produktionsreifen Server deutlich, unter anderem durch fertige Patterns für Composition, Resources, Prompts, OAuth2 und Multi-Tenant-Setup. Das Vanilla-SDK gibt mehr Kontrolle auf niedriger Ebene, verlangt dafür aber, dass Sie diese Bausteine selbst bauen. Für die meisten Unternehmenseinsätze ist FastMCP der pragmatischere Startpunkt.

Nein. Eine klassische Integration verbindet zwei Systeme fest miteinander. MCP macht ein System als Werkzeug für einen KI-Agenten aufrufbar - der Agent entscheidet zur Laufzeit, welches Werkzeug er wann nutzt. Das ist ein anderes Sicherheits- und Governance-Modell, weil nicht mehr nur der Entwickler, sondern auch der Agent den Aufruf auslöst.

Wir haben unsere eigenen MCP-Beiträge im Bereich KI-Integration überprüft: 13 davon behandeln das Protokoll generisch, ohne konkreten Claude-Bezug im Artikeltext. Die sechs Artikel, auf die diese Seite verweist, sind einzeln gegen echten Claude-, Claude-Code- oder Claude-Agent-SDK-Bezug geprüft worden - nicht nur gegen eine Erwähnung in einer Anbieter-Aufzählung.

Ja. Über langchain-mcp-adapters werden MCP-Tools zu einer LangChain- und LangGraph-kompatiblen Tool-Liste - damit lassen sich MCP-Server in bestehende Agent-Pipelines einbinden, die nicht ausschließlich auf Claude direkt aufsetzen. In der Praxis kombinieren viele unserer Projekte beides: Claude als Modell, LangGraph als Orchestrierung.

Für einen klar abgegrenzten Anwendungsfall wie eine einzelne OPC-UA-Datenquelle sind wenige Wochen realistisch, wie unser Praxisbericht zeigt. Komplexere Anbindungen wie SAP mit mehrstufiger Berechtigungsprüfung brauchen deutlich länger - vor allem wegen der Auth-Logik, nicht wegen des MCP-Teils selbst.

Ziffer 2.2.2 der SAP API Policy 4.2026a (abgerufen am 18.09.2026) untersagt die Nutzung von SAP-APIs für die Anbindung generativer oder (teil-)autonomer KI-Systeme, die Abfolgen von API-Aufrufen planen, auswählen oder ausführen, außer über von SAP vorgesehene Architekturen, Datendienste oder dienstspezifische Wege; Ziffer 3 verbietet die Umgehung über eigenen Code, Proxys oder Gateways. MCP selbst ist damit nicht verboten, SAP baut eigene MCP-Infrastruktur. Verboten ist ein bestimmtes Zugriffsmuster, und die Trennlinie verläuft nicht zwischen Lesen und Schreiben, sondern zwischen einem Integrationsflow, der die Aufruffolge festlegt, und einem Modell, das sie selbst wählt. Für uns heißt das: Ein MCP-Server gegen SAP bleibt als gekapselte Integrationsschicht sinnvoll, deren Aufrufe der Flow anstoßt. Soll Claude selbst entscheiden, welchen SAP-Dienst er als Nächstes aufruft, führt der Weg über die von SAP vorgesehenen Architekturen: MCP Gateway der SAP Integration Suite, SAP-eigene MCP-Server über Joule Studio und A2A. SAP stellt in der CAP-Dokumentation ausdrücklich klar, dass ein selbst gebauter MCP-Adapter keine anerkannte Architektur im Sinne dieser Ziffer ist. Was in Ihrer Landschaft zulässig ist, klärt verbindlich nur Ihr SAP-Vertrag oder Ihr SAP-Account-Team; wir bringen die Frage in jedem Projekt auf den Tisch. Für OPC UA, DMS, Fachverfahren und interne APIs gilt die Einschränkung nicht.