Wenn KI-Agenten ernsthaft arbeiten sollen, brauchen sie Zugriff auf Systeme: Repositories, Tickets, Dokumente, Datenbanken, interne APIs. Die Frage ist nicht mehr, ob Agenten Tools nutzen. Die Frage ist, wie diese Tools sauber, portabel und kontrollierbar angebunden werden.
Genau hier wird das Model Context Protocol interessant. MCP ist kein weiteres Prompt-Pattern und auch kein einzelnes Agenten-Framework. Es ist eine Standardschnittstelle zwischen einem KI-Host und externen Kontext- oder Aktionsquellen. Für mich ist MCP deshalb weniger „noch eine Integration“ als ein Architekturbaustein: ein gemeinsamer Vertrag, über den Agenten Systeme entdecken, lesen und ansteuern können.
Das Problem: jede KI braucht Kontext, aber Integrationen skalieren schlecht
Ohne gemeinsamen Standard entsteht schnell ein Integrationsproblem. Ein Team baut eine Jira-Anbindung für Tool A. Ein anderes baut eine SharePoint-Anbindung für Tool B. Ein drittes Team braucht dieselbe Datenbank in Tool C. Jede Integration hat eigene Authentifizierung, eigene Tool-Beschreibung, eigene Fehlerbehandlung und eigene Sicherheitsannahmen.
Das ist nicht nur ineffizient. Es erhöht auch Risiko. Je öfter ich dieselbe Verbindung neu baue, desto öfter muss ich Berechtigungen, Secrets, Logging, Datengrenzen und Tool-Schemas neu entscheiden. MCP verschiebt diese Wiederholung auf eine Protokollebene: Ein Server beschreibt seine Fähigkeiten standardisiert, und ein MCP-fähiger Host kann sie nutzen.
Meine Kurzfassung: MCP ist USB-C für agentische KI-Integrationen. Nicht, weil es alles löst, sondern weil es den Anschluss vereinheitlicht.
Die Rollen: Host, Client, Server
Die MCP-Architektur ist bewusst einfach. Sie unterscheidet zwischen Host, Client und Server. Diese Trennung ist der Grund, warum MCP als portabler Standard funktioniert.
Wichtig ist: Der Server muss nicht wissen, ob er gerade von Cursor, Claude Code, Codex, GitHub Copilot oder einem internen Agenten genutzt wird. Er stellt Fähigkeiten über MCP bereit. Der Host entscheidet, welche davon er in welchem Kontext nutzt.
Die drei Primitive: Tools, Resources, Prompts
Ein MCP-Server beschreibt seine Fähigkeiten über drei zentrale Primitive. Genau diese Unterscheidung macht MCP praktisch: Nicht alles ist ein Tool-Aufruf. Manches ist lesbarer Kontext, manches ist eine wiederverwendbare Vorlage, manches verändert tatsächlich Zustand.
Warum MCP für KI-Coding so relevant ist
KI-Coding lebt von Kontext. Der Agent muss nicht nur den aktuellen Code sehen, sondern oft auch Tickets, Architekturentscheidungen, Logs, Deployment-Status, Cloud-Ressourcen, Feature-Flags und Dokumentation. MCP macht solche Quellen nicht automatisch richtig, aber es macht sie standardisiert erreichbar.
Das verändert die Integrationslogik. Statt jede IDE, jeden Agenten und jedes interne System paarweise miteinander zu verdrahten, kann ein Team einen MCP-Server für eine Domäne bauen. Derselbe Server kann danach in mehreren MCP-fähigen Hosts verwendet werden. Das reduziert Lock-in auf der Protokollebene und verschiebt die eigentliche Differenzierung auf Tool-Qualität, Berechtigungen, UX und Governance.
Ein praktisches Beispiel
Ein Beratungsteam baut einen MCP-Server für Kundenarbeit. Der Server bietet drei Tools: Kundendatensatz lesen, Angebotsentwurf erzeugen, Beraterauslastung abfragen. Zusätzlich stellt er Resources für Vertragsvorlagen und Prompts für Angebotsreviews bereit.
Am Montag nutzt Engineering denselben Server aus einem Coding-Tool heraus, um eine technische Änderung mit Kundenvorgaben abzugleichen. Am Dienstag nutzt Pre-Sales ihn aus einem anderen KI-Host, um einen Angebotsentwurf zu prüfen. Sechs Monate später wechselt ein Team den KI-Host. Der MCP-Server bleibt gleich.
Das ist der eigentliche Charme: MCP macht Integrationen nicht wertlos, sondern langlebiger. Die Investition wandert vom einzelnen Tool in eine gemeinsame Integrationsschicht.
Was MCP löst und was nicht
Ich halte MCP für wichtig, aber nicht für magisch. Ein standardisiertes Protokoll löst Anschlussfähigkeit. Es löst nicht automatisch Tool-Design, Berechtigungen, Datenschutz, Prompt-Injection-Schutz, Observability oder fachliche Qualität.
Der wichtigste Architekturgedanke
Für mich ist MCP vor allem eine Entkopplung. Der Agent muss nicht wissen, wie ein internes System technisch funktioniert. Der Host muss nicht jede Domäne individuell implementieren. Der Server muss nicht für jeden Host neu geschrieben werden. Die Schnittstelle dazwischen ist standardisiert.
Das macht KI-Coding erwachsener. Statt Agenten immer mehr Kontext blind ins Prompt-Fenster zu kippen, können wir Kontext und Aktionen gezielt bereitstellen. Ein Server kann genau definieren, welche Daten lesbar sind, welche Aktionen möglich sind, welche Parameter erlaubt sind und welche Rückgaben erwartet werden.
Worauf ich bei MCP-Servern achten würde
Ein guter MCP-Server ist nicht der, der möglichst viele Tools anbietet. Er bietet die richtigen Tools mit klaren Schemas, engen Berechtigungen, verständlichen Fehlermeldungen und guter Beobachtbarkeit. Gerade bei internen Systemen ist weniger oft besser: lieber fünf robuste Tools als dreißig halbgare Aktionen mit unklarer Wirkung.
Ich würde jeden MCP-Server wie eine kleine Produkt-API behandeln: klare Domäne, Versionierung, Tests, Logging, Berechtigungsmodell, dokumentierte Grenzen und bewusstes Fehlverhalten. Sonst wird MCP nur eine hübsche Verpackung für dieselben alten Integrationsprobleme.
Fazit
MCP ist wichtig, weil es eine gemeinsame Sprache für Agenten und Systeme schafft. Es nimmt uns nicht die Architekturarbeit ab, aber es macht sie an der richtigen Stelle möglich. Für KI-Coding bedeutet das: weniger Tool-spezifische Einzellösungen, mehr portable Integrationsschichten, klarere Tool-Verträge und bessere Chancen auf kontrollierbare Agentenarbeit.
Der Unterschied ist subtil, aber entscheidend: MCP macht nicht den Agenten intelligent. MCP macht die Umgebung lesbar und bedienbar. Genau das ist die Voraussetzung dafür, dass agentische Schleifen mehr tun können als nur plausibel klingen.