MCP: connect Claude to your tools

What MCP is

Before USB, every printer had its own cable and every camera its own adapter. LLMs were in the same spot before MCP: every app that wanted to connect a model to a service wrote its own homemade connector. MCP plays the role of the USB port, with a shared format. Claude speaks MCP, the service speaks MCP, they talk.

An MCP server exposes two things:

• Tools: functions Claude can call. create_issue, execute_sql, get_deployment.
• Resources: data Claude can read. A Notion page, a file, a DB schema. You reference them with @, like a file: type @ in your prompt and they show up in autocomplete.

Claude Code consumes, the MCP server provides. The server can run locally on your machine (stdio) or remotely (HTTP).

What MCP changes day to day

Before MCP, your life looked like this: you ask Claude for a change in your DB, you copy the schema from Supabase, you paste it, it gives you SQL, you copy the SQL, you paste it into the Supabase editor, you run it, you go back to Claude, you tell it "it crashed, here's the error". Fifteen round trips for something simple.

With MCP, Claude does the round trips on its own. It reads your schema, writes the migration, applies it, rereads the logs and fixes things while you watch.

Most of the gain is in the action. In the same session, without leaving the terminal, Claude can create a GitHub issue with labels and assignees, then query your Supabase database and generate the matching TypeScript types. It updates a Notion page, deploys to Vercel while watching the build logs, or starts from a Sentry error to propose a fix.

The official servers

Here are the most useful official MCPs for a solo builder working on a SaaS:

The list moves fast. Current reference at code.claude.com/docs/en/mcp.

Step-by-step setup, 3 essential MCPs for a solo builder

Three ways to add an MCP to Claude Code, from simplest to most manual:

1. A claude.ai connector. You connect it once in claude.ai settings (Connectors section), and it shows up on its own in /mcp in Claude Code, on all your machines. That's what I use for Notion, Supabase and Vercel.
2. claude mcp add for a remote or local server:

# remote server (HTTP), example taken from the CLI help
claude mcp add --transport http sentry https://mcp.sentry.dev/mcp

# local server (stdio) with an environment variable
claude mcp add my-server -e API_KEY=xxx -- npx my-mcp-server

By default the server is added for the current project (local scope). --scope user makes it available everywhere, --scope project writes it to a versioned .mcp.json your team shares.

1. A plugin that ships its own MCP server (chapter 16).

For servers that need a login (OAuth), you authenticate with claude mcp login <name> in the terminal or from /mcp in the session: the browser opens, you authorize, it's connected. Over SSH, with no browser, claude mcp login <name> --no-browser prints the URL to open on your machine.

Notion

For most solo builders, this is where the most copy-pasting happens: specs, todos, client notes, roadmap. If you only connect one MCP, start with this one.

Connection: the claude.ai Notion connector, then check that it shows up in /mcp. Notion's OAuth asks which pages and databases to make accessible. Give access to the workspaces you work in, avoid "all pages" by default.

Useful scopes:

• Pages (read + write)
• Databases (query + update)
• Comments (if you use Notion reviews)

Commands on Claude's side: notion-search, notion-fetch, notion-create-pages, notion-update-page, notion-create-database.

Example prompt:

Find the "Q2 Roadmap" page in my Notion and create
a GitHub issue for each item with status "Todo",
with the page context in the description.

Claude reads the Notion page, picks out the "Todo" items and creates the issues on GitHub.

Vercel

Useful as soon as you deploy. You no longer copy build logs into Claude when a deploy fails, it fetches them on its own.

Connection: the claude.ai Vercel connector, or the Vercel plugin from the official marketplace. Vercel OAuth, pick the team you give access to.

Useful tools (names shift between versions, /mcp shows the current list):

• list_projects: lists your projects
• list_deployments: a project's deploy history
• get_deployment: details of a specific deploy (URL, status, commit)
• get_runtime_logs: runtime logs (production errors)
• create_deployment: trigger a deploy

Example prompt:

My last deploy on the "carbonara" project failed.
Get the build logs, find the error, propose a fix.

Claude fetches the logs, identifies the missing module or the TypeScript error, edits the file, you review, you commit. Three minutes instead of fifteen.

Supabase

The one that does the most. Claude can read your schema, write SQL, apply migrations, generate TypeScript types, read logs.

Connection: the claude.ai Supabase connector (OAuth). You choose which organization to connect. Each action mentions the project_ref so Claude knows which project to hit.

Useful tools:

• list_projects + get_project: identify the right project_ref
• list_tables: see the current schema
• execute_sql: direct query (read + write)
• apply_migration: apply a named migration
• generate_typescript_types: generate the database.types.ts file
• query_logs: Postgres, API, auth, edge function logs
• get_advisors: security and performance warnings

Example prompt:

Add an "invoices" table with the usual columns
(id, user_id, amount, status, created_at), add an RLS
policy "user can read own invoices", apply the migration
to the carbonara-prod project, then regenerate the types.

