Extend the agent's reach with MCP, hooks, and plugins

Three needs show up once an agent does real work in a repository, and none of them is solved by a better prompt or a better instructions file. A system the agent cannot see - a database, a ticket board - means every fact from it passes through you by hand. A check that must fire every time cannot depend on the model choosing to run it. A setup that works only on your machine helps nobody else on the team. Claude Code has one extension point for each: MCP servers for reach, hooks for enforcement, and plugins for shipping the result.

The chapter works all three against a small TypeScript payments service (the example this course returns to; every page restates the facts it needs). Two facts about that repo matter here.

First, the repo is self-contained. src/payments/ledger.ts counts money in a plain in-memory array, and no file in the repo opens a database connection. The external systems in the MCP lessons - a shared staging Postgres and the board where failed charges get ticketed - are therefore a constructed scenario: the surroundings a real payments team would have. The commands are real; the systems they point at belong to that imagined team, and you substitute your own.

Second, the repo already carries the tension the hook lessons resolve. Its root CLAUDE.md states two lines: “Every bug fix must include a regression test” and “Never commit without passing tests.” The same file says to use integer cents and never floating point for currency, and src/payments/processor.ts still computes the fee-inclusive total, amount * 1.029, in floating point (the fee itself is amount * 0.029; the total is the amount plus that fee). Every one of those lines loads into the agent’s context each session, and the code floats anyway. A rule in context informs. It does not enforce. This chapter builds the enforcement; the rules chapter is optional background on how that CLAUDE.md was built and which of its lines earn their place.

Reach, gate, ship

Three extension points, three different jobs, worth separating up front because they are easy to blur:

• Reach - an MCP server is a bridge to an external system the agent otherwise cannot touch: a database, an issue tracker, a browser. It speaks the Model Context Protocol, an open standard for connecting an agent to a tool or data source, and it gives the agent new tools with new names.
• Gate - a hook is a handler wired to a fixed moment in the agent’s lifecycle. Handlers come in five types - command, http, mcp_tool, prompt, and agent - and they are not all alike: prompt and agent hooks hand the decision to a Claude model. The gate we build is a command hook, plain shell that runs no matter what the model was about to do, and can stop it.
• Ship - a plugin bundles skills (task playbooks), agents (delegated workers), hooks, and MCP config into one installable unit, distributed through a marketplace (a catalog file in a git repo), so a setup you built once installs identically for everyone.

In the course’s vocabulary, reach extends the agent’s capability and its context; the gate is control, the difference between guidance and enforcement that this chapter keeps returning to. A rule expresses a constraint. A hook enforces one.

The order the need appears in

The needs arrive in the order real work produces them: reach first, then a gate, then shipping. The pages below follow that order.

• Connect an external system with an MCP server - register the Postgres and board servers, and collapse the copy-paste loop.
• Scope the agent’s reach so a connection isn’t a blank check - which scope a server lives in, a read-only connection, and a deny rule at the permission layer.
• Block a bad commit with a PreToolUse hook - the ledger-needs-a-test wall, wired to the repo’s real paths.
• Why a hook is stronger than a rule or a permission - the three-way comparison, and when a rule or permission is the right tool instead.
• Bundle your setup into a plugin - manifest, directory contract, 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.