Ich habe vor kurzem auf einem lokalen Meetup einen Talk über MCP gehalten — was funktioniert, was nicht, und worüber vorher niemand redet. Dieser Post geht tiefer als 30 Minuten Slides es erlauben.
Die Kurzfassung: MCP hat sich als De-facto-Standard für LLM Tool Calling durchgesetzt — also für die konkrete Frage, wie ein Modell eine Datenbank abfragt, eine API aufruft oder auf ein Dateisystem zugreift. Seit Dezember 2025 liegt es unter der Agentic AI Foundation der Linux Foundation, co-gegründet von Block und OpenAI, unterstützt von Google, Microsoft, AWS und Cloudflare. 97 Millionen monatliche SDK-Downloads. Über 10.000 öffentliche MCP-Server. Jede relevante IDE und AI-Plattform unterstützt es.
Aber Standard-Protokoll für Tool Calling werden und produktionsreif sein sind zwei verschiedene Dinge. Das Protokoll ist 16 Monate alt und die Auth-Spezifikation wurde in dieser Zeit dreimal von Grund auf neu geschrieben. Wer heute auf MCP baut, baut auf einem Standard, der sich noch selbst findet. Das ist kein Grund, es zu vermeiden — es gibt keine Alternative. Aber es ist ein Grund, bewusst zu entscheiden, wie man es einsetzt.
Vier Probleme, die euch begegnen werden
Nach mehreren MCP-Projekten haben sich vier Probleme herauskristallisiert, auf die jedes Team früher oder später stößt. Das sind keine Bugs. Es sind strukturelle Lücken im Design, die das Ökosystem erst jetzt zu schließen beginnt.
Die Speisekarte ist schwerer als das Essen
Jede Tool-Definition lebt im Kontextfenster des LLM. Alle gleichzeitig. Bevor der Agent irgendetwas Nützliches tut.
Der GitHub MCP Server hat aktuell knapp 100 Tools. Das sind rund 55.000–60.000 Tokens allein für Tool-Beschreibungen — ein einzelner Server. Wer mehrere MCP-Server verbindet, ist schnell bei sechsstelligen Token-Zahlen, bevor das eigentliche Prompt beginnt. Eine Analyse von Stacklok hat das Mitte 2025 durchgerechnet: damals drei Server (GitHub mit ~50 Tools, dazu Grafana und Notion), insgesamt 114 Tools und 240.600 Tokens Overhead. Heute, mit dem auf knapp 100 Tools gewachsenen GitHub-Server, wäre die Zahl noch deutlich höher.
Anthropic hat einen Workaround vorgeschlagen: Code-Stubs statt vollständiger Definitionen generieren, von 150K auf ~2K Tokens. Clever. Erfordert aber dynamische Code-Generierung zur Laufzeit — und damit hat jede zweite Enterprise-Compliance-Abteilung ein Problem.
Redis hat den praktischen Impact gemessen: Bei 50+ verfügbaren Tools sinkt die Selektionsgenauigkeit auf 42%. Filtert man auf die 3–5 relevanten Tools, springt sie auf 85%, Token-Verbrauch fällt von 23.000 auf 400, Latenz von 3,4 auf 0,4 Sekunden. Wer unseren Post über Skills vs. MCP gelesen hat, erkennt das Muster. Mehr Tools machen Agents nicht klüger. Ab einem Schwellwert von etwa 5–7 Tools pro Interaktion machen sie sie schlechter.
Niemand liest das Etikett
Eine Studie vom Februar 2026 hat 856 Tools aus 103 MCP-Servern analysiert: 89,8% hatten nicht dokumentierte Einschränkungen, 89,3% fehlten Nutzungsrichtlinien, 84,3% hatten unklare Parameter. Fast jedes Tool da draußen ist so schlecht beschrieben, dass das LLM suboptimale Entscheidungen trifft.
Die Konsequenzen sind vorhersehbar. Wenn drei Tools get_status, fetch_status und query_status heißen, wählt das Modell nach Token-Ähnlichkeit, nicht nach Bedeutung. Wenn Beschreibungen zu mehrdeutig sind, hat Microsoft festgestellt, dass Agents komplett einfrieren können — sie weigern sich zu handeln, weil die Auswahl zu unklar ist. Und wenn nichts passt, halluzinieren Agents Tool-Namen, die gar nicht existieren.
Das passiert, weil Tool-Beschreibungen als Dokumentations-Nebensache behandelt werden. Sie sind aus OpenAPI-Specs kopiert, geschrieben für menschliche Entwickler, nicht für LLM-Routing. Die Beschreibung ist das Interface — und fast niemand engineert sie.
Security war ein Nachgedanke
MCP wurde für Einfachheit und Erweiterbarkeit designt. Security kam später. Die Spec sagt wörtlich: “There SHOULD always be a human in the loop.” Simon Willisons Kommentar dazu: Behandelt diese SHOULDs als wären es MUSTs.
Die Angriffsfläche ist real. Tool-Beschreibungen können versteckte Anweisungen enthalten — sichtbar für das LLM, unsichtbar für den Nutzer. Ein Tool, das vorgibt, zwei Zahlen zu addieren, kann im Hintergrund die MCP-Konfiguration an einen externen Server schicken. Ein MCP-Server kann die Tools eines anderen Servers überschatten und Aufrufe abfangen, ohne dass der Nutzer es merkt. Und weil Tools sich nach der Installation umdefinieren können, kann ein Server, der an Tag eins harmlos ist, ab Tag sieben API-Keys exfiltrieren.
Das ist nicht theoretisch. Invariant Labs hat demonstriert, wie eine komplette WhatsApp-Historie über Tool-Metadaten abgegriffen werden kann. Im Juli 2025 hat Replits AI-Agent eine Produktionsdatenbank gelöscht — über 1.200 Datensätze, trotz explizitem Code-and-Action-Freeze. Als Knostic im Juli 2025 knapp 2.000 öffentlich erreichbare MCP-Server identifizierte und 119 davon manuell prüfte, hatte kein einziger irgendeine Form von Authentifizierung.
Prompt Injection steht auf Platz 1 der OWASP Top 10 für LLM Applications 2025. MCP Tool-Beschreibungen sind Prompt-Injection-Vektoren by Design.
Wem gehören die Schlüssel, wenn 50 Agents auf 50 APIs zugreifen?
Das ist das Problem, das Dennis Traub von AWS kürzlich auf den Punkt gebracht hat: Credential Management im Großen. Wenn Dutzende Agents Zugriff auf Slack, GitHub, Jira, das CRM und interne Tools brauchen, braucht jeder eigene API-Keys oder OAuth-Tokens. In frühen MCP-Setups — localhost, stdio, API-Keys in .env-Dateien — sind Credentials über Maschinen verteilt, werden per Chat geteilt, selten rotiert und sind komplett vom SSO entkoppelt.
Das Szenario, das Security-Teams den Schlaf raubt: Ein externer Mitarbeiter geht am Freitag. Sein SSO-Account wird deaktiviert. Aber drei Agents auf seinem Laptop halten noch API-Keys für CRM, interne Docs und die Deployment-Pipeline. Diese Credentials leben außerhalb des Identity-Perimeters.
Das ist das Problem zentraler Identitätsverwaltung, das Unternehmen mit SSO und föderierter Authentifizierung längst gelöst haben — aber MCPs frühe Architektur umgeht das alles. Der stdio-Transport kennt kein Konzept von Identity Delegation. Remote MCP-Server über HTTP können als Identity-Grenze dienen (Nutzer authentifizieren sich via OAuth durch SSO, ohne Downstream-Keys zu sehen), aber dafür braucht man Infrastruktur, die die meisten Teams noch nicht haben.
Der entstehende MCP-I-Standard (von Vouched an die Decentralized Identity Foundation übergeben) will das mit dreidimensionalem Nachweis lösen: Agent-Identität, Nutzer-Identität und ein maschinenlesbares Delegations-Credential. Das steckt noch in den Anfängen. In der Zwischenzeit ist die praktische Antwort: ein Gateway.
Das MCP Maturity Model
Als wir diese Probleme zusammen betrachtet haben, wurde ein Muster sichtbar. Sie sind nicht unabhängig voneinander. Sie sind Symptome von Adoption auf unterschiedlichen Reifegraden. Also haben wir ein Framework gebaut — lose inspiriert vom Richardson REST Maturity Model, einem der meistzitierten API-Design-Frameworks der Branche.
| Stufe | Name | Was es bedeutet |
|---|---|---|
| 0 | Kein MCP | Hardcodierte Integrationen. API-Keys in .env. Kein Standardprotokoll. |
| 1 | Auto-Generated | OpenAPI importiert, Tools automatisch generiert (z.B. via Gravitee). Null Aufwand, aber alle oben genannten Probleme. |
| 2 | MCP-Optimized | Zweckgebaute Endpunkte. Zusammengefasste Calls, kontextbewusste Antworten. Keine 1:1-Abbildung von REST-Operationen. |
| 3 | Semantically Rich | Tool-Beschreibungen engineert für LLM-Selektionsgenauigkeit. Prompt Engineering auf Tool-Ebene. Descriptions als First-Class-Artefakte. |
| 4 | Agentic Native | Multi-Agent-Flows. Explizite Pre-/Postconditions. Eingebaute Auth und Governance via Gateway. Tool-Filtering statt Tool-Flooding. |
Der zentrale Punkt: Stufe 1 erzeugt die Probleme. Stufe 3 und 4 lösen sie.
Auf Stufe 1 importiert man eine OpenAPI-Spec mit 80 Endpoints und bekommt 80 Tool-Beschreibungen in den Kontext geschüttet. Daher kommt die Token-Explosion. Daher kommen die schlechten Beschreibungen (es sind die OpenAPI-Summaries, geschrieben für menschliche Entwickler). Daher kommt das Identity-Problem (keine Governance-Schicht, kein Filtering).
Auf Stufe 3 behandelt man Tool-Beschreibungen als engineerte Artefakte — optimiert dafür, wie ein LLM Tools auswählt, nicht wie ein Mensch Dokumentation liest. Das adressiert direkt das Beschreibungsqualitäts-Problem.
Auf Stufe 4 kommt eine Governance-Schicht dazu: Tool-Filtering (nur die 5 relevanten Tools pro Request exponieren, nicht 80), zentralisierte Auth, Audit-Logging, Rate Limiting. Das adressiert Token-Explosion, Credential-Problem und Security.
Die meisten Teams, mit denen ich spreche, stehen auf Stufe 0 oder 1. Der Sprung zu Stufe 2 ist überschaubar. Stufe 3 erfordert ein Umdenken — Beschreibungen als Code behandeln, nicht als Kommentare. Stufe 4 erfordert Infrastruktur.
Was ein Gateway konkret bringt
Die Lücke zwischen Stufe 1 und 4 ist der Punkt, an dem ein MCP Gateway ins Spiel kommt. Wir arbeiten mit Gravitee, das protokoll-nativen MCP-Support in Version 4.8 eingeführt und in 4.10 deutlich ausgebaut hat. Ich tue nicht so, als wäre das eine neutrale Bewertung — wir sind Gravitee-Partner und haben uns bewusst dafür entschieden. Was ein Gateway wie dieses konkret leistet:
Bestehende APIs ohne Code-Änderungen zu MCP konvertieren. OpenAPI-Spec importieren, MCP-Entrypoint aktivieren, Agents können sich verbinden. Das ist Stufe 1 — aber der Ausgangspunkt.
Protokoll-bewusstes Traffic Management. Das Gateway behandelt MCP nicht als generisches HTTP. Es versteht tools/list, tools/call, prompts/list auf Method-Ebene. Das bedeutet Rate Limiting, Caching und Analytics, die tatsächlich verstehen, was passiert. tools/list-Responses können gecacht werden. tools/call kann pro Agent rate-limited werden. Tool-Beschreibungen werden gecacht, Tool-Ausführungen nicht.
Zentralisierte Identität. Das ist die Antwort auf das Credential-Zoo-Problem. OAuth 2.1 mit Dynamic Client Registration, PKCE, Audience Enforcement, kurzlebige Tokens. Agents authentifizieren sich über das Gateway; sie sehen nie die Downstream-API-Keys. Jemand verlässt das Unternehmen? Token am Gateway revoken. Fertig.
Feingranulare Autorisierung. Seit Version 4.10 unterstützt Gravitee OpenFGA-Integration (Relationship-based Access Control) und einen AuthZen Policy Decision Point für Echtzeit-Allow/Deny-Entscheidungen. Man kann einschränken, welche Agents welche Tools überhaupt sehen dürfen — nicht nur, welche sie aufrufen können.
Observability. Welche Tools rufen Agents tatsächlich auf? Wie oft? Mit welchen Fehlerraten? Ohne Gateway fliegt man blind. Mit Gateway bekommt man die gleiche Sichtbarkeit, die man von jeder Produktions-API erwartet.
Nichts davon ist MCP-spezifische Innovation. Es ist API Management, angewandt auf ein neues Protokoll. Und genau das ist der Punkt — MCP-Server sollten Auth, Rate Limiting und Observability nicht selbst neu erfinden müssen.
Was das für die Praxis bedeutet
Wer MCP für den Produktiveinsatz evaluiert, hier die komprimierte Version:
Nicht roh deployen. Ein Gateway vor die MCP-Server. Man würde eine REST-API auch nicht ohne eins ans Internet hängen, und hier gilt die gleiche Logik.
Wissen, wo man steht. Die meisten Teams sind auf Stufe 0 oder 1 im Maturity Model. Das ist als Startpunkt in Ordnung, aber man sollte die damit einhergehenden Probleme kennen. Den Weg zu Stufe 3 planen.
Beschreibungen als Code behandeln. Die größte Wirkung hat die Investition in Tool-Beschreibungsqualität. Testen. Iterieren. Selektionsgenauigkeit messen. Das ist Prompt Engineering auf Infrastrukturebene.
Tool-Exposition pro Request begrenzen. Wenn der Agent mehr als 10 Tools sieht, braucht man Filtering — ob über ein Gateway, eine Orchestrierungsschicht oder beides.
Identität jetzt zentralisieren. Das Credential-Zoo-Problem wird mit jedem zusätzlichen Agent und Server schlimmer. Auth zentralisieren, bevor es ein Incident-Report wird.
MCP ist die richtige Infrastruktur. Was fehlt, ist die Reife, sie gut einzusetzen. Das Protokoll wird sich weiterentwickeln (der MCP Dev Summit ist am 2.–3. April in New York, und die Tool-Versioning-Proposals SEP-1575 und SEP-1400 sind noch in Arbeit). In der Zwischenzeit gibt das Maturity Model einen Rahmen, um bewusste Entscheidungen zu treffen, statt die Probleme erst in der Produktion zu entdecken.