Claude Code 2.1.121: MCP guardrails

An MCP guardrail is a written rule in your repo that says which connectors Claude Code may fire and what data they are allowed to touch. If you run Claude Code 2.1.121, Anthropic's coding agent, the four conventions below give your reviewers something concrete to check before a PR merges. They turn agent output back into work a teammate can explain.

Here is the failure they prevent. Watch a PR queue for a week and you will meet the merge that is green everywhere except in anyone's ability to say what it did. CI passed. Tests passed. Nobody can tell you which connector pulled which data. That gap is what these guardrails close.

Tag every connector with the data it touches

The surprise that hurts most is a connector that pulls customer data, where the shock lands during an audit instead of during review. Context feels local while you work, but the data still leaves the laptop boundary.

The fix is to tag each connector with a data class and a retention expectation. Then a security review starts from a written inventory rather than an incident interview. Every untagged connector is a hole you have not looked at yet.

Keep the conventions next to the code, in CLAUDE.md, so they travel with the repo:

# CLAUDE.md guardrails

- Hooks win over informal chat agreements. Document each hook's rollback path.
- Skills defer to this file on security-sensitive folders.
- Bash approvals never bypass the red-folder list maintained here.

Keep memory the agent can inherit

Sessions rotate daily, and shared memory rots when transcripts are the only record. A new teammate inherits rumor instead of reasoning.

So append a weekly retro note: one .md changelog of the decisions agents relied on that week. It is short, it is boring, and it is the thing that lets someone six weeks later understand why a connector was scoped the way it was.

A second drift problem is skills. Skills multiply until a reviewer cannot tell which one governed a diff. Maintain a skills/README.md that lists each skill's activation cue and what it defers to. An on-call engineer then resolves a mismatch by reading the index, not by replaying a session.

Cap your hooks so the alerts stay loud

Hooks that fire everywhere teach developers to ignore them, and an ignored guardrail is an open hole. Noise degrades the signal until the one alert that mattered gets dismissed with the rest.

Cap the active hooks per repo and document each trigger plus its rollback. What survives the cap is rare, loud, and trusted. A hook budget is less about adding control and more about protecting the attention the existing controls depend on.

Pin the version you actually run. The Claude Code releases page is the changelog of record, and your conventions should name the version they were written against.

Run the connector check before you approve

Before you approve a PR, four questions separate an expected connector call from a surprise. Keep them as a standing checklist in the review template.

The connector-truth gate is the one worth starting with. Ask which MCP servers fired on your last five merges and see who can answer from the repo. Here is the scope receipt to paste into the PR description:

• Primary-doc links were smoke-checked after publishing edits.
• MCP connectors mentioned (if any) list their owners.
• Verification command output is pasted or linked.
• Forked agent work lists parent plus child responsibilities.

If your repo cannot state its boundaries plainly, the agent will guess, and guessing scales poorly.

Common questions

• What are the Claude Code 2.1.121 MCP guardrails?

  They are written boundaries that say which connectors may fire and what data they may touch, enforced through four conventions: data-class tags, a weekly retro note, a skill index, and a hook budget. The point is simple. Green CI keeps hiding missing human judgement, and these guardrails put it back into review.

• How do reviewers know which MCP servers fired?

  The connector-truth gate makes it a standing question on every PR: which MCP servers fired, and were they expected? Because the receipt requires connectors to list their owners, the answer comes from the repo and the PR body rather than from whoever happens to remember the session.

• How do data-class tags prevent audit surprises?

  They record, per connector, the data classes it touches and the retention rules that apply. Surprises happen because context feels local while the data leaves the laptop boundary. With tags in place, a security review starts from a written inventory instead of reconstructing one during an incident.

• Why does hook noise threaten safety automation?

  Because noise lowers the signal until developers ignore every alert, including the one that mattered. The hook budget caps active hooks per repo and documents each trigger plus its rollback. What remains is rare and loud, so the alerts keep the urgency they need.

• Where do these conventions live in the repo?

  They live in plain files that travel with the code: CLAUDE.md for precedence rules, skills/README.md for the skill index, a weekly .md retro note for decisions, and the data-class tags alongside each connector definition. Boring, explicit files beat tribal memory because a tired reviewer can still read them.

Next move

Pick one repo and add the data-class tags and the connector-truth gate this week, before the next audit finding asks for them. Our training builds these guardrails live against your own connector list, and the rest of the team conventions cluster fills in the patterns around them.