Skip to content

MCPs that earn their place

MCP — Model Context Protocol — is the standard Claude Code uses to talk to external tools and services. An MCP server is a small program that exposes a set of tools (read this file, query this database, take this screenshot) to Claude. Once installed, the tools appear inline in the conversation and Claude can call them like any other capability.

The MCP ecosystem is large and growing. Most MCPs are noise for a Playbook project. Four genuinely earn their place — each one fills a capability gap that no other Foundations primitive covers.

MCPWhat it doesWhy it matters for a Playbook project
Context7Pulls live, version-pinned documentation for libraries directly into the conversation.Default model knowledge lags real-world library versions by months. For anything moving fast (Next.js, Supabase SDK, framework migrations), Context7 stops Claude generating code against a stale API.
GitHubLets Claude read and write issues, PRs, comments, and reviews without leaving the terminal.Most of the Playbook’s spine touches GitHub eventually — opening a PR, reviewing a diff, responding to a review comment. Doing it from inside Claude Code is faster than alt-tabbing and keeps the work in one place.
PlaywrightDrives a real browser. Claude can navigate to your local dev server, take screenshots, click through flows, and see what rendered.A Next.js + Vercel project’s most underused capability. Without this, Claude is generating UI code blind. With it, Claude can verify a layout actually rendered before claiming the work is done.
SupabaseRuns SQL, lists tables, applies migrations, fetches logs.The data-layer equivalent of GitHub access — instead of describing what Claude should do to your database, Claude can do it directly, observe the result, and verify.

The rest of the MCP ecosystem is mostly noise — community-maintained servers for narrower use cases, IDE-specific helpers, or wrappers around APIs you’d be better off calling directly from your code. Resist adding more than you need.

Two installation patterns:

  • Local stdio servers — install via claude mcp add (run claude mcp --help for current syntax) or by adding an entry to ~/.claude/settings.json. Most third-party MCPs work this way. Each MCP’s README has the exact command.
  • claude.ai integrations — for MCPs that offer a hosted integration (GitHub, Supabase, and others), install via your account at claude.ai/settings/connectors. These don’t need a local process and authenticate via OAuth; tools show up automatically in your next session.

When both are available, the claude.ai integration is usually less work to set up and easier to revoke. The stdio version is the right choice when you need version control of the server itself, or when the MCP doesn’t offer a hosted version.

Anyone can publish an MCP. The official Anthropic-maintained list is curated; the rest of the ecosystem isn’t. A malicious or careless MCP server has the same risks as a malicious plugin: file access, shell command execution, network calls, exposed credentials.

The same three checks from Plugins port directly to MCP servers:

  • Read the source. Open the repository. Read what the server actually does. If the README is thin and the source is opaque, walk away.
  • Check maintenance. Recent commits and active issue resolution are the cheap signals. A two-year-old MCP may not work with current Claude Code, or may depend on a deprecated API.
  • Audit the permissions. What does the server read? What does it write? Does it make network calls to anywhere other than the stated provider? If anything surprises you, don’t install it.

The pattern is identical; the surface is different. Hold MCPs to the same bar as plugins.