Zum Inhalt springen

Wissensbasis

MCP: Protokoll und Kontextkosten

Was MCP standardisiert, wer es nutzt und wie viel vom Kontextfenster seine Tool-Schemas belegen. Dazu Wege, Tools erst zu laden, wenn eine Aufgabe sie braucht.

Verfasst von

Aktualisiert:

Tools 4

Unsere Position. Wir nutzen MCP für externe Integrationen (öffnet in einem neuen Tab) wie Issue-Tracker, Datenbanken, Chat und APIs von Drittanbietern. Jeder verbundene Server bringt Fähigkeiten und kostet Kontext-Token. Deshalb laden wir MCP-Server explizit pro Aufgabe (öffnet in einem neuen Tab) und verbinden, was die Aufgabe braucht, statt alles, was verfügbar ist.

Was standardisiert MCP, und wer nutzt es?

MCP löst ein echtes Integrationsproblem. Entwickler:innen bauen keinen eigenen Connector mehr für jede Kombination aus Agent und Tool. Sie implementieren das Protokoll einmal und erreichen damit ein ganzes Ökosystem. Seit dem Start im November 2024 hat sich MCP schnell verbreitet. Agents verbinden sich heute routinemäßig mit Hunderten oder Tausenden Tools auf Dutzenden Servern (Anthropic - Code execution with MCP (öffnet in einem neuen Tab)). Ein Nebeneffekt: Jeder Server, den jemand für einen Client baut, wird zum Plugin für alles, was das Protokoll spricht. So wird MCP zu einem versehentlich universellen Pluginsystem. Fähigkeiten summieren sich im ganzen Ökosystem, ohne dass sich die Autor:innen abstimmen (Works on My Machine - MCP: An (Accidentally) Universal Plugin System (öffnet in einem neuen Tab)).

In großen Unternehmen zeigt sich das Muster als interne Tool-Plattform. Stripe betreibt einen “tool shed” mit rund 500 MCP-Tools und wählt per Meta-Tool aus. Shopify betreibt mehr als 100 interne MCP-Integrationen (KI-Produktivitätsstudien).

Das Protokoll wandert außerdem über Entwicklungstools hinaus ins Web. WebMCP ist in Chrome als Early Preview verfügbar. Es schlägt deklarative und imperative APIs vor, über die Websites strukturierte Tools direkt für Browser-Agents bereitstellen. Bei Flows wie Checkout oder Support-Tickets ersetzt das die fragile Steuerung über das rohe DOM (Chrome for Developers - WebMCP is available for early preview (öffnet in einem neuen Tab)).

Agents, die eine UI bedienen, zeigen im Vergleich, warum Zugriff per Protokoll überzeugt. Perplexitys Browser-Agent Comet macht bei jedem Klick einen Screenshot. Per Bilderkennung sucht er dann das nächste Ziel und macht weiter. Eine Suche nach Ferienwohnungen auf fünf Plattformen dauerte so etwa dreißig Minuten und brachte ein schwaches Ergebnis. Das Beispiel zeigt konkret, warum strukturierte Tools für Agents im Web besser funktionieren als Screen Scraping (OMR State Of The Internet 2026 (öffnet in einem neuen Tab), 7. Mai 2026).

Das Protokoll selbst hat einen überschaubaren Umfang. Ein MCP-Server stellt drei Arten von Primitiven bereit, also mehr als aufrufbare Tools:

  • Tools: ausführbare Funktionen
  • Resources: Dateien oder Datensätze, die der Agent lesen kann
  • Prompts: wiederverwendbare Vorlagen

Server laufen lokal, remote oder als Managed Service, den jemand anderes hostet (Scalable AI with Multi-Agent Systems and MCP (öffnet in einem neuen Tab)). Der Transport ist bewusst schlank. Lokale Server sprechen JSON-RPC über stdio, praktisch ohne Netzwerk-Overhead. Remote-Server nutzen HTTP vom Client zum Server und Server-Sent Events zurück. Dafür braucht ihr dann auch einen Webserver und Auth (Walkthrough zum Docker MCP Toolkit (öffnet in einem neuen Tab)). Der MCP Inspector prüft Tools, Resources und Prompts eines Servers, bevor ihr ihn an einen Client anbindet. Discovery ist noch nicht ausgereift. Anthropic hat eine MCP Registry in Aussicht gestellt, damit Clients den passenden Server für eine Aufgabe selbst finden und keine manuelle Konfiguration mehr brauchen (Scalable AI with Multi-Agent Systems and MCP (öffnet in einem neuen Tab)).

