Claude Code MCP servers for UK micro-SaaS: the four wires (Stripe UK, Supabase EU, Postgres, GitHub) and one rule that stops the agent guessing

Every Claude Code user hits a wall around month two. The agent can write code, run tests, edit files — but it cannot see your live Stripe charges, query your Supabase EU project, or check the state of your GitHub PRs. So it guesses. And a guessing agent is how a UK indie hacker ends up with a Stripe refund logic that does the right thing for the example in the docs and the wrong thing for the actual production data.

Model Context Protocol — MCP — is the fix. MCP servers wire Claude Code to live data sources: real Stripe charges, real Supabase rows, real Postgres tables, real GitHub PRs. The agent stops guessing and starts looking. This post is the UK micro-SaaS primer: the four MCP servers that actually move the needle, the install commands, and the one rule that stops MCP from turning into a foot-gun.

What an MCP server actually is (60 seconds)

An MCP server is a small process that exposes tools (functions Claude Code can call) and resources (data Claude Code can read) over a stable wire protocol. The agent talks to the server; the server talks to the live system. Anthropic designed it as an open standard so any tool can plug in.

The shape is simple:

1. You install or run an MCP server locally (or use a hosted one).
2. You register it with Claude Code via claude mcp add <name> <command>.
3. The agent now has new tools available — mcp_stripe_list_charges, mcp_supabase_query, and so on.
4. The agent calls those tools the same way it calls Read or Edit. Live data flows through.

For a UK indie hacker, MCP is the difference between an agent that knows your codebase and an agent that knows your business. Four servers do most of the work.

Wire 1: Stripe UK

Stripe ships an official MCP server that exposes charges, customers, subscriptions, refunds, and disputes. For a GBP-priced micro-SaaS, this is the most valuable wire — every "did this customer actually pay" question gets a live answer instead of a grep through your webhook logs.

claude mcp add stripe -- npx -y @stripe/mcp \
  --tools=charges.read,customers.read,subscriptions.read,refunds.read,disputes.read \
  --api-key=sk_test_or_restricted_key

Two things to get right for the UK case:

• Use a Stripe restricted key (rk_…) with read scopes, not your secret key. Stripe's dashboard lets you scope a key to "charges: read, customers: read, no writes". Five minutes well spent.
• Set --tools explicitly. Default is everything; everything includes write tools that you don't want the agent invoking without a turn-by-turn check.

The agent can now answer questions like "what was our refund rate in April for the GBP 9.99 tier" and "which subscriptions failed payment in the last 7 days" by hitting Stripe directly. No more pasting JSON into the prompt.

Wire 2: Supabase EU

Supabase ships an official MCP server too. It exposes query, schema inspection, migration management, and (if you let it) writes. For a UK micro-SaaS running on Supabase EU-West, this is the wire that makes refactors safe — the agent can see the schema and the live data before suggesting a migration.

claude mcp add supabase -- npx -y @supabase/mcp-server-supabase \
  --access-token=$SUPABASE_ACCESS_TOKEN \
  --project-ref=your-project-id \
  --read-only

The --read-only flag is the bit most tutorials skip. Default is full read-write, and Supabase MCP can run arbitrary SQL on your live project. For day-to-day vibe coding, read-only is correct — you opt into writes per-task, by reconfiguring the server when you genuinely need an UPDATE.

The agent now knows your schema in detail and can do things like "find all users created after the GoCardless integration shipped" or "list rows in subscriptions where stripe_customer_id is null but is_paid is true" without you having to paste a single row.

Wire 3: Postgres direct

When you need a raw SQL wire that doesn't go through Supabase's RLS layer (admin queries, ad-hoc analytics, anything that touches pg_catalog), the official Postgres MCP server is the right tool.

claude mcp add postgres -- npx -y @modelcontextprotocol/server-postgres \
  "postgresql://readonly_user:password@db.your-project.supabase.co:5432/postgres"

The connection string is the only knob. Two strong recommendations:

• Connect as a readonly_user Postgres role, not the service-role user. Create one in Supabase SQL: CREATE ROLE readonly_user LOGIN PASSWORD '…'; GRANT pg_read_all_data TO readonly_user;.
• Use a separate restricted password from your service-role secret. If the agent leaks the password (it shouldn't, but hooks earn their keep), you can rotate the readonly role without rotating production.

The agent now does analytics queries — "average days from signup to first paid invoice", "weekly active by Tuesday cohort" — without you opening pgAdmin. For an indie hacker, this is the fastest way to a "data-informed Monday morning".

Wire 4: GitHub

The GitHub MCP server exposes issues, PRs, workflow runs, and gists. The gh CLI gets you 70% of this already, but MCP wires it into the agent's reasoning loop — the agent can read PR review comments and respond to them in the same turn.

claude mcp add github -- npx -y @modelcontextprotocol/server-github \
  --github-token=$GITHUB_PERSONAL_ACCESS_TOKEN

Scope the token narrowly. A fine-grained personal access token with Repository contents: read, Pull requests: read+write, Issues: read+write, scoped to the repos this agent should touch, is the right shape. Avoid classic tokens with repo scope — that's a master key and the agent doesn't need one.

For a solo UK indie hacker, the killer pattern is "address the PR review I just got": you paste the PR URL, the agent reads the review via MCP, replies to the comments, opens the right files, makes the edits, runs the tests, pushes a fix-up commit. Twelve minutes from "review arrived" to "review addressed".

The one rule: pin scopes to read-only by default

The single mistake that turns MCP from "agent superpower" into "agent foot-gun" is wiring servers with write scopes by default. Three concrete failure modes for a UK micro-SaaS:

• Stripe writes. A Stripe MCP wired with refunds.write and customers.write will eventually refund the wrong customer when the agent confuses the test and live keys mid-session. The blast radius is "Stripe support ticket".
• Supabase writes. A Supabase MCP without --read-only will eventually run an UPDATE without a WHERE clause during a refactor. The blast radius is "restore from a four-hour-old backup".
• GitHub force-push. A GitHub MCP with admin scope will eventually force-push a wrong branch to main when the agent confuses two feature branches. The blast radius is "PR history rewritten".

The fix is the same in each case: read-only by default, opt in to writes per task. When the agent genuinely needs to write — adding a Stripe metadata field, running a Supabase migration, merging a PR — you reconfigure the relevant server for that one task, do the work, and switch back. Five seconds of friction; whole categories of disaster avoided.

In settings.json the pattern looks like this:

{
  "mcpServers": {
    "stripe-read": { "command": "npx", "args": ["-y", "@stripe/mcp", "--tools=charges.read,customers.read", "--api-key=$STRIPE_RESTRICTED_KEY"] },
    "supabase-read": { "command": "npx", "args": ["-y", "@supabase/mcp-server-supabase", "--project-ref=...", "--read-only"] }
  }
}

Note the -read suffix on each server name. It is a small thing, but every prompt where the agent picks stripe-read is a prompt where it cannot accidentally refund a customer.

Verifying the wires

After installing each server, sanity-check from inside Claude Code. Type /mcp to list registered servers and see their connection status. Each one should show Connected and a list of tools. If a server shows Failed, the most common causes for a UK indie hacker are:

• Expired or wrong-scope API key (Stripe restricted keys can expire if you set an expiry; Supabase service keys can be revoked).
• Wrong project ref for Supabase (EU projects have refs that start with the region code).
• A firewall on the dev machine blocking outbound 443 to Stripe's API.
• A missing Node version (most MCP servers want Node 20+).

claude mcp logs <server> shows the server's stderr — first place to look when something is silently broken.

A starting four-server .mcp.json for a UK micro-SaaS

Drop this in your repo root as .mcp.json (or merge into ~/.claude.json). It wires all four servers in their safe shape.

{
  "mcpServers": {
    "stripe": {
      "command": "npx",
      "args": ["-y", "@stripe/mcp", "--tools=charges.read,customers.read,subscriptions.read,refunds.read,disputes.read", "--api-key=${STRIPE_RESTRICTED_KEY}"]
    },
    "supabase": {
      "command": "npx",
      "args": ["-y", "@supabase/mcp-server-supabase", "--access-token=${SUPABASE_ACCESS_TOKEN}", "--project-ref=${SUPABASE_PROJECT_REF}", "--read-only"]
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres", "${POSTGRES_READONLY_URL}"]
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_PAT}" }
    }
  }
}

Commit .mcp.json (it has no secrets — the secrets live in .env). Anyone who clones the repo and runs claude gets the same agent powers.

How MCP changes a UK weekend build

Without MCP, the typical Sunday-afternoon refactor looks like this: the agent rewrites a Stripe webhook handler, you copy real webhook payloads into the prompt as "here's what comes in", you spot a bug, you go back and forth three times. About 45 minutes.

With MCP, the agent reads a real charge from stripe-read, sees the actual fields and currencies (GBP minor units, anyone?), writes the handler against the real shape, and ships. About 12 minutes.

Multiply that across a weekend of work and you free up a couple of hours for the part of the project that isn't yet automated — talking to the first three users, writing the launch tweet, or sitting in the pub with your first GBP 9.99 customer.

Want a data-backed UK business idea every week? Free reports drop every Thursday — keyword volumes, SERP analysis, builder prompts. Browse the latest free report on IdeaStack.

---