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.