In vielen Unternehmen sind APIs längst strategisches Kapital. Aber oft nur für diejenigen, die sie wirklich verstehen. Das Model Context Protocol – kurz MCP – könnte das ändern. Still. Aber grundlegend.
Meine erste Begegnung mit MCP war keine Spezifikation, sondern eine Demo. Ralf D. Müller zeigte bei Softwarearchitektur im Stream, wie Claude – das Sprachmodell von Anthropic – über ein selbstgebautes Browser-Tool eigenständig Werkzeuge nutzen konnte. Kein Copy-Paste, keine Befehle über Umwege. Einfach nur: „Mach das“, und Claude entschied selbst, wie.
Was mich daran fasziniert hat: Die Aufgabenstellung kam vom Menschen, die Vorgehensweise wählte die KI. Der Fokus lag auf dem Was, nicht auf dem Wie. Wenn man dieses Prinzip auf APIs überträgt, ändert sich etwas Grundlegendes. Schnittstellen müssen dann nicht mehr aktiv bedient, sondern zielgerichtet verfügbar gemacht werden – mit den nötigen Informationen, aber in einer Form, die ein KI-System versteht.
Genau das ist die Idee hinter dem Model Context Protocol, kurz MCP. Ein Protokoll, das es Sprachmodellen ermöglicht, APIs samt ihrer Funktionen, Datenstrukturen und Abläufe so zu erfassen, dass sie sie sinnvoll nutzen können. Und das nicht in einer fernen Zukunft, sondern jetzt.
Was ist MCP – und warum ist das interessant?
Das Model Context Protocol (MCP) ist kein neuer API-Standard im klassischen Sinne. Es ersetzt keine Schnittstellen, keine Formate, keine Transportwege. Stattdessen ergänzt es bestehende APIs um etwas, das bisher meist fehlte: strukturierten Kontext für Maschinen, insbesondere für Sprachmodelle.
Konkret definiert MCP, wie ein System Informationen über seine Fähigkeiten bereitstellen kann – in einer Form, die für generative KI nachvollziehbar ist. Diese sogenannten Capabilities beschreiben nicht nur, was ein Dienst kann, sondern auch, wie typische Aufrufe aussehen, welche Parameter erforderlich sind, welche Rückgabewerte zu erwarten sind. Nicht als Dokumentation für Menschen, sondern als strukturierte Hilfestellung für Modelle.
Dabei steht kein einzelner Use Case im Vordergrund. Ein Capability könnte einen Datenbankeintrag erstellen, eine Nachricht übermitteln oder einen internen Report abrufen – entscheidend ist, dass ein KI-System daraus ableiten kann, wie die Funktion zu verwenden ist.
Der eigentliche Unterschied zu herkömmlicher API-Dokumentation liegt also nicht im Was (“Welche Operationen gibt es?”), sondern im Wofür (“Was kann ich damit erreichen?”): MCP zielt darauf ab, dass nicht Menschen APIs verstehen und bedienen müssen, sondern Maschinen. Schnittstellen werden so zu Werkzeugen, die durch Sprachmodelle gesteuert werden können – je nach Kontext, Absicht und Ziel.
Das hat weitreichende Folgen. Denn wenn KI-Systeme nicht nur Texte schreiben, sondern auch mit realen Diensten interagieren können, ändert sich das Verhältnis zwischen Nutzer*in, Anwendung und Schnittstelle. Die Frage lautet nicht mehr: „Welche API muss ich wie aufrufen?“, sondern: „Welche Aufgabe möchte ich erledigen – und was steht dafür zur Verfügung?“
Von der API zur Aufgabe: Warum Zugänglichkeit den Unterschied macht
Aus Unternehmenssicht ist MCP zunächst keine Revolution, sondern eine stille Verschiebung. Schnittstellen bleiben, was sie sind: technische Zugangspunkte zu Funktionen, Daten und Prozessen. Aber die Art, wie sie genutzt werden, verändert sich – und das kann strategische Auswirkungen haben.
Ein naheliegender Vorteil ist die vereinfachte Integration. Wenn ein KI-System selbstständig erkennt, wie es mit einem Dienst interagieren kann, entfällt ein großer Teil der manuellen Arbeit: keine Code-Beispiele mehr suchen, keine Auth-Flows von Hand nachbauen, keine Trial-and-Error-Runden im API-Testtool. Stattdessen reicht ein Ziel („Lade aktuelle Umsatzzahlen hoch“), und die KI sucht sich den Weg dorthin über die verfügbaren Capabilities.
Das senkt Hürden – nicht nur für Entwickler*innen, sondern auch für Teams, die bisher wenig mit APIs zu tun hatten. In internen Plattformen könnten so neue Self-Service-Funktionen entstehen. Auch produktnahe Rollen könnten ohne technische Abhängigkeiten mit Systemen arbeiten, die heute noch eine eigene Schnittstelle erfordern.
Hinzu kommt die Zugänglichkeit für KI-Anwendungen: Sprachmodelle wie Claude oder ChatGPT, eingebettet in Tools, Assistenten oder Agents, können MCP nutzen, um mit APIs produktiv zu arbeiten – ohne dass diese speziell dafür angepasst werden müssen. Die Schnittstelle bleibt gleich, der Kontext macht den Unterschied.
Und schließlich verändert sich auch die Perspektive auf APIs selbst. Wenn Schnittstellen nicht mehr nur „bereitgestellt“, sondern kontextualisiert werden müssen, rücken andere Fragen in den Vordergrund:
- Wie beschreibe ich eine Funktion so, dass sie auffindbar und sinnvoll nutzbar ist?
- Wie gestalte ich den Zugang, ohne Kontrolle oder Sicherheit zu verlieren?
- Welche Schnittstellen will ich sichtbar machen – und für wen?
Was MCP dabei besonders interessant macht: Die Nutzung erfolgt nicht über neue Spezialtools, sondern direkt in bestehenden Anwendungen. In den Desktop-Apps von ChatGPT oder Claude können die Nutzer*innen Aufgaben einfach formulieren – etwa „Schick mir die aktuelle Pipeline aus dem CRM“ – und die KI nutzt im Hintergrund die bereitgestellten Capabilities, um das umzusetzen. Keine zusätzliche Oberfläche, kein gesondertes Interface – nur ein Modell, das die vorhandenen Werkzeuge versteht.
Für viele Unternehmen ist das eine neue Form der Zugänglichkeit: APIs werden nicht nur einfacher integrierbar, sondern auch leichter erreichbar. Und das könnte langfristig entscheidender sein als jede neue Schnittstellentechnologie.
MCP im Feld: Wer schon mitspielt – und was entsteht
Das Model Context Protocol wurde im November 2024 von Anthropic vorgestellt – als pragmatische Lösung für ein konkretes Problem: Wie kann ein Sprachmodell zuverlässig verstehen, welche externen Tools und Schnittstellen es nutzen darf – und wie?
Nur wenige Monate später kündigte auch OpenAI die Unterstützung von MCP an. Damit ist klar: Das Protokoll ist nicht auf ein einzelnes KI-System zugeschnitten. Im Gegenteil – es entwickelt sich mit bemerkenswerter Geschwindigkeit zu einem anbieterunabhängigen Standard für KI-gesteuerte Schnittstellenzugriffe.
Auch Microsoft bringt sich aktiv ein. In Copilot Studio wird MCP genutzt, um Aktionen und Wissensquellen automatisiert bereitzustellen – etwa für die Entwicklung interner KI-Anwendungen oder Agenten. Der zugehörige Azure AI Agent Service unterstützt MCP ebenfalls. Und mit dem Open-Source-Projekt Playwright-MCP stellt Microsoft sogar einen eigenen MCP-Server bereit, der Sprachmodellen erlaubt, automatisiert im Web zu navigieren.
Gleichzeitig wächst das Ökosystem rund um MCP. Auf Plattformen wie mcpt.com oder mcp.run entstehen erste Kataloge von Context Servern. Hier lassen sich bestehende Capabilities durchsuchen, testen und mit eigenen Diensten verknüpfen. Die Idee erinnert an frühe API-Marktplätze – mit dem Unterschied, dass die primäre Zielgruppe heute nicht mehr Menschen, sondern Modelle sind.
Auch in der Open-Source-Community gibt es Bewegung. Auf GitHub finden sich bereits mehrere Implementierungen von MCP-Servern – in unterschiedlichen Sprachen und mit unterschiedlichen Zielsetzungen. Die Einstiegshürden sind niedrig, das Interesse ist da.
Natürlich ist das alles noch kein konsolidiertes Ökosystem. Aber die Geschwindigkeit, mit der sich die Idee verbreitet, ist bemerkenswert. Und sie deutet darauf hin, dass MCP nicht nur ein interessantes Konzept ist – sondern eines, das kommt, um zu bleiben.
Zwischen Anspruch und Wirklichkeit: Was noch zu klären ist
So vielversprechend MCP ist – es wäre naiv, nur auf die Potenziale zu schauen und die offenen Fragen auszublenden. Denn wie bei jeder neuen Technologie gibt es auch hier Unsicherheiten. Manche sind technischer Natur, andere betreffen Prozesse, Rollen und Verantwortung.
Technologische Reife
MCP ist jung. Die Spezifikation entwickelt sich ständig weiter, erste Implementierungen entstehen gerade erst. Das bedeutet: Wer heute einsteigt, bewegt sich in einem sich schnell verändernden Umfeld – mit allen Risiken und Chancen, die das mit sich bringt. Was heute funktioniert, kann morgen anders aussehen. Was heute fehlt, kann übermorgen Standard sein.
Standardisierung und Interoperabilität
MCP ist offen, aber (noch) kein offizieller Standard im klassischen Sinne. Es gibt keine Normierungsstelle, kein Governance-Modell, keine festgelegte Roadmap. Dass mehrere große Anbieter – Anthropic, OpenAI, Microsoft – auf dasselbe Protokoll setzen, ist ein gutes Zeichen. Aber ob daraus ein stabiler, interoperabler Standard wird, ist offen.
Sicherheit und Governance
Wenn Sprachmodelle Schnittstellen ansprechen können, stellt sich zwangsläufig die Frage: Wer entscheidet eigentlich, was erlaubt ist? Und auf welcher Grundlage? MCP bietet technische Mechanismen zur Zugriffskontrolle – etwa über die Registrierung von Capabilities und deren Sichtbarkeit. Aber das reicht nicht aus. Unternehmen werden sich überlegen müssen, wie sie die Governance für KI-Zugriffe organisieren – und wie sie Missbrauch oder Fehlverhalten vorbeugen.
Verantwortung und Nachvollziehbarkeit
Ein Sprachmodell, das eigenständig mit APIs interagiert, handelt nicht deterministisch. Es interpretiert. Das kann im besten Fall sehr hilfreich sein – und im schlechtesten Fall zu unerwartetem Verhalten führen. Wer trägt in solchen Situationen die Verantwortung? Wer kann erklären, was passiert ist – und warum? Solche Fragen sind nicht neu, gewinnen aber mit MCP an praktischer Relevanz.
Organisatorische Auswirkungen
Nicht zuletzt stellt sich die Frage, wo solche Schnittstellen künftig verankert sind: im Entwicklungsteam? In der KI-Abteilung? Auf der Plattform? Und wer entscheidet, welche Capabilities angeboten werden – oder welche zu „offen“ sind? MCP ist keine rein technische Entscheidung, sondern eine, die Teams, Rollen und Prozesse berührt.
Was tun mit MCP? Erstmal: hinschauen
MCP ist kein Tool, das man mal eben installiert. Es ist auch keine Lösung, die heute schon überall einsatzbereit ist. Aber es ist ein Impuls – einer, der die Schnittstelle zwischen Mensch, KI und System neu denkt. Und wer über API-Strategien nachdenkt, sollte sich zumindest damit befassen.
Was kann das konkret heißen?
Entwicklungen beobachten – aktiv, nicht nur beiläufig
Die Dynamik rund um MCP ist hoch. Neue Integrationen, Tools und Spezifikationen entstehen fast wöchentlich. Es lohnt sich, gezielt zu beobachten, was sich tut – etwa in den Repositories auf GitHub, in den Marktplätzen oder in den Ankündigungen der großen Anbieter. Wer heute verfolgt, versteht morgen schneller, was möglich ist.
Kleine Experimente ermöglichen
MCP lässt sich in ersten Tests relativ unkompliziert ausprobieren – zum Beispiel mit einem eigenen, internen Context Server für ausgewählte Funktionen. Das schafft Sichtbarkeit im Unternehmen und hilft, Potenziale und Grenzen frühzeitig zu erkennen. Besonders wertvoll: Die Perspektive aus Produkt-, Plattform- und KI-Teams gemeinsam einbeziehen.
Zugänglichkeit als strategisches Ziel denken
Der vielleicht größte Effekt von MCP liegt nicht in der Technologie selbst, sondern im veränderten Zugang zu APIs. Wer seine Schnittstellen so beschreibt, dass ein Sprachmodell sie versteht, macht sie auch für neue Nutzergruppen zugänglich – ob intern oder extern. Das kann ein echter Hebel für Plattformstrategien und Developer Experience sein.
Voraussetzungen klären – technisch und organisatorisch
Früher oder später stellt sich die Frage: Wer verantwortet die Capabilities? Wer entscheidet, was zugänglich gemacht wird – und wie? MCP erfordert keine komplett neue Infrastruktur, aber ein neues Nachdenken über Rollen, Sichtbarkeit und Zugriff. Und das sollte besser früh passieren als zu spät.
Mehr als ein Standard – weniger als ein Hype
Das Model Context Protocol ist weder ein Allheilmittel noch ein vorübergehender Hype. Es ist ein ernst zu nehmender Versuch, Schnittstellen zugänglicher zu machen – nicht, indem sie einfacher werden, sondern indem sie besser erklärt werden. Für Maschinen.
Was daraus entsteht, ist mehr als ein technisches Detail. Es verschiebt, wie wir über APIs denken: weg von reinen Integrationspunkten, hin zu beschreibbaren Werkzeugen im Dienste der Nutzer*innen. Und es öffnet Räume – für neue Rollen, neue Nutzungen, neue Produkte.
Ob MCP in einem Jahr Standard sein wird oder eine von mehreren Ideen bleibt, lässt sich heute nicht sagen. Aber es ist ein guter Zeitpunkt, sich damit auseinanderzusetzen. Nicht, weil man muss – sondern weil man kann.
