MCP and the rest

MCP and the rest

The Model Context Protocol has made tool integration substantially easier, which means most agents now consume tools from servers their team did not write.

Everything above applies, with one addition specific to the protocol: the server controls both the tool descriptions and the results, so it supplies leg two of chapter 3's trifecta and a write into your prompt. A third-party MCP server is a trusted component in the precise sense that it can change your agent's behaviour without changing your code.

That is not an argument against using them. It is an argument for knowing which ones you run, who maintains them, whether their descriptions are pinned, and what capabilities they hold under chapter 8. Most teams cannot currently answer the first of those.

The register

Everything in this chapter reduces to one artifact, and it is a file rather than a platform.

- tool: lookup_order
  source: internal
  maintainer: orders-team
  capabilities: [read:order]
  description_hash: 9f2a...

- tool: web_fetch
  source: mcp://example-tools.dev
  maintainer: third-party
  pinned: sha256:41c8...
  capabilities: [read:public-web]
  description_hash: 7b10...
  reviewed: 2026-09-02

Five fields per tool and the chapter is mostly implemented. The hash of the description is what turns a silent change into a failing build. The capability list is chapter 8 arriving at the point where someone has to write it down. The review date is what an auditor asks for, and what tells you which entries nobody has looked at since they were added in a hurry.

Generate the descriptions hash at startup and fail if it has moved. That single check catches description injection, rug-pulls in the metadata, and a surprising number of ordinary mistakes.

The reason to keep it in the repository rather than a wiki is that it then moves through review with the code that depends on it, and a pull request that adds a tool is visibly a pull request that adds a tool.

What this costs

Friction, and the friction is the point.

The 72-hour delay means you are never on the newest release, which occasionally matters and usually does not. Hash pinning means updates are a deliberate act rather than a lock-file refresh. Description pinning means adding a tool has a review step.

The larger cost is organisational. Somebody has to own the list of tools the agent can reach, and in most teams that list is currently owned by whoever last needed something. The register does not have to be sophisticated. A file naming each tool, its source, its maintainer, its pinned hash and its capability set is enough, and it is the artifact chapter 18 will ask you for.

Chapter 14 turns to the last surface the primitives do not cover: the person you interrupt for approval.

Sources for this chapter

The four-failure taxonomy, the treatment of tool descriptions as part of the system prompt, the 72-hour adoption delay, and the tool register are the author's. The claim that "most malicious releases are caught in hours" generalises from this incident and a handful of others and has not been measured across the population of malicious packages; it is the weakest quantitative statement in the chapter and is offered as a rule of thumb. The assertion that most teams cannot enumerate their MCP servers is experience, not survey data.