Extending Claude Code

The last chapter taught the agent to own a procedure — write the PR ritual down once as a skill and let it run the four steps itself. But a skill can only do what the agent can already do: edit files, run shell, read the repo. This chapter is about widening that boundary — giving the agent reach into systems it can’t see, putting a deterministic wall around the one thing it must never get wrong, and then packaging the result so your whole team gets it in one move.

Three extension points, three different jobs, and it’s worth fixing the distinction up front because they’re easy to blur:

Reach — an MCP server is a bridge to an external system the agent otherwise can’t touch: a database, an issue tracker, a browser. It gives the agent new tools.
Gate — a hook is a deterministic shell command wired to a moment in the agent’s lifecycle. It runs regardless of what the model decides, so it’s how you enforce a rule that can’t depend on the agent remembering to follow it.
Ship — a plugin bundles commands, skills, agents, hooks, and MCP config into one installable unit, distributed through a marketplace, so a setup you built once installs identically for everyone.

The setup we’ll build

Same payments service, but now we’re going to outgrow what the agent can do unaided. Three things are missing, and each one wants a different extension point:

The service talks to a Postgres database and a Jira board the agent can’t see. When you ask it about a failing charge, it’s guessing at the schema and you’re pasting ticket text into chat. That’s a reach problem — give it an MCP server.
You want a hard guarantee: no commit that touches the ledger code ever lands without a test alongside it. Not “ask the agent nicely” — a wall that holds even when the session is loose and you’re not looking. That’s a gate problem — wire up a hook.
Once all of this works on your machine, you want to hand it to your team as one unit — the database connection, the Jira link, the ledger gate, the commands — without everyone reassembling it by hand. That’s a ship problem — package it as a plugin.

The lessons build in that order, because that’s the order the need shows up in real work: first you extend what the agent can reach, then you put guardrails on the dangerous part, then you distribute the whole thing. Each lesson ends where the next one starts.

Connect an external system with an MCP server — add the Postgres and Jira servers, and use them.
Scope the agent’s reach so a connection isn’t a blank check — choosing which scope a server lives in, and tying it back to deny rules.
Block a bad commit with a PreToolUse hook — the ledger-needs-a-test wall, built and proven.
Why a hook is stronger than a rule or a permission — deterministic gate vs model-mediated instruction.
Bundle your setup into a plugin — manifest, components, one installable unit.
Ship it to your team through a marketplace — the catalog, the install command, the hand-off.

Start by connecting the database and the board.