MCP, wire Claude to your SaaS

What MCP is

MCP, Model Context Protocol, is the open standard Anthropic created to plug Claude into external services. One unified way to tell Claude "here are my docs, here's my DB, here's my GitHub, help yourself."

The analogy that works: MCP is the USB port of code. Before USB, every printer had its own cable, every camera its own adapter. Same thing for LLMs two years ago: every app that wanted to wire a model into a service wrote its own custom connector. MCP sets 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.

Claude Code consumes, the MCP server provides. The server can run locally (stdio) or remotely (HTTP, since remote MCP hit GA in October 2025).

Why it became essential

Before MCP, life looked like this: you ask Claude for a change in your DB, you copy the schema from Supabase, paste it in, he spits out SQL, you copy the SQL, paste it into the Supabase editor, run it, come back to Claude, tell him "it broke, here's the error." Fifteen round trips for a simple task.

With MCP, Claude does the round trips itself. He reads your schema, writes the migration, applies it, reads the logs, fixes. You watch.

The real shift isn't in reading. It's in the action. Claude can now:

• Create a GitHub issue with labels and assignees
• Query your Supabase DB and generate matching TypeScript types
• Read a Notion page and update it
• Deploy to Vercel and check build logs
• Pull a Sentry error and propose a fix

All of it in the same session, without ever leaving the terminal.

Official servers

Here are the official MCPs most useful to a solobuilder shipping SaaS:

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

Step-by-step setup, 3 essential MCPs for a solobuilder

The easiest way to add an MCP to Claude Code is via the /plugin command or the MCP settings menu (Cmd+, on Mac). For the official MCPs listed above, everything goes through OAuth: click "Connect", browser opens, you approve, it's wired.

Notion

Your number one copy-paste battlefield. Specs, todos, client notes, roadmap. Wiring Notion kills 80% of manual round trips.

Connect: /plugin then search "notion", or go directly through MCP settings. The Notion OAuth screen asks which pages/databases to expose. Grant access to the workspaces you actively 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.

Sample prompt:

Pull my Notion page "Roadmap Q2" and create a GitHub issue
for every item with status "Todo", using the page context
as the issue description.

Claude reads Notion, understands the structure, creates the issues on GitHub's side. One instruction, two MCPs talking to each other.

Vercel

Useful the moment you deploy. You no longer have to copy build logs into Claude when a deploy fails, he fetches them himself.

Connect: /plugin or MCP settings, OAuth Vercel. Pick the team you want to expose.

Useful commands:

• list_projects: list your projects
• list_deployments: a project's deploy history
• get_deployment: details of a specific deploy (URL, status, commit)
• get_deployment_build_logs: full build logs
• get_runtime_logs: runtime logs (prod errors)
• deploy_to_vercel: trigger a deploy

Sample prompt:

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

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

Supabase

The most powerful of the three. Claude can read your schema, write SQL, apply migrations, generate TypeScript types, read logs.

Connect: OAuth Supabase through /plugin. Pick which organization to wire. Every action carries the project_ref so Claude knows which project to hit.

Useful commands:

• list_projects + get_project: find 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
• get_logs: Postgres, API, auth, edge function logs
• get_advisors: security and performance warnings

Sample prompt:

Add an "invoices" table with the usual columns (id, user_id,
amount, status, created_at), set a 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 via apply_migration, calls generate_typescript_types, updates the local file. Zero copy-paste.

Custom MCP, the Nano Banana example

Official servers cover 80% of needs. For the remaining 20%, you can host your own MCP. That's exactly what we do in chapter 15 with Nano Banana, a home-grown MCP server that wires the Gemini Image API into Claude Code so you can generate visuals straight from the terminal.

The principle is always the same:

1. Write a small server (Node or Python) that exposes tools
2. Declare it in your MCP config (~/.claude/mcp_servers.json for local stdio, or an HTTP URL for a remote MCP)
3. Claude Code detects it on startup and the tools become callable

Typical cases where building your own MCP is worth it:

• Your SaaS's internal API (so Claude can test endpoints in dev)
• Custom workflows on top of an API that already has an MCP but lacks the action you need
• Domain-specific tool (invoice generator, accounting export, scraper)

Since remote MCP hit GA (anthropic.com/news/claude-code-remote-mcp), you can host your server on Vercel/Fly/Cloudflare and share it across machines without rebuilding locally on every update.

Security

Three rules to keep:

1. OAuth and minimal scopes. When you connect an MCP, OAuth asks which scopes to allow. Pick the minimum needed. For Notion, grant access to relevant workspaces, not "all pages". For GitHub, create a token scoped to specific repos when you can. For Supabase, keep read and write separate and never connect your prod project with auto-approve on.
2. Use /permissions to audit. The /permissions command in Claude Code shows what each MCP can do. Check it after every install. If an MCP asks for more than needed, revoke and reconfigure.
3. Manual approval on writes. By default, Claude Code asks for confirmation before any action that modifies or deletes. Don't flip auto-approve on MCPs that touch prod data (Supabase, GitHub writes, Linear delete). Keep the confirmation prompt.

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