Claude Code v2.1.121: Instant MCP Tools and Tool-Output Hooks

Lachlan Reed

Welcome to the show — James, I need to start with one tiny config flag that is absolutely not tiny in practice: in Claude Code v2.1.121, you can put alwaysLoad: true on an MCP server entry in .claude/settings.json or ~/.claude/settings.json, and that means the server's tools load at session START instead of waiting for tool-search to wake them up.

James Turner

[quickly] v2.1.121 and one boolean — alwaysLoad: true — that's the kind of release note people skip, and then three weeks later they're like, "why does my workflow suddenly feel better?" Because timing matters. If the tool enters on turn one instead of turn six, the whole conversation shape changes.

Lachlan Reed

Exactly. And the pain it's solving is super ordinary. You've got the same Postgres server, same internal API helper, same CI helper. Every session. But because of deferral, you sort of end up nudging Claude like you're introducing two mates at a barbie — "nah, use THAT one, the database one, the one we've used all week." [chuckles] It feels a bit silly.

James Turner

[skeptical] Okay, but the deferral existed for a reason. If you've got, say, 30-plus tools sitting behind a giant MCP catalog, loading all of that up front is how you quietly torch context before the first useful answer. That's not paranoia — that's just budgeting. Tokens spent early are still tokens gone.

Lachlan Reed

Right, and that's the distinction people have gotta keep straight: alwaysLoad is NOT "turn off deferral everywhere." It's per server. That's the whole trick. You leave the weird exploratory servers lazy-loaded, and you pin the two or three workhorse servers you touch constantly.

James Turner

Per-server is the important phrase there. Not global. [pauses] So let me try to explain it back: if I have one MCP server for my everyday Postgres queries and another for some giant rarely-used internal docs system, I can set alwaysLoad: true on the Postgres one, but keep the docs server deferred until tool-search actually needs it?

Lachlan Reed

Yep — that's it. Almost like pinning your favorite spanner on the pegboard and leaving the rest in the drawer. The good stuff is in reach, the clutter stays out of the way. And because you can put it in the project-level .claude/settings.json or the user-level ~/.claude/settings.json, you've got a nice split between team defaults and your own personal setup.

James Turner

That .claude/settings.json versus ~/.claude/settings.json split is actually bigger than it sounds. Project-level means a team can decide, "our internal API server is mission-critical, load it every time." User-level means I can keep my own weird toolbox without forcing it on everyone else.

Lachlan Reed

[warmly] Yeah, and that's where this stops being a nerdy config footnote and becomes workflow design. In my web-dev world, the annoying part isn't just waiting — it's context-switching. If I'm halfway through tracing a bug and Claude still hasn't got the DB tool in play, I have to interrupt the task to steer it. That's friction. Tiny friction, but it stacks up like sawdust in the shed.

James Turner

And I think the counterpoint is healthy: if you load 30 tools because "maybe I'll need them," you've recreated the worst kind of startup bloat. It's like opening every tab you'll possibly need for a research session and then wondering why your laptop sounds like a leaf blower. The escape hatch is useful precisely because it's narrow.

Lachlan Reed

[laughs] A browser with 97 tabs is a cry for help, mate. But yes — narrow is the point. Claude Code is basically saying: we still believe in tool-search deferral, because giant catalogs can bloat the context window. We are just admitting that, for a few servers, deferral flips from safety into nuisance.

James Turner

And that's the part I'd want listeners to remember: this doesn't kill lazy-loading. It lets you choose where laziness is smart and where it's just getting in the way. That's a very different philosophy from "load everything" or "load nothing."

James Turner

The same v2.1.121 release had a second change that I think is actually more explosive. PostToolUse got widened so hookSpecificOutput.updatedToolOutput can replace the output of ANY built-in tool, not just MCP tools. So now a hook can rewrite bash output, file reads, other native tool results — before Claude sees them.

Lachlan Reed

[questioning tone] Wait — any built-in tool? Not just MCP? So if bash spits out a log full of secrets, a hook can scrub that before Claude ever reads it?

James Turner

Exactly. And "scrub secrets from shell output" is one really practical use case. Another is normalizing noisy logs so the model doesn't get distracted by garbage. Another is injecting context into a result — like, basically shaping the tool output into a cleaner object for Claude to reason over.

Lachlan Reed

That phrase — updatedToolOutput — is the bit that'll stick for me, because it's deceptively tidy. It sounds like formatting. But this is more than formatting. If Claude acts on the rewritten output instead of the raw output, you've moved the trust boundary. That's a big old shift.

James Turner

[serious] Yes. That's the exact tension. The automation upside is real, but Claude is now responding to the edited version. So if your hook silently blanks a line, truncates something important, or mangles a bash result, Claude can continue on a false premise. Not because the model hallucinated — because YOU fed it a distorted tool result.

Lachlan Reed

And that's nastier than a normal bug, hey, because it can look clean. If a shell command really failed loudly, you'd notice. If a hook politely rewrites that output into something half-wrong... Claude strolls ahead like nothing happened. That's the software equivalent of painting over the check-engine light. [scoffs]

James Turner

Painting over the check-engine light is perfect. [chuckles] And this is why I'd treat hooks like production code, not glue code. Test them. Version them. Be explicit about what they redact, what they normalize, what they preserve. Because once bash and file reads are in scope, the blast radius is way wider than "my MCP integration is quirky."

Lachlan Reed

The phrase "blast radius" is bang on. Built-in tools are the bones of the session. If you rewrite those, you're not just accessorizing the workflow — you're changing the evidence Claude uses to think. I mean, that's powerful... and a little spicy.

James Turner

[reflective] And tucked into that same release were two less flashy fixes that, honestly, might save more people actual pain. One fix addressed unbounded RSS growth that could climb into MULTI-gigabyte territory during image-heavy sessions. Another fixed an almost 2 GB leak in /usage on machines with huge transcript histories. No config change, just upgrade.

Lachlan Reed

Multi-GB RSS during image-heavy sessions, and nearly 2 GB leaking in /usage — those are not cute little papercuts. That's your machine getting bogged down while you're trying to work. And the nice bit is, unlike the hooks stuff, there's no philosophical decision tree there. Just update the thing.

James Turner

Right. One part of this release says, "here's more control." The memory fixes say, "also, sorry, this should've been tighter." [pauses] I actually like that combination. Give people sharper tools, but also reduce the background instability that makes power features scary.

Lachlan Reed

Though it does land us in an interesting spot. With alwaysLoad: true, you're deciding what tools Claude sees earlier. With updatedToolOutput, you're deciding what Claude thinks those tools SAW. That's... not the same level of control. One is convenience. The other is epistemology with a config file. [laughs softly]

James Turner

[calm] That's the cleanest way to put it. Claude Code is getting more configurable at the tool boundary, which is great. But the more you rewrite inputs and outputs, the more the real question stops being what Claude can see — and becomes who gets to decide what it thinks it saw.

Lachlan Reed

[softly] And if your team can't answer that clearly, maybe don't hand the kangaroo the car keys just yet. Catch you next time.