Nicht alle glauben an diese Entwicklung. Eine ausführliche Kritik hält das “NxM problem”, das MCP lösen will, durch bestehende SDK-Abstraktionen für weitgehend erledigt. Eigene langlebige Serverprozesse brächten Probleme bei Runtime, Debugging und Supply Chain, darunter mehrere CVEs mit hohem Schweregrad in beliebten Servern. Die meisten veröffentlichten Server seien dünne API-Wrapper, die ein Coding-Agent in einem Anlauf als lokales Skript schreiben könnte. Die Prognose lautet, dass Skills, Command Runner und schlichtes OpenAPI die Rolle von MCP nach und nach verkleinern (MCP is a Fad (öffnet in einem neuen Tab)). Ob die starke Fassung dieser These hält oder nicht: Die Sicherheits- und Betriebsprobleme, die sie auflistet, beruhen auf echten Vorfällen. Sie gehören in jede Diskussion über eine MCP-Einführung.

Wie viel Kontext belegen MCP-Tool-Schemas?

Der zentrale Tradeoff von MCP ist der Kontext. Die meisten Clients laden alle Tool-Definitionen vorab. Diese Definitionen wirken wie “billboards” und belegen Kontext, auch wenn niemand die Tools aufruft (Claude Code). Die gemessenen Zahlen sind durchweg groß:

Große Toolboxen kosten mehr als Token, sie verwirren die Agents auch. Tools aus beliebigen Quellen wissen nicht, was sonst in der Toolbox liegt. Ihre Beschreibungen können deshalb nicht klären, wann welches Tool passt. Mit wachsender Zahl der Tools wählen Agents messbar schlechter aus (MCP is a Fad (öffnet in einem neuen Tab)). Praktiker:innen empfehlen durchgängig weniger MCP-Server, die ihr bewusst ladet, denn weniger Server liefern bessere Ergebnisse (KI-Produktivitätsstudien).

Die Gegenmittel sind gut dokumentiert (Claude Code):

  • Löscht die Standard-.mcp.json.
  • Ladet Server bei Bedarf mit claude --mcp-config <file>.
  • Blockiert globale Server mit --strict-mcp-config.
  • Teilt Server auf Config-Dateien pro Zweck auf, auch in Varianten nur zum Lesen und mit Schreibzugriff.
  • Prüft den Kontextverbrauch mit /context.

Dynamische Discovery geht weiter. Eine CLI-Schicht lädt Schemas nicht mehr statisch. Sie listet die Server auf, holt das Schema eines bestimmten Tools und führt es erst aus, wenn es gebraucht wird. Im gemessenen Szenario sank der MCP-bezogene Token-Verbrauch damit um rund 99 % (Introducing MCP CLI (öffnet in einem neuen Tab)).

Im November 2025 hat Anthropic dieses Muster als Teil der eigenen Plattform ausgeliefert, das Tool Search Tool. Es lädt vorab nur ein kleines Suchtool mit rund 500 Token. Alle anderen Tools tragen defer_loading: true und werden bei Bedarf gefunden, statt im Kontext zu landen (Anthropic - Advanced tool use (öffnet in einem neuen Tab)). Anthropics Beispiel mit fünf Servern umfasst schon 58 Tools und rund 55.000 Token an Definitionen, Jira allein käme mit etwa 17.000 hinzu. In Anthropics Vergleich verbrauchten die vorab geladenen Definitionen für mehr als 50 MCP-Tools rund 77.000 Token vor dem ersten Arbeitsschritt, mit dem Tool Search Tool etwa 8.700. Anthropic nennt das ein Minus von 85 %, rechnerisch ergeben die beiden Zahlen etwa 89 %. Gleichzeitig stieg die gemessene Genauigkeit bei der Tool-Auswahl:

  • Opus 4 von 49 % auf 74 %
  • Opus 4.5 von 79,5 % auf 88,1 %

Zurückgestellte Tools gelangen nie in den ersten Prompt, deshalb bleibt auch das Prompt Caching erhalten. Diese Angaben stammen vom 24. November 2025 und sind eine Herstellerangabe zur eigenen Plattform.

Der Hersteller rät, die drei bis fünf meistgenutzten Tools immer zu laden und den Rest zurückzustellen. Greifen solltet ihr zu dem Muster, sobald die Tool-Definitionen mehr als rund 10.000 Token belegen oder mehr als rund 10 Tools umfassen (Anthropic - Advanced tool use (öffnet in einem neuen Tab)). Es zielt dabei auf mehr als Token-Kosten. Ein häufiger Fehler ist die falsche Tool-Auswahl, wenn Namen kollidieren, etwa notification-send-user und notification-send-channel (Anthropic - Advanced tool use (öffnet in einem neuen Tab)).

Verwandte Seiten

Quellen

Artikel

Posts

Talks und Videos