Das Model Context Protocol (kurz MCP) ist ein offener Standard, über den KI-Anwendungen auf externe Werkzeuge und Datenquellen zugreifen. Statt für jede Kombination aus KI-Anwendung und Datenquelle eine eigene Anbindung zu schreiben, sprechen beide Seiten dasselbe Protokoll: Ein Server stellt bereit, was er anzubieten hat, ein Client nutzt es. Veröffentlicht hat das Protokoll Anthropic Ende 2024, offengelegt und dokumentiert, sodass es jeder implementieren kann.
Der Vergleich, der am ehesten trägt: MCP will für den Werkzeugzugriff von KI-Anwendungen das sein, was ein Standardstecker für Peripheriegeräte ist. Nicht spektakulär, aber es erspart eine Menge Adapter.
Das Problem, das der Standard löst
Ein Sprachmodell allein weiß nichts über dein Unternehmen. Nützlich wird es erst, wenn es an eure Daten kommt: an das Ticketsystem, die Dokumentenablage, die Datenbank, das CRM. Genau dafür schreibt man Anbindungen.
Ohne Standard wächst dieser Aufwand als Produkt und nicht als Summe. Bei fünf KI-Anwendungen und zehn Systemen sind es fünfzig Anbindungen, jede mit eigener Authentifizierung, eigenem Datenformat und eigener Pflege. Das ist das klassische N-mal-M-Problem, und es ist der Grund, warum Integrationsprojekte selten am Modell scheitern.
| Ohne Protokoll | Mit MCP | |
|---|---|---|
| Anzahl Anbindungen | eine je Paar aus Anwendung und System | eine je Anwendung, eine je System |
| Wiederverwendung | keine, jede Anbindung ist ein Einzelstück | ein Server bedient jeden Client |
| Wechsel der KI-Anwendung | alle Anbindungen neu | Server bleiben, Client wird getauscht |
| Pflege | verteilt über viele Projekte | gebündelt an einer Stelle je System |
Der Nutzen ist also weniger technischer Zauber als Arithmetik. Aus fünfzig Einzelstücken werden fünfzehn wiederverwendbare Bausteine.
Client und Server
MCP arbeitet mit einer klaren Rollenteilung, die man einmal verstanden haben sollte, weil die Begriffe hier ungewohnt herum liegen.
Der Server
Der MCP-Server sitzt an der Datenquelle oder am Werkzeug. Er kapselt ein System, etwa eine Datenbank, ein Dateiverzeichnis oder eine Schnittstelle, und beschreibt nach außen, was er kann: welche Werkzeuge er anbietet, welche Angaben sie brauchen, welche Daten er lesbar macht. Er enthält die gesamte Logik für dieses eine System, inklusive Authentifizierung und Fehlerbehandlung.
Wichtig: Ein MCP-Server ist nicht zwingend ein Dienst irgendwo im Netz. Er kann auch ein lokal gestartetes Programm auf demselben Rechner sein. Das ist bei Entwicklungswerkzeugen sogar der Normalfall.
Der Client
Der Client sitzt in der KI-Anwendung, also in dem Programm, mit dem Menschen arbeiten: einem Chatfenster, einer Entwicklungsumgebung, einem KI-Agenten. Er verbindet sich mit einem oder mehreren Servern, fragt ab, was diese anbieten, und stellt das dem Modell als verfügbare Werkzeuge zur Verfügung. Entscheidet das Modell, ein Werkzeug zu nutzen, schickt der Client den Aufruf an den passenden Server und gibt das Ergebnis zurück in den Kontext.
Das Modell selbst spricht kein MCP. Es sieht nur eine Liste von Werkzeugen und deren Beschreibungen. Der ganze Standard liegt eine Ebene darunter, in der Anwendung.
Was ein Server anbieten kann
Grob lassen sich die Angebote eines Servers in drei Arten teilen. Die Unterscheidung ist praktischer Natur und beschreibt vor allem, wer die Nutzung auslöst.
- Werkzeuge. Aufrufbare Funktionen mit Nebenwirkung oder Rückgabewert, etwa eine Suche, ein Datenbankzugriff, das Anlegen eines Tickets. Die Entscheidung, sie zu benutzen, trifft das Modell.
- Ressourcen. Lesbare Inhalte, die als Kontext dienen: Dateien, Datensätze, Dokumentation. Sie werden gelesen, nicht ausgeführt.
- Vorlagen. Vorformulierte Bausteine für wiederkehrende Aufgaben, die eine Anwendung anbieten kann, damit Nutzerinnen sie auswählen.
Über konkrete Detailfestlegungen lohnt sich der Blick in die offizielle Spezifikation, denn das Protokoll wird weiterentwickelt und nicht jede Client-Anwendung unterstützt jeden Teil davon.
Was das in der Praxis ändert
Für ein Unternehmen verschiebt ein Standard vor allem eine Entscheidung: Die Anbindung an das eigene System ist nicht mehr an eine bestimmte KI-Anwendung gebunden. Wer heute einen MCP-Server für das eigene Warenwirtschaftssystem baut, kann ihn morgen mit einer anderen Anwendung nutzen, ohne die Integration erneut zu schreiben.
Das ist die gute Nachricht. Die nüchterne dazu: Ein Protokoll löst keines der Probleme, die Integrationsprojekte eigentlich teuer machen. Rechte, Datenqualität, Verfügbarkeit und die Frage, wer die Anbindung pflegt, bleiben genau da, wo sie vorher lagen. MCP sorgt dafür, dass du diese Arbeit einmal machst statt fünfmal.
Sicherheitsseitig kommt eine eigene Überlegung dazu. Ein Server, den eine KI-Anwendung aufrufen darf, ist ein Zugang zu einem System, und die Inhalte, die er zurückgibt, landen im Kontext des Modells. Damit sind es potenziell Anweisungen, siehe Prompt Injection. Ein eigenes Konto mit engem Rechteschnitt ist deshalb kein Übereifer, sondern der Normalfall.
Häufige Fragen zum Model Context Protocol
Ist MCP an ein bestimmtes Modell gebunden? Nein. Das Protokoll beschreibt die Verbindung zwischen Anwendung und Datenquelle, nicht das Modell dahinter. Welches Large Language Model die Anwendung benutzt, ist für den Server unsichtbar.
Brauche ich MCP, wenn ich ohnehin eine eigene Anwendung baue? Nicht zwingend. Für genau eine Anwendung und genau eine Datenquelle ist eine direkte Anbindung schneller gebaut. Der Standard rechnet sich, sobald mehrere Anwendungen auf dieselbe Quelle zugreifen sollen oder du dir die Option offenhalten willst, die Anwendung zu wechseln.
Was ist der Unterschied zu einer normalen Schnittstelle? MCP ersetzt keine Schnittstelle, es liegt darüber. Ein Server nutzt intern weiterhin die REST- oder Datenbankschnittstelle des Systems. Was er ergänzt, ist eine einheitliche Beschreibung dessen, was ein Modell hier tun darf und wie es die Rückgabe zu lesen hat.
Gibt es fertige Server, oder muss man alles selbst bauen? Für viele verbreitete Systeme existieren bereits Implementierungen, teils von den Herstellern, teils aus der Community. Für hauseigene Systeme schreibt man den Server selbst, was dank offener Spezifikation und Bibliotheken in mehreren Sprachen überschaubar bleibt.
Fazit
Das Model Context Protocol ist eine unauffällige, aber folgenreiche Festlegung. Es macht aus dem Anbinden von KI-Anwendungen eine Aufgabe, die man je System einmal löst statt je Projekt neu, und es entkoppelt die eigene Integration von der Frage, welche KI-Anwendung gerade vorne liegt. Der schwierige Teil eines Integrationsprojekts bleibt bestehen, er wird nur nicht mehr mehrfach bezahlt. Wie wir Schnittstellen, Rechtekonzepte und Systemanbindungen bauen, steht auf unserer Seite zur Custom-Software-Entwicklung. Unsere Einschätzung dazu, was der Einsatz von KI in der Entwicklung tatsächlich bringt, findest du im Artikel KI in der Softwareentwicklung. Wofür diese Anbindungen am Ende gebraucht werden, nämlich für Systeme, die selbst Schritte ausführen, steht auf unserer Seite zu KI-Agenten, und für alles Weitere gibt es das unverbindliche Beratungsgespräch.