Tool-Sprawl vermeiden, von 530 auf 30 MCP-Tools pro Session

Wenn Du Claude Code, Codex oder Cursor länger nutzt, sammelst Du MCP-Server an wie Tabs im Browser. GitHub MCP, Memory MCP, Filesystem MCP, Slack, Notion, Stripe, Brave-Search, dazu zwei oder drei eigene. Auf einmal hast Du 200+ Tools im Context, Dein Agent wählt das falsche aus, halluziniert Tool-Namen, oder bricht den Plan ab weil er sich verläuft. Das nennt sich Tool-Sprawl, und Anthropic hat im April 2026 die offiziellen MCP Client Best Practices genau dafuer veroeffentlicht.

Dieses Playbook bringt Dir 10 Schritte zum sauberen Tool-Routing. Du lernst wie Du Tools pro Agent zuordnest, wie Du den Context schlank haeltst auch wenn Du 30 Server installiert hast, und wie Du uberhaupt erst merkst dass Du im Sprawl bist. Funktioniert mit Claude Code, Cursor, Codex und jedem MCP-Host der Tool-Filtering unterstuetzt.

Bevor Du anfaengst: schau in den Lesson L4-06 "MCP Discovery und Marketplaces" und L6-07 "Multi-Agent Orchestrierung" rein. Da steht das Konzept warum, hier steht die Praxis wie.

Schritt 1, Inventur machen

Zaehl mal nach was Du angeschlossen hast. In Claude Code läuft claude mcp list, in Cursor schaust Du in ~/.cursor/mcp.json, in Codex das gleiche unter ~/.codex/config.toml. Schreib alle Server auf, dann pro Server die Tool-Anzahl. GitHub MCP allein bringt 19 Tools mit, Memory bringt 50+, eine vollstaendige Suite kommt schnell auf 200.

Mein eigenes Setup: 38 MCP-Server, 530 Tools wenn alle gleichzeitig laden würden. Macht das aber nicht, weil ich sie pro Aufgabe filtere. Ohne Filterung waeren das 80 Prozent meines Token-Budgets nur für Tool-Beschreibungen.

Schritt 2, das Tool-Sprawl-Problem verstehen

Drei Symptome zeigen Dir dass Du im Sprawl bist. Erstens, der Agent schreibt komplett halluzinierte Tool-Namen ("ich rufe github_create_issue_with_assignees auf" obwohl das Tool create_issue heisst). Zweitens, der Agent wählt das richtige Tool aber mit falschen Argumenten ("ich ubergebe repo_name" obwohl der Parameter repository heisst). Drittens, der Agent verliert den Plan ("Moment, ich prüfe erst mit Tool A, dann mit Tool B, dann mit Tool C..." und versickert in Meta-Steps).

Alle drei Symptome haben den gleichen Grund: zu viele Tool-Beschreibungen im Context, der Aufmerksamkeitsmechanismus verteilt sich. Anthropic spricht von "Token-Drift" und empfiehlt Tool-Filtering aktiv zu nutzen.

Schritt 3, das pickMcp-Pattern als Mental Model

Statt alle Server gleichzeitig in den Context zu laden, gibst Du jedem Agent oder jeder Aufgabe nur die 3-5 Server die er wirklich braucht. Bei mir heisst die Funktion pickMcp(role) und liefert pro Rolle eine getypte Liste.

Beispiel: Mein Research-Agent bekommt nur mcp-research (Web-Search), mcp-nex (Memory) und mcp-notion (Output). Mein Code-Review-Agent bekommt nur mcp-github, mcp-nex (Memory für frueheren Reviews), mcp-filesystem. Kein Agent bekommt alles.

Das Pattern funktioniert auch ohne Programmierung. Du kannst einfach Profile anlegen und manuell zwischen ihnen wechseln.

Schritt 4, Profile in Claude Code einrichten

Claude Code 2.1.119 hat persistente /config eingeführt, damit kannst Du pro Workspace eine andere MCP-Konfig haben. Leg Dir drei oder vier Profile an: research, code, ops, writing. Jedes Profil hat einen eigenen ~/.claude/profiles/<name>/mcp.json.

In jedem Profil definierst Du nur die Server die da reingehoeren. Research bekommt Such-Tools und Memory, Code bekommt GitHub plus Filesystem plus Memory, Ops bekommt Server-Connections plus Memory, Writing bekommt nur Memory plus Notion.

Wechsel mit claude --profile=research. Claude laedt nur die Server aus dem Profil, der Rest bleibt im Schrank.

Schritt 5, Tools innerhalb eines Servers filtern