Claude writes the migration, applies it through apply_migration, calls generate_typescript_types, updates the local file.

Custom MCP, the Nano Banana example

The official servers cover 80% of needs. For the remaining 20%, you can host your own MCP. We do it in chapter 15 with Nano Banana, a homemade MCP server that connects the Gemini Image API to Claude Code to generate visuals straight from the terminal.

The principle is always the same:

1. You write a small server (Node or Python) that exposes tools
2. You declare it with claude mcp add (a local command for a stdio server, a URL for an HTTP server)
3. Claude Code detects it at startup and the tools become callable

Typical cases where building your own MCP makes sense:

• Your SaaS's internal API (so Claude can test endpoints in dev)
• Custom workflows on an API that already has an MCP but not the action you need
• A tool specific to your business (invoice generator, accounting export, scraper)

With a remote MCP (anthropic.com/news/claude-code-remote-mcp), you host your server on Vercel, Fly or Cloudflare and share it across several machines without a local rebuild on every update.

Managing your servers day to day

claude.ai connectors show up in /mcp next to your local servers. You'll also find Anthropic's own there, including Claude Docs, which lets Claude Code create and edit shared documents (chapter 15).

Security

Three rules to stick to:

1. OAuth and minimal scopes. When you connect an MCP, the OAuth flow asks which scopes to allow. Pick the minimum. For Notion, give access to the relevant workspaces, not "all pages". On GitHub, a token limited to the relevant repos if you can. For Supabase, never connect your production project without a safeguard.
2. /permissions to audit. MCP tools show up there as mcp__<server>__<tool>. Check what's allowed after each install.
3. Block production writes with a rule. New sessions start in auto mode (the default mode, see chapter 9): a classifier approves what looks safe and blocks destructive and production actions. The classifier can miss a case. For tools that write to production, add an explicit deny rule:

{
  "permissions": {
    "deny": [
      "mcp__claude_ai_Supabase__execute_sql",
      "mcp__claude_ai_Supabase__apply_migration"
    ]
  }
}

The name follows the mcp__<server>__<tool> pattern. A claude.ai connector gets the claude_ai_ prefix followed by its name (here claude_ai_Supabase). A server added with claude mcp add supabase ... would give mcp__supabase__execute_sql. Check the exact name in /mcp before writing the rule. deny rules block in every mode, bypassPermissions included.

If you work with sensitive data (clients, payments), split your MCPs: a "dev" profile with the MCPs that hit staging, a "read-only" profile with only read MCPs for exploration sessions.

MCP or CLI?

When a service has a good CLI, it often does better than an MCP. gh for GitHub, vercel for Vercel, supabase for Supabase: Claude already knows them, they need no tool definition in context, and you can filter their output (| grep, | jq, | tail) before it lands in the conversation. The Claude Code cost docs recommend this explicitly.

Keep the MCP when there's no CLI, when you need OAuth authentication the CLI doesn't handle, or when the service exposes actions the CLI lacks (the Notion tools, for example).

What your MCPs cost in context

The advice that went around for a long time: "disconnect the MCPs you don't use, they eat your context". It was right until tool search came along.

Measured on a real setup with nine servers connected:

MCP tools    376 tools · 0 tokens

What they would weigh if all were loaded:
  Canva  edit-design               8.7k
  Notion query-meeting-notes       6.8k
  Qonto  create_client             6.7k
  … 373 more
  Theoretical total               244.1k

376 tools announced, zero tokens consumed. Loaded all at once, they would take up almost a quarter of a 1M window.

This is Claude Code's default behavior, you have nothing to turn on. All current models support it. The exceptions: a proxy connected through ANTHROPIC_BASE_URL, older models on Google Cloud, and Microsoft Foundry deployments hosted on Azure, where tools load upfront. Another useful side effect: with tool search, connecting or removing an MCP mid-session no longer breaks the prompt cache.

Three settings to know. alwaysLoad goes in the server config (for example in .mcp.json), the other two are environment variables:

• alwaysLoad: true on a server loads its tools upfront. Keep it for a server you call every session, otherwise you pay its weight again for nothing.
• ENABLE_TOOL_SEARCH (true, auto, auto:N or false) controls tool search globally. auto only defers tools beyond 10% of the context window. Leave the default unless you have a specific reason.
• MAX_MCP_OUTPUT_TOKENS caps an MCP tool's response, 25,000 tokens by default (with a warning from 10,000). An SQL query returning 10,000 rows or a log export can hit that cap: ask Claude to filter on the server side rather than raising the limit.

{
  "mcpServers": {
    "my-server": {
      "type": "http",
      "url": "https://my-server.example.com/mcp",
      "alwaysLoad": true
    }
  }
}

What weighs today is the tool responses: every result enters the context and goes back out with every following message. So sort your MCPs on security, scopes and the volume of what they return.

Sources

• MCP in Claude Code (official docs)
• Claude Code, manage costs
• Claude Code, prompt caching
• Routines in Claude Code