MCP Servers

The Model Context Protocol (MCP) is an open standard for connecting Claude Code to systems that live outside your shell and filesystem. An MCP server is a small adapter — local or remote — that exposes tools (functions Claude can call), resources (data Claude can read via @ mentions), and prompts (commands Claude can run). Connect one, and Claude can query your database, drive a browser, read your issue tracker, or pull live library docs directly, instead of you copy-pasting context into the conversation by hand.

That power is also the catch. Every server you add is more tools competing for Claude’s attention, more context consumed, more surface area to secure, and — crucially — more code and more output you’re choosing to trust. An MCP tool result is untrusted input: it can carry instructions that try to steer Claude. A server you npx into your session is untrusted code running on your machine. The protocol is genuinely transformative when the connected system is something the filesystem and shell can’t reach, and a liability when you’ve wired up fifteen servers you don’t use and never vetted.

So this chapter is as much about restraint and trust as about wiring. It opens with when MCP is the right tool at all, then argues for installing fewer servers than you think you need. It covers configuring servers at the right scope, keeping credentials out of committed config, and letting tool definitions stay deferred so they don’t drown your context. It closes with the security core: treating a new server as untrusted code and its output as untrusted input, and governing access with permission rules and — for organizations — managed allowlists.