DEV Community

Harris Ahmad
Harris Ahmad

Posted on

MCP tools are model-elective. Hooks aren't. That distinction turned out to matter more than I expected.

An MCP server can expose the perfect tool and the model can simply not call it. Nothing is wrong, nothing errors — the information just doesn't arrive. Hooks are the opposite: the harness runs them, so whatever they return lands in context whether the model asked or not.

I got stuck on this while trying to solve a specific problem: I'd change a base image or a Terraform module in one repo, and only find out later that three other repos pinned the same thing. The knowledge existed, it just wasn't anywhere the agent would look.

So I built the thing as a hook rather than a tool. A PreToolUse hook fires when a manifest is read and pushes cross-repo impact in unprompted; a Stop hook captures what the session learned. Extraction stays the model's job — it handles multi-stage aliases, ARG-templated bases and FROM inside a heredoc that my regex attempts got wrong.

What I can actually back up, measured against a fixture corpus with 19 deliberate traps planted in it:

39/39 artifacts extracted, 39/39 version specs intact (a model that silently normalises ^18.2.0 to 18.2.0 destroys the whole signal)
43 OSV advisories matched, 9 that actually reach the versions in your lockfiles
~40 tokens per injection, ~126 always-on

Honest caveats: that corpus is synthetic and I wrote it, so it's a floor not a proof. Nobody but me has run this yet. npm cross-repo impact is weaker than infrastructure, because packages install independently per repo. pnpm lockfiles aren't read.

pip install blastradius-mcp — MIT, local-only, one SQLite file, nothing leaves your machine.

GitHub Link

Mostly I'm curious whether the hooks-over-tools framing holds up for other people's use cases, or whether I've over-fit it to mine.

Top comments (0)