Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
作者提供的说明(英文原文)
Real-world actions for AI coding agents: an inbox with approval outbox, deploys, domains, payments.
这三项永远不会合并成一个分数:意见、测量和人气是不同的东西。
我们还没有为它写通俗的介绍。下面是我们从注册中心读取到的事实。
选择你使用的 AI 应用,然后复制设置。
你需要
你用的是哪个应用?
在上方选择你的应用。我们会记住它,下次按钮会显示“安装到 …”。
打开 Claude Desktop → Settings → Developer → Edit Config,把下面的内容粘贴到 claude_desktop_config.json
{
"mcpServers": {
"clize": {
"command": "npx",
"args": [
"-y",
"@clize/clize"
]
}
}
}在终端中运行这条命令
claude mcp add clize -- npx -y @clize/clize粘贴到项目中的 .cursor/mcp.json,或 ~/.cursor/mcp.json
{
"mcpServers": {
"clize": {
"command": "npx",
"args": [
"-y",
"@clize/clize"
]
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
粘贴到项目中的 .vscode/mcp.json
{
"servers": {
"clize": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@clize/clize"
]
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
这个服务器在你的电脑上运行,而 ChatGPT 只能连接互联网上的服务器。请选择其他应用。
你的选择通过 Cookie 保存在这台设备上,无需账户。
这些设置是根据作者在注册中心的条目生成的。如果 README 的写法不同,请以 README 为准。
它在你的电脑上运行;安装后,工具列表会显示在你的 AI 应用中。
我们检查的是任何人都能看到的信息;我们没有阅读代码。不适用的检查项不计入总数。 · 检查于 2026年11月6日
注册名称已通过域名 clize.ai 验证(注册中心会核实域名所有权)
我们还没有从 GitHub 读取这个仓库
我们还没有从 GitHub 读取这个仓库
它在你的电脑上运行,没有互联网端点
在你的电脑上运行,改用本地设置
它在你的电脑上运行;我们只能读取互联网端点的工具列表
与注册中心里这个分类中所有活跃的服务器比较。只有当发布者拥有该仓库时,星标数才计入。
它在 1 项适用的基础检查中通过了 1 项。我们没有阅读代码。在添加密钥或令牌之前,请先看看这个服务器要求哪些权限,并使用只具备所需权限的密钥。
注册中心没有列出必需的密钥,不过有些服务器会在首次使用时要求你登录。
它在你的电脑上运行。你的 AI 应用会在需要时启动它,数据不会经过作者的服务器(除非它自己调用在线服务)。
GitHub 仓库最后更新于–,最新版本(0.52.0)于24天前进入注册中心。
支持 MCP 的应用,例如 Claude Desktop、Claude Code、Cursor 和 VS Code。你的电脑上还需要有 Node.js。
同一分类中有:Spec Driven Development, Remote Desktop Commander, Dechonet MCP
同一分类中其他作者的服务器,按星标数排序。
如何看卡片:★ GitHub 星标i三大支柱:评价 · 检查 · 使用情况i更新 = 最新版本发布到注册中心的时间i
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
30 security tools for AI agents: phishing links, exposure maps, DNS, SSL, PQC, history, pivots.
按原文从作者的仓库复制。PopNx MCP 没有审查或背书其内容。HTML、图片和脚本已被移除。链接会离开本站。
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](https://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 + 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.app
| Example | What it does | Cost |
|---|---|---|
| 01 · first verification email | install → claim an address with an inbox → read a verification code → queue a reply a person must approve | $0 |
| 02 · HTML → HTTPS → your domain | a three-file folder to https:// .clize.app, then a domain and a mailbox on it | $0 (+ the domain, quoted first) |
| 03 · one SEO loop | clize seo check on a real site → two changes tied to numbers → publish → dated re-read | $0 |
Each one is Clize's own account and site (self-use), not a customer story.
| Log in with | What runs where |
|---|---|
clize login (web: GitHub / Google / email) — or clize login --token clize_… for CI / headless | 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 and clize email send need --domain / --from — unless the directory is bound with clize init --handle , 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 ; 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 . 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.| Area | Commands |
|---|---|
| Identity | clize claim --email — a first-come, free identity for your agent: .clize.app (site placeholder) plus a receiving support@ .clize.app. Without --email you get the name and the site only (clize email setup opens the inbox later) — inbound is opt-in because each inbox costs 4 DNS records in the shared clize.app zone, and that zone is the whole platform's free-handle capacity |
| Domains | clize domain search / tlds / buy / import / list; clize domain check runs six layers in repair order — registry delegation (public DoH) → Cloudflare zone → worker binding → content → edge AI-crawler policy (Cloudflare ai_bots_protection; new zones default to blocking AI crawlers from 2026-09-15, and a blocked edge beats any robots.txt) → http→https (a real http:// request must get a 301 to https; clize turns on Cloudflare's Always Use HTTPS on every zone it deploys to, imports or registers, and domain canonicalize does too) |
The mailbox your agent signs up for services with and reads verification codes from (clize email inbox [domain] --wait-for polls until the mail arrives), and the inbox real people write to. clize email address add opens a mailbox in one step (object + receiving) on any domain you own — as many per domain as you need (ops@, sales@, one per agent or per person); --forward me@gmail.com copies mail to a personal inbox, --owner makes it someone's private mailbox. support@ .clize.app is available on any claimed handle via clize email setup (or clize claim --email). Read with inbox (triaged: promos / notices / spam are filtered, --all shows everything) / show / thread / search, correct triage with mark, send with send (--attach). Mail is stored permanently and indexed. Multi-user: clize members invite alice@corp.com --mailbox alice@ lets a person log in and use their own mailbox; owners/admins see every mailbox in the account. Per-agent keys: clize email key create --scope read,send --address ops@ . Command reference: clize.ai/docs/commands. | |
| Outbox | Interactive clize email send without --confirm lands in an outbox instead of vanishing as a draft: a person approves or rejects it in the console (Home → needs you → Inbox), or from the digest email's signed one-tap link; clize email pending lists what is waiting and status counts it. A standing allowlist (a recipient or @domain, weekly cap 5) can be set only in the console — approvals and the allowlist are refused to CLI-issued keys, so a prompt injection cannot grant itself an exemption. Sends to allowlisted recipients within the cap go out without --confirm. |
| Send API (server-callable) | POST /v1/email/send — transactional email from a long-running backend (fly.io / cron), Resend/Postmark-shaped, sending from a domain already in Clize (no second email vendor). Auth is a scoped send key (clize_sk_…: send-only, lockable to specific domains) — clize email key create/list/revoke. No --confirm (the human-review gate stays on interactive email send). Idempotency-Key, HMAC-signed delivery webhooks (bounce/complaint), RFC 8058 one-click unsubscribe + suppression lists (email delivery-webhook / suppressions / messages). Walkthrough: sending from a backend with a scoped key · webhooks and delivery events. |
| Media | clize gen image / video / music — text→image (gpt-image-2 / nano-banana-2, with --ref / --mask for image-to-image and inpainting), text/image→video (veo), text→music (suno); long tasks via gen jobs / status. Every spend is gated by --confirm (gen budget pre-approval for hosted is on the roadmap). Results land as local files, ready to deploy or email --attach. |
| Build · site (hosted methods) | clize build site start — a hosted design system that briefs your agent on a cohesive style *before* it writes the site, so pages land with taste instead of AI-template sludge. Then build site recommend / list / get / search / review + build site stack for stack-specific guidance (React / Next / SwiftUI / …). The former clize design … spelling still works as a hidden alias. clize build site check [--live ] is the free pre-ship lint: doorway-shaped near-duplicates (≥60% shared visible text) and thin pages, _redirects targets (probed live with --live), hreflang reciprocity, FAQ text vs JSON-LD, canonical/noindex conflicts, sitemap membership — errors exit non-zero. Since 0.41.0 it also reports three GEO warnings (never errors): a comparison page whose first 200 words do not name your own product, a comparison page with no , a content page with no visible date or one over 12 months old. |
| Build · clip (hosted methods) | clize build clip start → your agent writes a shot-by-shot blueprint → build clip check (free local lint: continuity, dialogue coverage, timing) → build clip render --confirm (💰 one summed quote, batch-generate + merge, resumable). One-off footage stays gen video. |
| Deploy | clize deploy --domain — multi-file static sites; free *.clize.app or your own domain. Preview locally first with clize serve (proper Range support — pages actually play in Safari). Deploy runs the same guards as build site check before uploading — doorway-shaped near-duplicates block the upload (--allow-similar to override), and after upload every _redirects rule is probed live; the result rides along in the deploy output as guards (including the three GEO warnings from build site check). Deploy only adds or overwrites: a live path missing from stays online and is listed under `o
只显示了开头部分;其余内容请在仓库中阅读