MCP-Kontext in Claude Code: Tool behalten oder einen Befehl ausführen?
Eine überprüfbare Methode, den Kontextbeitrag eines MCP-Servers in Claude Code zu prüfen, ohne eine feste Token-Ersparnis zu behaupten.
Inhalt
MCP-Kontext in Claude Code: Tool behalten oder einen Befehl ausführen?
Ein MCP-Server hilft Claude Code beim Zugriff auf Systeme außerhalb des Arbeitsverzeichnisses: Tickets, interne APIs, Datenbanken oder Observability-Daten. Er erweitert aber auch die Sitzung um Tool-Namen, Beschreibungen, Eingabeschemas und mögliche Aktionen. Die Frage nach den Kontextkosten muss daher für eine bestimmte Aufgabe beantwortet werden: Ist wiederholbarer externer Zugriff nötig oder genügt eine kurze lokale Aktion?
Deaktivieren Sie nicht alle Server nach einer langen Antwort. Nehmen Sie eine kurze, wiederholbare Aufgabe ohne Seiteneffekt, messen Sie sie und beschränken Sie nur einen Server. Turns, benötigte Aufrufe und ein überprüfbares Ergebnis sagen mehr aus als das Gefühl, der Kontext sei zu groß.
Wenn Sie einen separaten Claude-Code-API-Workflow testen, öffnen Sie die aktuelle BetterToken-Anleitung, führen Sie denselben Prompt mit demselben Modell zweimal aus und vergleichen Sie anschließend im Dashboard Zeitpunkt, Modell, Status, Input-/Output-/Cache-Token und den angezeigten Verbrauch. So wird aus einer Vermutung über zu viel Kontext ein überprüfbarer A/B-Test. Beginnen Sie mit einem read-only Test und speichern Sie den API-Key nicht im Repository.
Wo zusätzlicher Kontext entsteht
Laut der MCP-Dokumentation von Claude Code verbinden Server externe Tools und Daten. Für das Modell zählt nicht nur das spätere Ergebnis eines Aufrufs: Bereits vor dem ersten Aufruf stehen Tool-Zweck, Parameter und Grenzen im Raum. Ein breiter Server mit vielen ungefilterten Tools erzeugt mehr Optionen, die der Agent einordnen muss.
MCP hat trotzdem keine feste „Token-Gebühr“. Die Messung hängt vom Server, aktivierten Tools, Prompt, Modell, Sitzungshistorie und Tool-Ergebnis ab. Unterscheiden Sie diese Fälle:
- Viele Tool-Schemas werden angeboten, obwohl keines benötigt wird.
- Ein Aufruf liefert ein langes Ergebnis, das weitere Turns lesen müssen.
- Ein unpräzises Ergebnis löst wiederholte Suchen oder Dateilesen aus.
- Nach dem Entfernen eines Tools fehlt eine externe Validierung und der Agent rät.
Keiner dieser Fälle beweist allein die Ursache jedes Tokens. Repository-Größe und bisherige History beeinflussen den Vergleich ebenfalls.
Kleinste nützliche Schnittstelle wählen
| Situation | Zuerst wählen | Grund |
|---|---|---|
| Tickets mehrfach lesen und aktualisieren | schmalen Tracker-MCP | Wiederholter Zugriff auf ein externes Objektmodell ist nötig. |
| Einen lokalen Prozessstatus prüfen | lokalen Befehl oder Statusdatei | Der Fakt liegt bereits im Workspace. |
| Interne API bei vielen Aufgaben lesen | read-only MCP mit kleinem Scope | Zugriff bleibt wiederholbar und prüfbar. |
| Ein Repository-Dokument öffnen | Suche und Datei lesen | Dafür ist kein externer Tool-Katalog nötig. |
| Externen Zustand ändern | zuerst manuelle oder read-only Prüfung | Autorisierung, Idempotenz und Ergebnisprüfung bleiben nötig. |
Nicht die Beliebtheit eines Servers entscheidet, sondern Häufigkeit und Datengrenze. Für einen einzelnen Arbeitsbaum-Status ist ein Befehl kleiner. Ein Befehl ersetzt aber keinen sicheren Zugriff auf ein System mit mehreren zusammenhängenden Operationen und festem Schema.
Eine vergleichbare Aufgabe messen
Wählen Sie eine Aufgabe ohne externen Seiteneffekt: Besitzer einer geänderten Datei finden, lokalen Status prüfen oder offene Vorgänge in einem Testprojekt lesen. Vergleichen Sie keine verschiedenen Aufgaben und leiten Sie aus einer ungewöhnlich langen Sitzung keine allgemeine Regel ab.
- Notieren Sie Prompt, Arbeitsverzeichnis und erwartetes Ergebnis, etwa: „Zeige geänderte Dateien und einen nächsten Schritt, ohne das Repository zu ändern.“
- Führen Sie sie mit dem aktuellen MCP-Profil aus. Erfassen Sie nur sichere Beobachtungen: Turns, verwendete Tools, Ergebnis und Zeitpunkt. API-Key,
.envund vollständige sensible Ausgaben bleiben außerhalb der Notiz. - Deaktivieren Sie in
/mcpgenau einen Server. Seine Konfiguration bleibt gespeichert und der Server wird als deaktiviert markiert. Schließen Sie die Sitzung, öffnen Sie eine frische Sitzung, prüfen Sie in/mcpden Status und wiederholen Sie exakt denselben Prompt. - Vergleichen Sie zuerst den erhaltenen Fakt. Hat der Agent dasselbe Nötige gefunden oder einen hilfreichen Aufruf durch eine Vermutung ersetzt?
- Aktivieren Sie den Server wieder, öffnen Sie eine frische Sitzung und prüfen Sie den Status. Stellen Sie ihn wieder her, wenn ohne ihn manuelles Kopieren nötig wird oder eine wichtige Prüfung fehlt. Behalten Sie die schmalere Konfiguration, wenn das Ergebnis erhalten bleibt und unnötige Aufrufe sinken.
Eine frische Sitzung ist entscheidend: Alte History enthält bereits Tool-Ergebnisse. Der Test misst keine universelle Claude-Code-Leistung, sondern Ihre übliche Aufgabe.
Ein wirklich vergleichbarer Befehl
Ersetzen Sie MCP nicht durch irgendeinen Befehl. Für einen lokalen Status kann dieser read-only Aufruf denselben Fakt liefern:
git status --shortFordern Sie in beiden Varianten nur die Liste geänderter Dateien und einen nächsten Schritt ohne Schreibzugriff an. Prompt und erwartete Liste bleiben gleich. Prüfen Sie erst die Liste, dann Turns, Aufrufe und Token. Liefert MCP einen externen Fakt, den git status nicht kennt, ist dies kein Ersatz: Behalten Sie einen engen read-only MCP oder dokumentieren Sie einen Befehl zum selben System.
Tool-Oberfläche und Risiko verringern
Ein Server kann viele Befehle anbieten, obwohl ein Projekt nur einen oder zwei braucht. Begrenzen Sie zunächst die Oberfläche:
- Für den ersten Test nur read-only Tools aktivieren.
- Nicht verwendete Integrationen abschalten.
- Profile für Entwicklung, Support und Administration trennen.
- Keine Secrets, langen Logs oder Gesprächshistorien in Tool-Beschreibungen geben.
- Seltene Vorgänge als kurze dokumentierte Befehle mit erwartetem Ergebnis führen.
MCP kann externe Daten lesen oder Aktionen auslösen; seine Konfiguration ersetzt weder Scope-Prüfung noch Kontrolle des Ergebnisses. Eine Modellantwort beweist nicht, dass eine externe Operation korrekt ausgeführt wurde.
Nutzung und Kosten sauber vergleichen
Für einen API-Test kann Claude Code mit dem eigenen BetterToken-Key konfiguriert werden. Prüfen Sie die aktuelle Claude-Code-Anleitung. BetterToken ist ein separater API-Zugang, kein Claude-Abonnement; der Key wird im eigenen Konto erstellt und gehört nicht in Repository, Handoff oder Versuchsprotokoll.
Im BetterToken Dashboard sehen Sie Zeitpunkt, Modell, Status sowie Input-, Output- und Cache-Token mit Verbrauch. Notieren Sie pro Lauf model, Datum und Uhrzeit, input, output, cache, angezeigten Verbrauch und Turns. Modell und Prompt müssen in beiden Läufen identisch sein.
Zeigt das Dashboard Kosten an, gilt: beobachtete Differenz = Verbrauch mit MCP − Verbrauch ohne MCP. Sind nur Token sichtbar, öffnen Sie zuerst die aktuelle Preisseite, notieren Datum, Modell und Cache-Regeln und verwenden Sie Kosten = input/1.000.000 × Pinput + output/1.000.000 × Poutput + cache/1.000.000 × Pcache nur bei separat ausgewiesenem Cache-Preis. Leere oder unklare Felder sind nicht null; alte Preise dürfen nicht wiederverwendet werden. Das Ergebnis ist eine Beobachtung zweier Läufe, keine feste MCP-Rate.
Entscheidung in der richtigen Reihenfolge prüfen
- Erforderlicher externer Fakt. Der Ersatz muss Ticket, Status, API-Datensatz oder Dokument wirklich abrufen, nicht vermuten.
- Korrektheit und Zugriff. Vergleichen Sie das erwartete Ergebnis und halten Sie den Test read-only, ohne neues Secret oder breiteren Scope.
- Erhaltene Validierung. Prüfen Sie, ob der Ersatz eine frühere Kontrolle entfernt hat; eine Modellantwort ist kein externer Nachweis.
- Erst dann Kosten. Vergleichen Sie Turns, Aufrufe, Input-/Output-/Cache-Token und Dashboard-Verbrauch bei gleichem Prompt in frischer Sitzung.
Scheitert einer der ersten drei Punkte, verbessert ein geringerer Verbrauch den Ablauf nicht: Die Aufgaben sind verschieden, oder ein Mensch übernimmt die verlorene Prüfung.
Wann neu entscheiden?
Aktivieren Sie den Server wieder, wenn sein Entfernen einen notwendigen externen Fakt verhindert, ungeprüfte Vorschläge erzeugt oder Menschen dieselben Daten in jeden Prompt kopieren lässt. Behalten Sie die schlankere Konfiguration, wenn das geforderte Ergebnis mit weniger unnötigen Aufrufen erhalten bleibt. Ein gutes MCP-Profil ist meist ruhig: Jedes aktive Tool hat eine wiederkehrende Aufgabe; für den Rest gibt es einen kurzen Befehl, ein Dokument oder eine manuelle Prüfung.