Manche Server bringen 50+ Tools mit obwohl Du nur 5 davon brauchst. GitHub MCP zum Beispiel: ich nutze create_issue, search_issues, get_pull_request, create_pull_request, merge_pull_request. Die anderen 14 (Workflows, Releases, Org-Management) brauche ich selten.

Modernere MCP-Server unterstuetzen "Toolsets" oder "Filter-Flags" beim Start. GitHub MCP zum Beispiel --toolsets=issues,pull_requests. Schau in der Doku Deines Servers nach --enabled-tools oder --disabled-tools. Wenn der Server das nicht kann, ist das ein Wunsch für den Maintainer.

Schritt 6, Progressive Disclosure als Notbremse

Wenn Du wirklich viele Tools brauchst aber nicht gleichzeitig, hilft Progressive Disclosure. Konzept: Du startest mit einer Meta-Liste ("welche Kategorien hast Du da?") und der Agent fragt erst on-demand die Tools einer Kategorie nach.

Solo.io hat im April 2026 ein Pattern dazu publiziert. In der Praxis: Du baust einen kleinen Wrapper-MCP der erst eine Liste von Server-Namen returned. Der Agent wählt einen Server, dann lieferst Du die Tool-Liste dieses Servers nach. Kostet einen Round-Trip, spart 80 Prozent Token im Default-Fall.

Nicht jeder braucht das. Wer mit 30 Tools auskommt, kann diesen Schritt uberspringen.

Schritt 7, Memory als Sprawl-Reducer

Memory ist gegen Tool-Sprawl Dein bester Freund. Statt drei Tools die alle "Notizen schreiben" können (Notion, Apple Notes, Markdown), hast Du ein einziges Memory-MCP das alles abdeckt. Statt vier Tools die "Search" machen (Google, Bing, Brave, Perplexity), hast Du mcp-research mit einer einheitlichen Schnittstelle.

Das ist der Zentralisierungs-Hebel. Prüfe in Deiner Liste aus Schritt 1 wo Du redundante Tools hast und konsolidier.

Schritt 8, Naming-Konflikte aufspueren

Wenn zwei Server beide ein Tool namens search haben, halluziniert der Agent garantiert. Das ist der unterschaetzte Killer. GitHub MCP hat search_issues, Brave-Search hat search, manche Memory-Server haben search_memories. Der Agent verliert den Uberblick wer was kann.

Loesung: pro MCP-Server einen klaren Tool-Prefix setzen falls der Server das unterstuetzt (github_search_issues statt search_issues). Wenn nicht, dann mindestens beim Zusammenstellen der Profile aufpassen dass nicht zwei Search-Tools im selben Profil landen.

Schritt 9, das eigene Setup messen

Bau Dir ein kleines Mess-Skript. Bei mir läuft das so: nach jeder Session dump ich die Anzahl Tool-Calls plus die Tool-Namen plus ob der Call erfolgreich war (kein Halluzinations-Fehler). Daraus sehe ich monatlich welche Tools nie genutzt werden, welche oft halluziniert werden, welche immer in Kombination mit welchen anderen verwendet werden.

Tools die in 30 Tagen Null-Mal genutzt wurden: raus aus dem Profil. Tools die in 30 Tagen mehr als 3-Mal halluziniert wurden: Naming prüfen oder Doku verbessern.

Manche MCP-Hosts haben eingebaute Telemetrie, andere nicht. Wenn nicht, eigenes Logging an den Server-Wrapper.

Schritt 10, Default-Profil als Selbstdisziplin

Mein Default-Profil hat genau drei Server. mcp-nex (Memory), mcp-filesystem (Lesen/Schreiben lokal), mcp-research (Web). 30 Tools insgesamt. Wenn ich mehr brauche, wechsel ich aktiv mit claude --profile=....

Diese Entscheidung "default ist klein, mehr nur auf Anfrage" ist die wichtigste Disziplin. Anfaenger wollen alles immer dabei haben für den Fall der Faelle. Profis wissen dass weniger Context = bessere Ergebnisse, und der Schalter zwischen Profilen ist eine Sache von 5 Sekunden.

Was als naechstes

Wenn Du Memory noch nicht aufgesetzt hast, geh ueber Playbook "Memory portabel nutzen". Wenn Du eigene MCP-Server bauen willst, Lesson L6-01 bis L6-08 plus Playbook "Erster MCP-Server in 90 Minuten". Wenn Du tiefer in Sub-Agents willst (jeder mit eigenem Profil), Playbook "Erster Sub-Agent in 30 Minuten".

Quellen: Anthropic MCP Client Best Practices, modelcontextprotocol.io/docs/develop/clients/client-best-practices. Solo.io Progressive Disclosure Artikel April 2026. Eigenes pickMcp-Pattern dokumentiert in agents/lib/mcp-config.ts.