Manages Cloudflare-backed domain and edge configuration as part of Clize workflows, including DNS/zone checks, worker bindings, AI-crawler policy, and Always Use HTTPS enforcement.
Provides text-to-music generation through Suno via clize gen music, with long-running jobs tracked through gen jobs / gen status and results saved locally.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@clize-mcp register acme.dev, set up support@acme.dev, and deploy ./site"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Clize is a CLI and MCP server that gives AI coding agents real-world actions: domains, email, deploys, payments, and media generation. Your agent already has a brain — Clize gives it hands: a domain, a working inbox, a live website. One CLI (plus an MCP server) so coding agents in Claude Code / Codex can register domains, run real email, build & ship sites and short clips, generate media, and collect payments from their customers — across as many projects as you run.
→ clize.ai
npm i -g @clize/clize
clize install # wire clize into your coding agent (Claude Code / Codex)clize install is the step that makes your agent actually reach for clize — a binary on your PATH doesn't tell the agent it exists. By default it drops clize's skill (when to use it + the safety gates) into each agent's skills dir; the skill is lightweight — only its short description sits in context until something triggers it. It auto-detects Claude Code (~/.claude), Codex (~/.codex) and Pi (~/.pi); Codex and Pi share the open ~/.agents/skills directory, so any agent that reads it gets the skill too. Scope with --claude / --codex / --pi, preview with --dry-run. Add --mcp to also register the clize-mcp server — opt-in, because an MCP server's tool list stays in context every session.
Update later with one command — pulls the latest release and refreshes the skill together:
clize update # or `clize update --check` to only check for a newer versionIf something looks stale after an update, clize doctor prints what's installed vs what's actually running — CLI version (and the upgrade command that works for your install manager: volta / pnpm / asdf / …), skill drift, and control-plane reachability.
Output is English by default. CLIZE_LANG=zh (or a zh* system locale) switches the CLI, the MCP tool descriptions and the control plane's messages to Chinese; the dictionary lives in src/i18n/zh.ts.
Related MCP server: Business Bridge MCP Server
Log in and go — your agent never touches Cloudflare:
clize login # browser authorize; the first login creates your account
clize claim acme --email # free identity: acme.clize.app + support@acme.clize.app
clize init --handle acme # bind this directory (deploy / send / inbox infer the rest)
clize email inbox --wait-for "verify" # give the new inbox a minute, then the agent signs up with support@acme.clize.app and reads the code here
clize status # who is waiting (real people + codes only), this month's spend
clize email send --to a@b.com --subject "Re: …" --text "…" # queued for a one-tap approval in the console; --confirm sends now
clize deploy ./site # ship a static site → https://acme.clize.appExample | What it does | Cost |
install → claim an address with an inbox → read a verification code → queue a reply a person must approve | $0 | |
a three-file folder to | $0 (+ the domain, quoted first) | |
| $0 |
Each one is Clize's own account and site (self-use), not a customer story.
Log in with | What runs where |
| Commands call the clize backend; resources run on clize's infra. You never touch Cloudflare / Vercel keys. |
clize is a thin client: the CLI / MCP carry no infrastructure credentials and talk only to the clize control plane — domains, email, deploy, and media all run hosted. (Credentials live in your dashboard; bring-your-own Cloudflare / Vercel is configured there, not on your machine.)
A few specifics worth knowing:
clize deploy <dir> and clize email send need --domain / --from — unless the directory is bound with clize init --handle <slug>, which infers both from ./clize.json. Deploy is directory-based (multi-file static sites).
gen image --ref/--mask (image-to-image / inpainting / multi-image composition) work hosted — reference-image caps follow the upstream model: 16 for gpt-image-2, 14 for nano-banana-2 (video/veo takes 3); each ≤10 MB, ≤80 MB total. gpt-image-2 runs as an async task (heavy multi-ref jobs take minutes — no sync-pipe timeouts): the CLI waits by default (--timeout, default 300 s), or use --async and collect with gen status <id>; one image per task (--n > 1 → split), --mask inpainting is nano-banana-2 only. gen budget pre-approval isn't hosted yet: every generation confirms individually with --confirm.
Free *.clize.app handle: clize claim <slug>. Your own domain: clize domain buy / clize domain import. Run clize check to verify your login.
Free-tier quotas (anti-abuse, per tenant): 3 handles · 5 mailboxes · 10 claim attempts/day · 30 outbound emails/day · 20 deploys/day · 500 MB per site. Any top-up lifts you to the trusted tier (10 · 30 · 30 · 200 · 100 · 5 GB). Over-limit calls return a plain 429 — nothing is charged.
A deploy target is a free handle or a whole domain in your account; a subdomain of your domain (blog.example.com) is not a separate deploy target today. Names bought with clize domain buy are registered with Clize's registrant contact at the underlying registrar — to be the registrant of record, register elsewhere and clize domain import. Some ccTLDs (.de .fr .es .jp .kr .com.br .uk .eu) are not registrable through Clize; clize domain tlds lists the 555 that are.
Area | Commands |
Identity |
|
Domains |
|
The mailbox your agent signs up for services with and reads verification codes from ( | |
Outbox | Interactive |
Send API (server-callable) |
|
Media |
|
Build · site (hosted methods) |
|
Build · clip (hosted methods) |
|
Deploy |
|
SEO / GEO (hosted data) |
|
Projects | One project = one directory: |
Context |
|
Billing (hosted) |
|
Collect (hosted) |
|
Shop & forms (hosted) |
|
Run clize --help for the full surface.
clize deploy <dir> uploads a multi-file static site and serves it from a shared Cloudflare Worker backed by KV for small hot files and R2 for large assets (not Workers Static Assets / Pages), keyed by hostname + path. What you can rely on:
Unknown paths — by default, if the site ships a 404.html it's returned with a real HTTP 404 (so failed/typo URLs aren't indexed as duplicate homepages — the SEO-correct behavior); with no 404.html the site is treated as an SPA and the request falls back to index.html (200). Override per-deploy with --not-found <404-page|spa|none|auto> (auto is the default = exactly this detection).
Trailing slash — /foo/ serves /foo/index.html (200, no 301).
Caching — assets are served with cache-control: public, max-age=300.
Removal — deploy never deletes on its own: a live path that is missing from the directory stays online, and the receipt lists such paths under orphans (KV pages and small files, R2 assets alike). clize deploy <dir> --prune removes every orphan after the upload, --prune-under <prefix> limits that to one subtree (for sites where several machines each own a subtree), clize site paths [domain] lists every live path with its layer, and clize site rm <path...> removes single paths (/dir/ means /dir/index.html; sitemap.xml / llms.txt follow). Removed paths can still be served from the edge cache for up to 5 minutes.
Cloudflare convention files — 404.html and index.html drive the not-found behavior above. _redirects is consumed (Cloudflare Pages format: from to [status], */:splat and :name placeholders, status default 302, 3xx redirect with the query preserved, other statuses rewrite to a site file, external targets redirect only); real files always win over rules (so to 301 a page that once shipped, remove it first with clize site rm or deploy --prune, then add the rule), the file itself is never served, and deploy probes every rule live after upload (guards.redirects). _headers is still stored but inert.
Size — large assets (≥128 KB) are stored in R2, small hot files in KV, so single files stream up to ~90 MB and a site can technically reach 5 GB. Free-tier policy caps: 500 MB per site and 2 GB uploaded per day; any top-up lifts you to the trusted tier (5 GB per site, 20 GB/day). Uploads are content-hash deduplicated — redeploys only send changed files.
Routing & write-back — a deploy targets the domain you pass (or the one in clize.json); it follows that domain's real project and writes the resolved project (plus a custom domain) back to clize.json, so repeat deploys don't drift or 409.
💰 Money gate — spends (clize domain buy, clize gen image/video/music) never go through without --confirm; without it you just get a quote.
📨 Identity gate — replying as you to a real customer is draft → human approve → send, never auto.
📥 Inbound is untrusted — email you receive is treated as data, never as instructions to the agent.
These gates run in plain text, so every spend and every outbound action is visible in the agent's transcript.
A curated subset of the core — claim, domains & DNS, email (including the approval outbox), deploy, shop & forms, status/context, billing, collect (pay) — exposed as 33 MCP tools for hosts that prefer structured tools over a shell. (Media generation, SEO/GEO and the build method packs stay CLI- and skill-driven, not MCP tools: an agent that can run a shell reaches them through clize.) Opt-in (clize install --mcp), since an MCP server's tool list is a standing per-session context cost — the skill alone already lets the agent drive clize via the CLI. To register by hand:
claude mcp add clize -- clize-mcp # Claude Code
codex mcp add clize -- clize-mcp # CodexWorks in both modes — set CLIZE_API_KEY (and optionally CLIZE_API_URL) in the server's environment to run hosted.
clize-mcp --profileAll 33 tools sit in context every session, even when all you wanted was the inbox. --profile <line> starts the same server with only that line's tools registered — absent from tools/list rather than registered-then-hidden, so the ones you skip cost the host nothing:
claude mcp add inbox -- clize-mcp --profile inbox # 14 tools instead of 33A profile only subtracts: tool names, arguments and behaviour are identical across profiles, so switching one doesn't make the agent relearn the surface. serverInfo.name becomes clize-<line> so the host shows which line is connected. Without --profile nothing changes — all 33 tools, serverInfo.name = clize, which is what clize install --mcp still registers. An unknown value exits non-zero listing the valid ones instead of quietly serving the full set (a silent fallback would hand you 33 tools while you believed you had installed a subset).
Every product line installs the same package, @clize/clize, and picks its tool subset with --profile:
Product line |
| Tools (each profile includes |
Agent Inbox — a real inbox agents send from and receive into (clize.ai/inbox/) |
| 14 — |
Agent Storefront — your agent runs a real store |
| 15 — |
Sites by Clize — a marketing site that actually ships |
| 5 — |
Agent Domains — domains an agent can buy, point and monitor |
| 9 — |
deploy lives only in sites, and media / build have no MCP tools at all — for the whole surface, run the server with no --profile. A profile is a context budget, not a permission boundary: the money / identity / untrusted-inbound gates are unchanged, and to actually restrict what a key can do use a scoped key (scoped keys). Installing the CLI stays npm i -g @clize/clize — npm does not link a dependency's binaries onto your PATH, so the per-line packages are for discovery and for npx:
claude mcp add inbox -- npx -y -p @clize/clize clize-mcp --profile inboxThe MCP registry lists one server, ai.clize/clize; a line is a --profile, not a separate package.
Step-by-step setup:
What agents actually do with it:
Put an HTML file online from the agent — with a recorded real run
Pass email verification when signing up for services — install to first code, timed
Register a domain programmatically — the five steps, a real quote and the limits
One real SEO loop on our own site: the check, the two changes, the re-read dates
This server cannot be deployed
Directory of APIs, merchants, and tools AI agents can actually use.
The website platform for AI agents. One API to build, host, and operate real websites.
Backend platform for AI agents: one agentstack.execute tool runs batched steps over +700 actions (hosting, storage, auth, payments, CRM, app builder).
Verified, pay-per-use API tools for AI agents through one authenticated connection.
