Am 11. März 2026 trat Perplexity-CTO Denis Yarats auf die Bühne der hauseigenen Ask-2026-Konferenz und verkündete, dass Perplexity intern von MCP abrückt. Die Ironie war sofort offensichtlich: Auf der eigenen Dokumentationsseite steht noch immer ein offizieller MCP-Server. Das Unternehmen, das eine MCP-Integration gebaut hatte, verabschiedete sich auf der eigenen Entwicklerkonferenz öffentlich davon und ersetzte MCP durch eine direkte Agent-API.
Perplexity steht damit nicht allein. Cloudflare hat MCP-Tool-Calling durch Code-Generierung ersetzt. Y-Combinator-CEO Garry Tan war so frustriert, dass er eine CLI-Alternative zusammengebaut hat. Google Workspace hat MCP-Support in Version 0.8.0 still und leise entfernt. Pieter Levels erklärte MCP für tot. Das Protokoll, das der USB-C-Standard für KI-Agenten werden sollte, erlebt seinen ersten ernsthaften Gegenwind. Und die Kritik ist technisch, konkret und durch Produktionsdaten belegt.
Die Token-Steuer: MCPs Context-Bloat-Problem
Der Kernvorwurf ist simple Mathematik. Jedes MCP-Tool sendet bei jeder Anfrage sein vollständiges Schema, Parameterdefinitionen und Beschreibungen an das Sprachmodell. Mehr Tools bedeuten mehr Token-Verbrauch, bevor der Agent auch nur eine einzige Nutzeranfrage verarbeitet.
Die Zahlen sind ernüchternd. Ein MySQL-MCP-Server mit 106 Tools erzeugt 207 KB Schemadaten, rund 54.600 Token bei der Initialisierung. Fünf MCP-Server mit je 30 Tools verbrauchen 30.000 bis 60.000 Token allein für Metadaten. Das sind 25-30 % eines typischen Kontextfensters, bevor die eigentliche Nutzeranfrage überhaupt verarbeitet wird.
Anthropic selbst hat Setups dokumentiert, in denen Tool-Definitionen allein 134.000 Token verbrauchten: ungefähr die Hälfte von Claudes gesamtem Kontextfenster. Nutzer auf Reddit haben einzelne Server vermessen: Linears MCP sendet 23 Tools mit rund 12.935 Token, JetBrains sendet 20 Tools mit 12.252 Token, und Playwright sendet 21 Tools mit 9.804 Token.
Warum das gravierender ist als es klingt
Token-Verbrauch ist nicht nur ein Kostenproblem. Forschungsergebnisse zeigen konsistent, dass die Zuverlässigkeit von Sprachmodellen negativ mit dem Umfang des instruktionalen Kontexts korreliert. Mehr Tool-Beschreibungen im Prompt bedeuten schlechtere Tool-Auswahl. Bill Prins Analyse ergab, dass bereits zwei MCP-Tools 20 % des Kontextfensters belegen, bevor die eigentliche Arbeit beginnt. Tau-Bench-Tests zeigten, dass Claude 3.7 Sonnet bei Flugbuchungsszenarien über MCP-Tools nur eine Aufgabenabschlussrate von 16 % erreicht, ein Wert, der in keinem Produktionssystem akzeptabel wäre.
Plattformen haben mit harten Limits reagiert. Cursor begrenzt auf etwa 80 Tools, OpenAI auf 128, Claude auf 120. Diese Grenzen existieren genau deshalb, weil Tool-Überladung die Leistung verschlechtert. Wer Zugang zu mehreren Diensten braucht, stößt schnell an diese Decke.
Perplexitys Ausstieg: Vom MCP-Server zur Agent-API
Perplexitys Abkehr ist die bisher prominenteste. Denis Yarats nannte zwei konkrete Probleme: Context-Overhead durch Tool-Definitionen, die das Arbeitsgedächtnis des Modells auffressen, und Authentifizierungsreibung durch MCPs dezentrales Auth-Modell, das bei der Integration Kopfschmerzen verursacht.
Der Ersatz ist die Perplexity Agent API: ein einziger Endpunkt unter POST https://api.perplexity.ai/v1/agent, der sechs Modellanbieter unterstützt (OpenAI, Anthropic, Google, xAI, NVIDIA, Perplexity) und integrierte Tools für Websuche (0,005 $/Aufruf), URL-Abruf (0,0005 $/Aufruf) und Function Calling (kostenlos) mitbringt. Die API ist OpenAI-SDK-kompatibel, Entwickler können Perplexitys Suchfähigkeiten mit einer einzigen Codezeile einbinden.
Das strategische Signal wiegt schwerer als die technischen Details. Perplexity hat einen MCP-Server gebaut, den Standard übernommen, ihn in Produktion genutzt und dann auf der eigenen Entwicklerkonferenz öffentlich aufgegeben. Das ist kein Unternehmen, das MCP nicht ausprobiert hat. Das ist ein Unternehmen, das es ausprobiert hat und entschieden hat, dass sich die Kompromisse nicht lohnen.
Cloudflares Code Mode: 99,9 % weniger Token
Cloudflares Antwort ist noch radikaler. Die Plattform hat über 2.500 API-Endpunkte. Alle als MCP-Tools abzubilden würde 1,17 Millionen Token verbrauchen. Stattdessen haben sie “Code Mode” gebaut: Der Agent bekommt nur zwei Tools, search() und execute(), die JavaScript-Code akzeptieren. Der Agent schreibt Code, der Cloudflares APIs direkt aufruft, mit rund 1.000 Token insgesamt.
Das ist eine Reduktion um 99,9 %. Cloudflare behält MCP für die Erkennung (welche APIs gibt es), hat aber den Tool-Calling-Mechanismus komplett durch Code-Generierung ersetzt. Theo Browne, der mit 480.000 YouTube-Abonnenten über Entwickler-Tools berichtet, fasste die Ironie zusammen: “Die Erfinder von MCP sagen uns, dass TypeScript-Code 99 % effektiver ist als ihre Spezifikation.”
Die Sicherheitsbilanz
Context Bloat ist ärgerlich. Sicherheitslücken sind gefährlich. MCP hat beides.
Im Januar 2026 wurden drei CVEs in Anthropics eigenem Git-MCP-Server offengelegt: CVE-2025-68143, CVE-2025-68144 und CVE-2025-68145. Das waren keine theoretischen Risiken. Sie ermöglichten Code-Ausführung, das Löschen beliebiger Dateien und das Laden unautorisierter Dateien in den KI-Kontext. Sie funktionierten ohne jede Konfiguration und ohne Zugangsdaten. Anthropic nahm die Meldungen im September 2024 entgegen und brauchte bis Dezember 2025 für die Patches.
Palo Altos Unit-42-Forschungsteam identifizierte drei Angriffsvektoren über MCP-Sampling: Ressourcendiebstahl, Konversationsentführung und verdeckten Tool-Aufruf. Sie bauten einen Proof-of-Concept für einen bösartigen Code-Summarizer, der unautorisierte writeFile-Operationen auslöste. Sicherheitsforscher Johann Rehberger bemerkte, dass die meisten eingesetzten MCP-Agenten die “tödliche Trias” aus Tool-Zugang, Datenzugang und Exfiltrationspfad aufweisen, was sie standardmäßig verwundbar macht.
Sechs strukturelle Schwächen
Eine Scalifi-AI-Analyse identifizierte sechs Designprobleme, die sich durch Patches nicht vollständig beheben lassen:
- Keine erzwungene Authentifizierung. MCPs Sicherheitsmodell ist Opt-in. Wenn ein Server keine Auth implementiert, gibt es keine Durchsetzung auf Protokollebene.
- Session-IDs in URL-Query-Strings. Ohne Message Signing können Sessions gekapert werden.
- Dynamische Tool-Manipulation. Server können Tool-Namen und -Beschreibungen ändern, nachdem der Nutzer die Berechtigung erteilt hat. Das ermöglicht “Rug Pull”-Angriffe.
- Geteilter Kontextraum. Mehrere Tools teilen sich denselben Kontext, was Remote-Poisoning über Tool-Grenzen hinweg ermöglicht.
- Keine Risikokategorisierung. Ein Tool, das eine Datei liest, und ein Tool, das eine Datenbank löscht, haben dasselbe Berechtigungsmodell.
- Zustandsbehaftetes Design. MCPs Session-basierte Architektur erschwert die Integration mit REST-basierter Infrastruktur.
Über 8.000 MCP-Server sind derzeit öffentlich im Internet erreichbar, mit genau diesen strukturellen Schwachstellen. Und 42 % der KI-Projekte scheitern Berichten zufolge bei der MCP-Implementierung, wobei die Sicherheitskomplexität als wesentlicher Faktor genannt wird. Für Unternehmen im DACH-Raum, die unter DSGVO und EU AI Act operieren, verschärft sich das Problem: Ein Protokoll ohne erzwungene Authentifizierung und mit bekannten Exfiltrationspfaden ist schwer mit den Anforderungen an technische und organisatorische Maßnahmen (TOMs) vereinbar.
Was Entwickler stattdessen einsetzen
Die Kritik hat drei unterschiedliche Alternativansätze hervorgebracht.
Direkte APIs und CLIs
Perplexitys Agent API, Garry Tans gstack (acht spezialisierte Claude-Code-Skills statt MCP) und OpenClaws bewusste “Bash statt MCP”-Architektur stehen alle für eine Rückkehr zur direkten Integration. Das Argument: Gut dokumentierte REST-APIs und CLI-Tools existieren bereits, Sprachmodelle sind inzwischen fähig genug, sie direkt zu nutzen, und die Protokollschicht erzeugt Overhead ohne ausreichenden Mehrwert.
Mario Zechners Ansatz ist noch schlanker: Markdown-Dateien mit Skriptbeispielen. Kein Protokoll, kein Schema, keine Serverprozesse. Nur Dokumentation, die das Sprachmodell lesen kann.
Code-Generierung statt Tool-Calling
Cloudflares Code Mode ist die Vorlage. Statt dem Agenten 2.500 einzelne Tools zu geben, bekommt er eine Code-Ausführungsumgebung und API-Dokumentation. Der Agent schreibt Code, der die APIs direkt aufruft. Steve Krouse erfasste die historische Ironie: “Wir haben mit OpenAPI-Specs angefangen, sie für MCP aufgegeben, weil LLMs nicht damit umgehen konnten, und jetzt, wo LLMs wieder mit Specs umgehen können…”
Dieser Ansatz skaliert besser, weil die Token-Kosten nicht linear mit der Anzahl verfügbarer APIs wachsen. Der Agent ruft nur die Dokumentation für die spezifischen Endpunkte ab, die er tatsächlich braucht.
Lazy Tool Hydration
Für Teams, die MCPs Standardisierungsvorteile behalten wollen, bietet Lazy Tool Hydration einen Mittelweg. Statt vollständige Schemas für alle Tools vorab zu senden, schickt man ein minimales Manifest mit nur Namen, Kategorien und Zusammenfassungen bei rund 4.900 Token. Wenn der Agent ein Tool auswählt, wird das vollständige Schema auf Anfrage bei etwa 400 Token pro Tool nachgeladen. Das ergibt eine Reduktion um 91 %, bei Beibehaltung von MCPs standardisierter Schnittstelle.
Anthropics eigener Claude Code nutzt inzwischen einen Tool-Search-Mechanismus, der sich aktiviert, wenn Tool-Beschreibungen mehr als 10 % des Kontexts belegen würden. Damit erreichen sie eine Token-Reduktion von 85 % bei großen Tool-Bibliotheken.
Das Gegenargument: Warum MCP trotzdem überleben könnte
Nicht alle sind bereit, den Nachruf zu schreiben. Charles Chens Analyse “MCP is Dead; Long Live MCP” argumentiert, dass das, was stirbt, MCP als universeller API-Wrapper in lokalen Stdio-Kontexten ist. Was überlebt, ist MCP über HTTP als Enterprise-Infrastruktur für zentralisiertes Agent-Tooling: Credential-Management, standardisierte Telemetrie, OAuth-basierte Zugangskontrolle und organisationsweite Wissensbereitstellung.
Matthew Hall vergleicht den aktuellen Moment mit der REST-Kritik um 1999, bevor REST SOAP ablöste. Die MCP-Spezifikation wurde erst im November 2025 veröffentlicht. Sechzehn Monate sind nicht genug, um ein Protokoll zu beurteilen, das die Linux Foundation jetzt pflegt und das weiterhin 97 Millionen monatliche SDK-Downloads und über 10.000 Server verzeichnet.
Das stärkste Argument für MCP ist das Fehlen eines einzelnen Ersatzes. Perplexity hat eine proprietäre API gebaut. Cloudflare hat eine eigene Code-Ausführungsschicht gebaut. Garry Tan hat CLI-Skills gebaut. Nichts davon sind interoperable Standards. Wenn MCP stirbt, fragmentiert das Agenten-Ökosystem in herstellerspezifische Integrationen, genau das Problem, das MCP lösen sollte.
Ob das relevant ist, hängt davon ab, ob man den Protokoll-Overhead als vorübergehende Steuer betrachtet, die mit der Reifung der Spezifikation sinkt, oder als strukturellen Fehler, der sich ohne Neuarchitektur nicht beheben lässt. Die Produktionsdaten stützen beide Sichtweisen.
Häufig gestellte Fragen
Warum wendet sich Perplexity von MCP ab?
Perplexity-CTO Denis Yarats gab auf der Ask-2026-Konferenz bekannt, dass das Unternehmen MCP intern aufgibt. Gründe sind der Context-Overhead durch Tool-Definitionen, die das Arbeitsgedächtnis des Modells belasten, und Authentifizierungsprobleme durch MCPs dezentrales Auth-Modell. Ersetzt wird es durch eine direkte Agent-API.
Wie viel Kontext verbrauchen MCP-Tools?
MCP-Tool-Definitionen verbrauchen erheblichen Platz im Kontextfenster. Ein MySQL-MCP-Server mit 106 Tools benötigt rund 54.600 Token. Fünf MCP-Server mit je 30 Tools können 30.000 bis 60.000 Token (25-30 % des Kontextfensters) allein für Metadaten verbrauchen, bevor der Agent eine Nutzeranfrage verarbeitet.
Was ist Cloudflares Code-Mode-Alternative zu MCP?
Cloudflares Code Mode ersetzt individuelles MCP-Tool-Calling durch Code-Generierung. Statt über 2.500 API-Endpunkte als separate Tools abzubilden (1,17 Millionen Token), erhält der Agent zwei Tools, die JavaScript-Code akzeptieren, bei insgesamt rund 1.000 Token. Das ergibt eine Reduktion um 99,9 %.
Ist das MCP-Protokoll tot?
MCP ist nicht tot, steht aber unter ernsthafter Kritik. Es verzeichnet weiterhin 97 Millionen monatliche SDK-Downloads und über 10.000 Server. Die prominenten Absagen von Perplexity, Cloudflare und anderen deuten jedoch darauf hin, dass das Protokoll vor allem als Enterprise-HTTP-Infrastruktur überleben könnte, nicht als universelle Tool-Integrationsschicht.
Was sind die wichtigsten Sicherheitslücken bei MCP?
MCP hat strukturelle Sicherheitsprobleme: keine erzwungene Authentifizierung (nur Opt-in), Session-IDs in URLs, dynamische Tool-Manipulation für Rug-Pull-Angriffe, geteilter Kontext für Cross-Tool-Poisoning und keine Risikokategorisierung zwischen Lese- und Löschoperationen. Drei CVEs in Anthropics eigenem Git-MCP-Server haben diese Risiken in der Praxis bestätigt.