← Zum Blog
Blog

Was mcp_tool Hooks für mich ändern, nach zwei Wochen im Realbetrieb

Claude Code 2.1.118 hat den direkten MCP-Tool-Aufruf in Hooks gebracht. Wie sich mein Memory-Workflow umgebaut hat, mit Zahlen aus dem Pilotbetrieb.

12. Mai 2026
Bash-Wrapper-Hooks waren bis Mitte April mein einziger Hebel, dem Modell Memory-Operations beizubringen. Drei Stück hatte ich produktiv: einer auf Stop, einer auf PreCompact, einer auf UserPromptSubmit. Alle drei haben funktioniert. Manchmal. Konkret: 47 Sessions über zwei Wochen vermessen. 38 sauber durchgelaufen. 6 ignoriert, das Modell hat den Reminder gelesen und ist trotzdem rausgegangen. 3 falsches Tool aufgerufen, nex_recall statt nex_summarize, weil "Recall" näher am Promptkontext war. Macht 19 Prozent Failure-Rate. Auf 2 von 10 Sessions hat Memory am Ende eine Lücke. Am 23. April kam Claude Code 2.1.118 mit `type: "mcp_tool"`. Direkter Tool-Aufruf, ohne dass das Modell zwischendrin entscheidet. Ich hatte zwei Wochen Zeit zum Umbauen und Vermessen. Hier kommt was sich praktisch geändert hat. ## Der Unterschied in einer Zeile Vorher musste der Bash-Hook dem Modell eine Notiz reinschieben, irgendwas in der Art "Bitte ruf jetzt nex_summarize auf bevor Du gehst". Das Modell liest die Notiz und entscheidet. Manchmal entscheidet es anders. Jetzt steht der Tool-Call direkt in `~/.claude/settings.json`: ```json { "type": "mcp_tool", "server": "studiomeyer-memory", "tool": "nex_summarize", "input": { "session_id": "${session_id}" }, "timeout": 60 } ``` Claude Code feuert den Tool-Call selbst. Kein Modell zwischendrin, keine Interpretation, keine Toolnamen-Verwechslung. Wenn der Server da ist, läuft es. Wenn nicht, log und weiter. So sollte es immer gewesen sein. ## Was ich falsch gemacht hab beim ersten Umbau Erste Iteration: ich hab alle drei Bash-Hooks 1:1 in mcp_tool-Hooks übersetzt. Plus zwei neue, weil "geht ja jetzt eh deterministisch". Macht fünf Hooks parallel auf Stop, PreCompact, UserPromptSubmit, SubagentStop, SessionStart. Result: 8 von 10 Sessions hatten doppelte Memory-Einträge. Mein `crm_create_company` war als idempotent angenommen, ist es aber nicht. Jeder Hook-Fire hat eine neue Company-Row in der CRM angelegt. Nach drei Tagen Pilotbetrieb 412 doppelte Companies in der Test-Datenbank. Mein Fehler, nicht der von Claude Code. Lesson eins: idempotent ist nicht "ich glaube das ist sicher". Idempotent ist "ich hab nachgeschaut und es macht beim zweiten Aufruf nichts mehr". Vor jedem Hook eine 5-Punkte-Prüfung, Idempotenz, Latenz, Determinismus, Side-Effect, DSGVO. Diese Prüfung ist die wichtigste Änderung, nicht das JSON-Schema. Lesson zwei: weniger Hooks. Ich bin von fünf zurück auf vier. Memory braucht vier Hooks, das reicht. Mehr ist Overkill und produziert Drift. ## Die zweite Pilotwoche, andere Zahlen Nach Cleanup und Reduce-to-Four: 32 Sessions über 7 Tage. 32 saubere Memory-Summaries. Null Tool-Verwechslung, es gibt nichts zu verwechseln, Claude Code ruft genau das Tool auf das im JSON steht. Latenz median 380ms, P95 1.2 Sekunden. Failure-Rate bei 0 Prozent, solange der Memory-Server live war. Einmal war der MCP-Server beim Restart 12 Sekunden weg. Hook hat gewartet, dann Timeout, dann Log, dann weiter. Genau wie geplant. Das ist das was Bash-Wrapper nie konnte, weil das Modell den Reminder dann gar nicht gesehen hat. ## Was nicht passt Nicht jeder Workflow gehört in einen mcp_tool Hook. Drei Fälle wo ich bei Bash bleibe. Du brauchst mehrere Tool-Calls mit Logik dazwischen, "wenn A, dann B". Bash-Hook mit ein bisschen jq. Mcp_tool kann nur einen Call pro Hook. Du willst etwas aufrufen das kein MCP-Tool ist, curl an einen Custom-Endpoint, ein eigenes Python-Script. Geht nur über Bash. Du willst das Tool-Result inspizieren bevor Du weitermachst. Mcp_tool feuert und vergisst. Bash kann das Result lesen und Folgeaktionen auslösen. Faustregel: ein klar definierter, idempotenter, deterministischer Tool-Call passt in mcp_tool. Alles andere bleibt Bash. ## Was bei mir jetzt live läuft Vier Hooks, klar abgegrenzt, jeder mit dokumentiertem Use-Case. Stop ruft `nex_summarize`. Nach jeder Session ein Memory-Snapshot. PreCompact ruft auch `nex_summarize`. Bevor Context komprimiert wird, persistieren wir den State. UserPromptSubmit ruft `nex_search` bei Trigger-Phrase ("erinner Dich an"). Spart mir das manuelle Recall. SubagentStop ruft `nex_learn` mit category research. Subagents werfen Research-Findings direkt in die Knowledge-Base. Mehr nicht. Ich hatte fünf, dann vier, ich teste gerade ob drei reichen. ## Wie Du anfängst Wenn Du Memory bisher nur manuell genutzt hast, beginn mit einem Hook. Stop ruft `nex_summarize`. Das ist der Eintrag mit dem höchsten Nutzen pro JSON-Zeile. Die anderen kommen wenn der erste sauber läuft. In der Academy haben wir das jetzt in Lesson 4-10 (Memory + MCP Layer) und im Playbook hooks-gegen-halluzinationen ausführlich. Wer eine fertige Recipe will, Phase 16 hat die fünf Bundles für Memory, CRM, GEO, Crew und Academy. Cross-Link: [Lektion 4.10: mcp_tool Hooks](/levels/4/mcp-tool-hooks) für die Lesson, [Playbook: Hooks gegen Halluzinationen](/playbooks/hooks-gegen-halluzinationen) für die Anti-Pattern-Liste. Quelle für alle Field-Namen und Schema-Details, die offizielle [Claude Code Hooks Reference](https://code.claude.com/docs/en/hooks). Wenn Du den Hook produktiv setzt, lies das einmal komplett, nicht nur den mcp_tool-Abschnitt.
← Weitere Blog-Posts