A Claude Code MCP server for things that happen outside the sandbox

What a Claude Code MCP server actually is

The Model Context Protocol is the socket Claude Code exposes for tools it didn't ship with. An MCP server is a separate program on the other side of that socket: it declares a list of typed tools, Claude Code sees them, and it can call one mid-conversation and read the result. Registration is one line, and after it the tools are simply part of what the agent knows how to do.

That's the mechanism, and it's neutral. What determines whether a given server is worth its slot in your context window is not the protocol — it's what the tools on the other end are allowed to touch.

The Claude Code MCP list everyone publishes

We read the long roundups that rank for this term — three of them run past 2,400, 2,900 and 3,200 words — and de-duplicated their recommendations. Between them they name well over thirty servers. Once you fold the overlap, you're looking at the same short list:

• Repository and file access — a GitHub server, a filesystem server. Reads issues, PRs, and local files into the conversation.
• Databases — Postgres and friends. Runs the query so the agent can reason about real rows instead of your description of them.
• Documentation — Context7 and similar. Pulls current library docs so the agent stops inventing an API that was removed two versions ago.
• Browsers — Playwright. Drives a page, scrapes the answer, screenshots the result.
• Search — Exa and web-search servers, for when the answer isn't in your repo.
• Work trackers and workspaces — Linear, Slack, Notion, Sentry. Tickets, threads, pages, stack traces.
• Reasoning helpers — Sequential Thinking and friends, which add no external data at all and simply restructure how the model plans.

This is a good list. If you install nothing else, docs plus repo plus database covers most of what makes a coding agent wrong. It is also, from top to bottom, one category wearing seven hats.

What every server on that list has in common

Each of them exists to widen what Claude Code can see. Better context, fewer hallucinated APIs, fresher facts. Enormously useful — and when the session ends, the world is exactly where it was.

The fair objection is that some of them write: a Linear server opens issues, a Slack server posts messages, a Notion server edits pages. True, and it doesn't change the shape. Those writes land inside a workspace you already administer, under credentials you already hold, in a system that already knew who you are. Nothing crosses the boundary of your own accounts. Nobody outside gets a bill, a domain, an email from a stranger, or a page they can open.

So the honest summary of the standard Claude Code MCP stack: the agent can now read almost anything, and still cannot cause anything. That's the gap this page is about.

The category the roundups skip: actions with a consequence

There is a second kind of MCP server, and there are very few of them, because it's the harder kind to build responsibly. Its defining property is simple: after the tool call returns, something exists in the world that did not exist before, and closing the terminal will not take it back.

Clize is that kind. Four verbs, all of them irreversible in the way that matters:

You can tell the two categories apart with one question: if the agent got this wrong, would an apology be enough? For a docs server, yes. For a registered domain, a sent email, a live page, or a charged card, no.

What it looks like in a session

Concretely, this is a first hour with the server connected. Give the agent an identity of its own — a free handle with a site and a support@ inbox attached:

$ clize claim acme --email        # acme.clize.app + support@acme.clize.app
$ clize init --handle acme        # this directory now needs no arguments

Now the agent has an address it can sign up for services with, and it can sit and wait for the verification code to arrive rather than asking you to paste it:

$ clize email inbox --wait-for "verification code"
$ clize deploy ./site             # live over HTTPS
$ clize status                    # who is waiting, what is deployed, this month's spend

The inbox is triaged by default: people and verification codes surface, promotions and notices are filed away, and --all shows the rest when you want it. Deploys serve a real 404 for unknown paths when your build ships a 404.html, which matters if the site is meant to be indexed. And clize status is the command worth starting every session with — it's the one place that answers "what did the agent already do".

Why this category needs gates the reading servers never did

A documentation server that returns something wrong wastes a few minutes. A server holding these four verbs can spend your money, put your name on a message, or publish something you hadn't approved. So the interesting engineering isn't the tool list — it's the three places where the layer refuses to act by itself.

• Spending stops for a human. Every command that costs money returns a price and does nothing else. clize domain buy example.com is a quote; registration happens only when someone adds --confirm. Generated images and video work the same way.
• Your name doesn't leave without you. Composing a reply and sending it are two separate acts. The agent writes the draft; the mail moves only on an explicit confirmation. There is no configuration that turns the agent into an unattended sender.
• Arriving mail is text, not orders. Anything in the inbox is material to summarize and answer. A message that contains instructions is quoted, not obeyed — which is the whole reason an agent can be handed a public address at all.

Those rules live in the layer, not in the prompt, so they hold the same whether the request came from Claude Code, from the Codex CLI, or from a plain shell.

Add it to Claude Code

Two commands to install, one to wire it in:

$ npm i -g @clize/clize
$ clize login
$ clize install --claude --mcp

The manual equivalent of that last line is claude mcp add clize -- clize-mcp, and claude mcp list confirms it. For the four-step walk-through with what each command prints, see the step-by-step setup guide.

Skill, MCP, CLI — and why MCP is opt-in

There are three layers, and you don't need all of them on day one.

• The skill is the trigger layer. It's what makes Claude Code think of this at the right moment — when you say "sign up for that with your own address" or "ship it" — and it carries the operating rules with it.
• MCP is the structured tool layer: 32 typed tools with schemas, for when you want the agent calling functions rather than composing shell commands.
• The CLI is the layer underneath both. Same operations, deterministic, scriptable, and available in a terminal with no agent attached.

Note what clize install does by default: it installs the skill and skips MCP. That's deliberate. A registered MCP server puts its tool list and instructions into context at the start of every session, used or not — a standing cost you pay in tokens on every conversation, including the ones about CSS. The skill is a few lines until it's needed. Add --mcp when the structured layer earns its rent.

If it half-earns it, register a subset. One npm package ships everything and a profile narrows the tool list without renaming a single tool: inbox (13 tools), storefront (15), sites (5), domains (9). It's a context budget, not a permission boundary.

$ claude mcp add inbox -- clize-mcp --profile inbox

The same install reaches Codex

Worth knowing before you run it, because it's the part people expect to have to repeat. clize install probes the machine for each host's config directory and writes to every one it finds in a single pass. The skill lands in ~/.claude/skills for Claude Code, and in the open ~/.agents/skills that Codex, Pi and OpenClaw all read.

That's two copies of the file, not one shared folder — the directories are genuinely separate — but it's one command, and clize install --dry-run prints both blocks before touching anything. MCP registration is per-host syntax underneath, which the installer handles. The account below all of it is single: a domain bought from Claude Code is already there when Codex starts. We wrote that out in full in Claude Code vs Codex.

Where this fits with the roundups

Nothing here argues against the standard list — a docs server and an action server aren't competitors, they're different layers of the same stack, and the good sessions use both. Context servers make the agent right; an action server makes it finish. If you want the wider survey rather than this one category, we keep one: MCP servers sorted by the job they do, including which SEO data servers are worth a slot.

And if you'd rather see the capability pages than the protocol: the agent's inbox, deploys, domains, and the storefront each go one level deeper. A support desk is one tag on the same inbox — see customer support with an agent and an inbox.

$ npm i -g @clize/clize
$ clize login
$ clize install --claude