MCP: connecting external tools

Skills give Claude knowledge. MCP gives Claude hands.

MCP — Model Context Protocol — lets Claude interact with external services in real time. Query a database. Create a pull request. Run a browser. Deploy a function. Anything that requires live data or produces side effects is MCP territory.

The distinction that matters

This is the line I draw: skills are static knowledge, MCP is live execution.

If Claude needs to know how your database schema works, that is a skill. If Claude needs to actually run a SQL query against your database, that is MCP.

If Claude needs to know your deployment process, that is a skill. If Claude needs to actually deploy to Vercel, that is MCP.

The distinction is important because MCPs have a real context cost (tool descriptions loaded at session start), while skills are free until triggered. Do not install an MCP when a skill would suffice.

Common MCP servers

Here are the MCPs I see used most in production agentic workflows, and what they actually do.

I run three MCPs on my daily projects: Supabase, GitHub, and Context7. That covers my database, my workflow, and my documentation needs. Everything else stays disabled.

For teams that have gone further, MCP catalogs organize available servers by category: recommended (Context7, GitHub, Supabase, Playwright), cloud platforms (Vercel, Railway, Cloudflare), AI and media (fal.ai for generation, Magic UI for components), and utility (Sequential-Thinking for chain-of-thought, Memory for persistence). The catalog is not a shopping list — it is a menu. You pick what your project actually uses and leave the rest disabled. The best-configured setups I have seen run 3-5 MCPs, not 15.

How to configure

MCP servers are configured in ~/.claude/settings.json under the mcpServers key. Each server has a command (what to run), args (arguments), and optional env (environment variables).

{
  "mcpServers": {
    "supabase": {
      "command": "npx",
      "args": ["-y", "@supabase/mcp-server"],
      "env": {
        "SUPABASE_ACCESS_TOKEN": "sbp_..."
      }
    },
    "context7": {
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp"]
    }
  }
}

That is it. When Claude Code starts, it connects to each configured MCP server and registers the available tools. Those tools then appear in Claude's tool list, ready to use.

You can also configure MCPs at the project level in .claude/settings.json (in your project root). Project-level MCPs only load when you are working in that project. This is better for project-specific tools — if you only need the Supabase MCP for one project, put it in the project config instead of the global one.

The context cost of MCPs

This is where most people go wrong. They install 8 MCPs because they look useful. Then they wonder why Claude seems slower and less sharp than before.

Every MCP server adds its tool descriptions to your context window at session start. A server with 30 tools adds roughly 3-5k tokens of overhead. Those tokens are loaded whether you use the tools or not. They sit in context for the entire session.

Let me put that in perspective. The Supabase MCP has about 30 tools. Context7 has around 5. GitHub has around 15. If you have all three active, that is 50 tool descriptions consuming maybe 8-10k tokens of your context budget.

Now add Playwright (15+ tools), a Slack MCP (10 tools), a Vercel MCP (12 tools), and a Notion MCP (10 tools). You are looking at 97 tool descriptions and potentially 15-20k tokens of overhead — 10% of your context window — before you have done anything.

MCP vs Bash

Here is something that is easy to overlook: Claude already has Bash access. Many things people install MCPs for can be done with a bash command.

Need to check your git status? Claude can run git status. Need to query your database? Claude can run psql or use the Supabase CLI. Need to deploy? Claude can run your deploy script.

MCPs are better when:

• The interaction is complex (multi-step API workflows)
• The tool provides structured output that Claude can parse reliably
• Authentication is handled by the MCP server (not exposed in bash history)
• The service has a rich API that would be tedious to use via curl

MCPs are overkill when:

• A single bash command does the job
• You are using the MCP for one tool out of thirty
• The MCP adds more context overhead than the time it saves

I used to have a Vercel MCP installed. Then I realized I only used it for vercel deploy, which Claude can just run as a bash command. Removing the MCP freed up 3k tokens of context overhead for zero loss in capability.

Practical setup for common stacks

For a Next.js + Supabase project (which is my main stack), here is what I recommend:

{
  "mcpServers": {
    "supabase": {
      "command": "npx",
      "args": ["-y", "@supabase/mcp-server"],
      "env": {
        "SUPABASE_ACCESS_TOKEN": "sbp_your_token"
      }
    },
    "context7": {
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp"]
    }
  }
}

Two MCPs. Supabase for database operations and Context7 for documentation lookups. GitHub I add at the project level only for projects where I manage PRs through Claude.

Start small. Add MCPs when you hit a real need, not a hypothetical one. Every MCP you do not install is context budget you keep for actual work.