接入你的智能体
發布者自己的指令。不是 PlugMCP 端點。
用我們的金鑰與日誌託管一份副本。
npx -y @clize/[email protected]Claude Code 沒有本機指令的安裝連結。複製下方指令並在終端機中執行。
claude mcp add clize-clize -- npx -y @clize/clize@0.52.0在終端機中執行。
{ "mcpServers": { "clize-clize": { "command": "npx", "args": [ "-y", "@clize/[email protected]" ] } }}claude_desktop_config.json
遠端 URL 還是本機指令？ 兩種安裝方式的差異
來自發布者
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.
The real-world capability layer for AI agents — domains, email, deploy, media, SEO/GEO. CLI + MCP.
→ 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 version
If 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.
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 + [email protected]
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 [email protected] and reads the code here
clize status # who is waiting (real people + codes only), this month's spend
clize email send --to [email protected] --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.app
Each one is Clize's own account and site (self-use), not a customer story.
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.*.clize.app handle: clize claim <slug>. Your own domain: clize domain buy / clize domain import. Run clize check to verify your login.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.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:
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)./foo/ serves /foo/index.html (200, no 301).cache-control: public, max-age=300.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.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.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.clize domain buy, clize gen image/video/music) never go through without --confirm; without it you just get a quote.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 # Codex
Works 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 33
A 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:
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 inbox
The 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:
The real-world capability layer for AI agents — domains, email, deploy, media, SEO/GEO. CLI + MCP.
{ "mcpServers": { "clize-clize": { "command": "npx", "args": [ "-y", "@clize/[email protected]" ] } }}工具
尚無工具清單。遠端伺服器會在首次健康檢查後取得工具清單。
常見問題
在本頁複製適用於 Cursor、Claude Desktop、Claude Code 或 VS Code 的 stdio 設定。它使用發布者的安裝方式，而不是 PlugMCP 代理伺服器。
這筆記錄未列出必要的環境變數。
@clize/clize 透過 stdio 在本機執行。
上次檢查時間：2026-11-15。 The real-world capability layer for AI agents — domains, email, deploy, media, SEO/GEO. CLI + MCP.
