The Model Context Protocol (MCP) is an open standard for connecting AI assistants to external tools and data. In Claude Code, every MCP server you install adds a new set of capabilities Claude can call directly — like adding a new section to your toolkit.
The mental model
Without MCP: you tell Claude "go check the database" and Claude writes a one-off SQL script, runs it via Bash, parses output, hopes for the best.
With MCP: you install the Supabase MCP server. Now Claude has tools called list_tables, execute_sql, apply_migration. They're typed, documented, and the auth is already wired. Claude calls them like it calls Read or Edit.
The win is consistency. Every conversation starts with the same powerful primitives instead of Claude reinventing them per session.
Three servers worth installing today
1. The official Supabase MCP
If your stack is Supabase, this is non-negotiable. You get:
list_tables,execute_sql,apply_migration— schema and DML in one motionget_logs,get_advisors— for debugging without hand-rolling queriesdeploy_edge_function,list_edge_functions— manage Edge Functions from chat
Install (one of):
- Claude Desktop UI: Settings → Connectors → Supabase
- CLI:
claude mcp add @supabase/mcp-server-supabase
Pair with project-scoped access tokens so each repo only sees its own database.
2. Chrome DevTools MCP
mcp__claude-in-chrome__* lets Claude navigate, click, and read web apps you're testing. Critical for:
- E2E test debugging — Claude reproduces user steps and reads console errors
- Pulling structured data from authenticated SaaS dashboards
- Checking your own deployed UI from Claude's seat
Install: npx -y @modelcontextprotocol/server-chrome and add to ~/.claude/mcp.json.
3. GitHub MCP
For PR review, issue triage, and "what's in this codebase" questions where you don't have the repo cloned. Tools like search_code, get_pr, list_issues, create_pr mean Claude can operate across repos without you cloning each one.
When to add an MCP server
Add one when you find yourself writing the same Bash + curl combo three times to interact with the same external system. That's the signal that a typed tool will pay off.
Stop short when:
- The tool is one-off (don't add a Twilio MCP for a single SMS test)
- The auth model is dangerous (no MCP for "delete production buckets")
- The MCP is unmaintained — abandoned servers leak credentials
How Claude finds and calls them
In Claude Code, tools are loaded lazily via ToolSearch — when you mention "check the logs" Claude searches available MCP tools, finds get_logs, and calls it. You don't need to memorize tool names; you just describe what you want.
For frequently-used tools, ask Claude to add allowlists in .claude/settings.json so you stop seeing permission prompts. The fewer-permission-prompts skill (from the agent-toolkit) automates this for you.
Building your own MCP
Custom tools are surprisingly easy. The @modelcontextprotocol/sdk ships in TypeScript and Python; a useful server is often <100 lines. Anthropic's docs at modelcontextprotocol.io walk through it.
Common reasons to build one:
- Wrap your internal API so Claude doesn't need to read OpenAPI docs every session
- Expose a CLI you already trust (
kubectl,aws, your deploy script) as typed tools - Let Claude search a private knowledge base (Notion, Confluence, internal wiki)
Where to go next
- Browse the Awesome MCP Servers directory for what already exists.
- Read the MCP specification before you build your own.
- Pair MCP with Claude Code hooks — hooks are enforcement, MCP is capability. The combo is your team's operating layer.