Im Jahr 2024 war jede KI-Integration eine Einzelanfertigung. Ein Team, das einen KI-Assistenten für ihr CRM aufbaute, schrieb maßgeschneiderten Klebecode für das Abrufen von Datensätzen, das Aktualisieren von Feldern und das Aufrufen interner APIs. Dann machten sie dasselbe für das ERP, das Ticketing-System und den Dokumentenspeicher. Das Ergebnis: fragile, nicht wiederverwendbare Konnektoren, die bei jedem API-Update brachen und nicht projektübergreifend geteilt werden konnten.
Dieses Problem hat jetzt eine Standardlösung. Sie heißt Model Context Protocol (MCP), und in den 18 Monaten seit Anthropic es als Open Source veröffentlicht hat, ist es zum dominanten Weg geworden, auf dem Unternehmens-KI-Systeme mit der Außenwelt kommunizieren.
Was MCP eigentlich ist
MCP ist ein offenes Protokoll, das eine Standardschnittstelle zwischen KI-Modellen (oder den darauf laufenden Agenten) und externen Systemen definiert. Stellen Sie es sich als USB-Standard für KI vor — anstatt dass jedes Tool einen maßgeschneiderten Konnektor benötigt, spricht alles, was MCP implementiert, dieselbe Sprache.
Das Protokoll hat drei primitive Typen:
- Tools (Werkzeuge) — Aktionen, die die KI aufrufen kann (Datenbankabfrage ausführen, Ticket erstellen, E-Mail senden)
- Resources (Ressourcen) — Daten, die die KI lesen kann (eine Datei, eine Datenbankzeile, ein Dokument)
- Prompts — wiederverwendbare Instruktionsvorlagen, die vom Client parametrisiert werden können
Ein MCP-Server stellt einen oder mehrere dieser Typen bereit. Ein MCP-Client — typischerweise ein KI-Agent oder eine Orchestrierungsschicht — erkennt, was der Server anbietet, und ruft es bei Bedarf auf. Das Modell selbst muss die zugrundeliegende Implementierung nie kennen; es sieht nur eine saubere, typisierte Schnittstelle.
Warum die Enterprise-KI-Welt das brauchte
Vor MCP war der Standardansatz Function Calling: für jede Funktion ein JSON-Schema definieren, es in den Kontext einfügen, das Modell entscheiden lassen, wann es aufgerufen werden soll. Das funktioniert gut für eine Handvoll Tools. Bei Enterprise-Skala scheitert es.
Die Probleme sind vorhersehbar:
Schema-Wildwuchs. Jedes Team schreibt seine eigenen Tool-Definitionen in seinem eigenen Format. Es gibt keine gemeinsame Bibliothek, keine Versionierung, keine Governance. Wenn sich die zugrundeliegende API ändert, muss jeder Konsument dieser Tool-Definition unabhängig aktualisieren.
Keine Serverabstraktion. Das Modell, das das Tool aufruft, und das aufgerufene System sind gekoppelt. Wenn Sie Authentifizierung, Ratenbegrenzung oder Audit-Logging zu einem Tool hinzufügen möchten, tun Sie das in jeder Integration separat.
Schlechte Auffindbarkeit. Es gibt keinen Standardweg, auf dem ein Agent fragen kann „was kann ich hier tun?" Ohne Laufzeitermittlung kann der Agent nur Tools aufrufen, die beim Start fest in seinen Kontext kodiert wurden.
MCP löst alle drei Probleme. Jeder MCP-Server ist ein eigenständiger Dienst mit eigener Versionierung, Sicherheitsrichtlinie und Dokumentation. Agenten entdecken verfügbare Tools zur Laufzeit. Das Protokoll ist sprachagnostisch — MCP-Server existieren in Python, TypeScript, Go und Rust.
Das Ökosystem im Jahr 2026
Das Tempo der MCP-Server-Entwicklung war bemerkenswert. Die aktuelle Landschaft umfasst:
Datenbankkonektoren — PostgreSQL, MySQL, MongoDB und die meisten Enterprise-Data-Warehouses haben Community- oder offizielle MCP-Server. Ein Agent kann Datensätze abfragen, einfügen und aktualisieren, ohne maßgeschneiderten SQL-Klebecode zu benötigen.
Business-System-Integrationen — Salesforce, HubSpot, Jira, Linear, GitHub, Slack und Microsoft 365 haben alle MCP-Server. Hier liegt der Enterprise-ROI: Agenten, die ein Support-Ticket lesen, den Vertrag des Kunden im CRM nachschlagen, die relevante Dokumentation prüfen und eine Antwort entwerfen können — alles durch Standard-MCP-Aufrufe.
Entwicklungstools — IDEs wie Cursor und VS Code liefern jetzt MCP-Unterstützung als eingebaute Funktion. Ein KI-Coding-Assistent kann den Test-Runner abfragen, CI-Status prüfen, interne Dokumentation lesen und PRs über ein einziges Protokoll öffnen.
Datei- und Dokumentensysteme — Lokale Dateisysteme, S3-kompatible Objektspeicher und Dokumentenverwaltungsplattformen machen ihre Inhalte über MCP-Ressourcen zugänglich. Agenten können Dokumente abrufen und darüber nachdenken, ohne sie alle vorab in das Kontextfenster einzubetten.
Eigene Unternehmensserver — Zunehmend sind die wertvollsten MCP-Server diejenigen, die Unternehmen für ihre eigenen internen Systeme bauen. ERP-Konektoren, interne APIs, proprietäre Datenbanken — jedes System, das für KI-Agenten erreichbar sein muss, ist ein Kandidat für einen MCP-Server.
Wie ein Enterprise-MCP-Server aussieht
Ein MCP-Server ist kein großer Codebase. Ein gut abgegrenzter Server für eine einzelne Geschäftsdomäne — zum Beispiel ein Beschaffungssystem — umfasst typischerweise 200–500 Zeilen Anwendungscode, sobald das Boilerplate durch das SDK gehandhabt wird.
Die wichtigsten Designentscheidungen sind:
Tool-Granularität. Definieren Sie Tools auf der Ebene von Geschäftsvorgängen, nicht von rohen API-Aufrufen. get_open_purchase_orders(vendor_id) ist ein besseres Tool als execute_sql_query(query). Gröbere Tools sind für Modelle einfacher korrekt zu verwenden und einfacher zu prüfen.
Authentifizierung und Autorisierung. Der MCP-Server ist eine Sicherheitsgrenze. Er sollte Zugriffskontrollen unabhängig vom aufrufenden Agenten durchsetzen. Der Agent präsentiert Anmeldeinformationen; der Server validiert sie gegen die Berechtigungen des zugrundeliegenden Systems. Agenten sollten niemals umfangreicheren Zugriff haben als der Mensch oder das Dienstkonto, in dessen Namen sie handeln.
Schema-Präzision. Tippen Sie Eingaben und Ausgaben streng. Verwenden Sie Enums, wo die Domäne Werte einschränkt. Geben Sie Beschreibungen an, die erklären, was das Tool aus geschäftlicher, nicht technischer Perspektive tut — das Modell liest diese Beschreibungen, um zu entscheiden, ob es das Tool aufrufen soll.
Observability. Protokollieren Sie jeden Tool-Aufruf mit den Eingabeargumenten, dem Ergebnis und der Identität des Aufrufers. In einem Audit-Kontext ist dieses Protokoll die Papierspur für jede Aktion, die die KI im Namen des Unternehmens durchgeführt hat.
Muster, die im B2B-Bereich funktionieren
Die produktivste Verwendung von MCP in Unternehmensumgebungen ist das Domänenserver-Muster: ein MCP-Server pro Geschäftsdomäne mit einer stabilen, versionierten Schnittstelle, die jeder Agent in der Organisation nutzen kann.
Ein Unternehmen mit gut gestalteten Domänenservern für CRM, ERP, Support und HR kann neue KI-Workflows aufbauen, ohne neue Integrationen zu schreiben. Der Agent, der neue Automatisierungen aufbaut, entdeckt und kombiniert einfach bestehende Server. Das ist der zusammengesetzte Vorteil früher Standardisierung.
Das unproduktivste Muster ist der Aufbau eines monolithischen MCP-Servers, der versucht, alles bereitzustellen. Diese werden unmöglich zu verstehen, schwer abzusichern und spröde. Schmale Server mit klarer Eigentümerschaft sind einfacher weiterzuentwickeln.
Die Wettbewerbsrealität
Die Unternehmen, die heute in MCP-Infrastruktur investieren, bauen einen dauerhaften Vorteil auf. Jeder Domänenserver, den sie erstellen, kann von jedem nachfolgenden KI-Workflow, den sie aufbauen, wiederverwendet werden. Die Grenzkosten der nächsten Automatisierung sinken mit jedem erstellten Server.
Unternehmen, die dieses Fundament überspringen — die für jedes KI-Projekt Einzellösungen bauen — werden dasselbe Fragmentierungsproblem auf der Agentenebene erleben, dem sie bereits auf der Datenebene begegnet sind. Die Tools ändern sich, aber die Lektion nicht: Standards akkumulieren, maßgeschneiderte Lösungen nicht.
Wenn Sie bewerten möchten, wie MCP in Ihre KI-Architektur passt oder Ihren ersten Enterprise-MCP-Server aufbauen möchten, sprechen wir miteinander. Wir helfen B2B-Softwareteams, KI-Infrastruktur zu entwerfen und bereitzustellen, die skaliert.