Kleap
OfficialThe Kleap server enables AI agents to create, modify, publish, and manage live websites programmatically.
App Management
List all websites owned by your account (
list_apps)Retrieve metadata for a specific app — status, slug, production URL, published state (
get_app)List source files of an app (
list_app_files)Rename an app (
rename_app)Resolve a domain, URL, or slug to an app ID (
find_app)
Building & Editing
Create a new website from a natural-language prompt (
create_app)Modify an existing site using plain English instructions (
modify_app)Read current file contents before editing (
read_files)Write exact file contents directly to an app — deterministic, no AI credits consumed (
write_files)
Async Task Handling
Poll a build/edit task until completion (
check_task)Resume a failed or stalled task from where it stopped (
retry_task)
Publishing
Publish an app with a verified-live guarantee — only reports live once provably serving (
publish_app)Confirm whether an app is actually live (
get_publish_status)
Domain Management
Search for available domain names across TLDs (
search_domains)Check a domain's DNS and connection status (
check_domain)Connect a domain you already own to a published Kleap app, including routing and TLS setup (
connect_domain)
Account
Check remaining credit balance and current plan (
get_credits)
Allows creating and modifying Astro-based websites from natural language prompts, with automatic deployment and hosting on Kleap.
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., "@KleapBuild a portfolio site and publish it."
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.
Kleap — website infrastructure for AI agents
Your agent builds. Kleap ships it live. Let any AI agent — Claude, ChatGPT, Cursor, or a bash-tool agent like Claude Code — build, edit and publish real, live websites for you. Hosting, database, auth and domains included.
An alternative to Lovable / v0 / Bolt — except it's driven by your agent, and every publish comes with the verified-live guarantee: a site is only ever reported online once it is provably serving — never a hallucinated dead link.
This package is both a CLI (kleap create "…", kleap publish 42, …) and an
MCP server (kleap mcp / no args) — same
account, same ~/.kleap/config.json auth, same underlying /api/v1 REST API.
Pick whichever fits your agent: a shell/bash-tool agent (Claude Code, a cron
script, CI) wants the CLI — one compact line per call, no JSON-RPC framing.
An MCP-native client (Claude Desktop, Cursor, ChatGPT connectors) wants the
MCP server, which this package also is, unchanged.

Above: a real run — your agent writes the code with
write_files,publish_appbuilds & deploys it, and the page is live in seconds. Or just ask Kleap's AI in plain English.
No secrets live in this package — it reads your own KLEAP_API_KEY (or the
token saved by kleap auth login) and talks only to kleap.co.
CLI (for agent shells — Claude Code, Codex, scripts)
If your agent drives a bash tool rather than MCP, use the CLI directly.
Output is 1-3 lines by default (token-efficient — built for an agent reading
its own tool output, not a human terminal), clean exit codes (0/1), and a
--json flag whenever you want the full structured response.
npx -y kleap-cli auth login # opens your browser once, no key to paste
# — or, for CI / non-interactive: npx -y kleap-cli auth key kleap_live_sk_...
npx -y kleap-cli create "a one-page site for my bakery, warm palette"
# ✓ created app 4821 — https://warm-bakery-fold.kleap.io
npx -y kleap-cli edit 4821 "change the headline to 'Roasted slow'"
# ✓ edited app 4821 — https://warm-bakery-fold.kleap.io
npx -y kleap-cli publish 4821
# ✓ published https://warm-bakery-fold.kleap.io
npx -y kleap-cli status warm-bakery-fold.kleap.io # by id, slug, kleap.io URL, or connected custom domain
# ✓ Bakery (4821) — live: https://warm-bakery-fold.kleap.ioCommands
Command | What it does |
| Sign in via browser (OAuth, PKCE loopback) — no key to copy |
| Store a |
| Clear / show current auth |
| Create a site, wait for the build (~5-15 min), print the live URL |
| Ask Kleap's AI to change a site, wait for it to redeploy |
| Publish/redeploy with the verified-live guarantee |
| One-line status: name, id, live URL or "not published" |
| Your apps, one tab-separated row each: |
| Available domains, one per line |
| Connect a domain you own; prints the A record to set |
| Capture a preview screenshot, print its URL |
| Run the MCP stdio server explicitly (same as no args) |
<app> accepts a numeric app id, a slug.kleap.io URL, a bare slug, or a
connected custom domain — resolved server-side in one call
(GET /apps/resolve), same as the MCP find_app tool.
Example: a Claude Code / bash-tool agent
# One-shot: build it, publish it, hand back a URL a human can click.
url=$(npx -y kleap-cli create "a landing page for my podcast" --json | node -e \
'let d="";process.stdin.on("data",c=>d+=c).on("end",()=>console.log(JSON.parse(d).url))')
echo "Live: $url"
# Non-blocking flow (agent does other work while it builds):
npx -y kleap-cli create "a landing page for my podcast" --no-wait --json # → { task_id, app_id, ... }
# ... later ...
npx -y kleap-cli status 4821Exit codes are always clean: 0 on success, 1 on any failure, with a single
✗ <reason> line on stderr (or {"error":{"message":...}} with --json) —
safe to check with $? / try/except subprocess.run(..., check=True) without
scraping prose.
Install once (optional — npx -y above needs no install)
npm i -g kleap-cli
kleap auth login
kleap create "a one-page site for my bakery"Related MCP server: webserver-mcp
MCP server (for MCP-native clients — Claude Desktop, Cursor, ChatGPT)
Same package, same account, same ~/.kleap/config.json auth — just a
different transport for clients that speak MCP
instead of a bash tool.
Easiest — connect with OAuth, no key
Add the hosted connector and sign in. Nothing to generate, nothing to paste — you authorize Kleap in your browser like any other app. Works in Claude Desktop, ChatGPT and Cursor.
https://kleap.co/api/mcpClaude Desktop — Settings → Connectors → Add custom connector → paste the URL → Connect → sign in to Kleap.
ChatGPT — Settings → Connectors → add the URL → authorize with OAuth.
Cursor — Settings → MCP → Add server → paste the URL → authorize.
That's it — same 17 tools, no API key. Skip straight to step 3.
Or — local CLI, sign in with your browser (no key)
Prefer a local stdio process? Sign in once — no key to generate or paste:
npx kleap-cli auth loginThis opens your browser, you authorize Kleap, and the token is saved to
~/.kleap/config.json. After that, npx -y kleap-cli just works. (kleap auth logout / kleap auth status are there too.) Then add a keyless stdio entry to
your client, e.g. Claude Desktop claude_desktop_config.json:
{ "mcpServers": { "kleap": { "command": "npx", "args": ["-y", "kleap"] } } }Or — local CLI with an API key
Prefer a key (e.g. for CI or scripting the REST API directly)?
1. Get an API key — at kleap.co → Settings → API key →
MCP / API access → Generate MCP key (kleap_live_sk_...).
2. Add Kleap to your AI client:
{
"mcpServers": {
"kleap": {
"command": "npx",
"args": ["-y", "kleap"],
"env": { "KLEAP_API_KEY": "kleap_live_sk_..." }
}
}
}{
"mcpServers": {
"kleap": {
"command": "npx",
"args": ["-y", "kleap"],
"env": { "KLEAP_API_KEY": "kleap_live_sk_..." }
}
}
}claude mcp add kleap -e KLEAP_API_KEY=kleap_live_sk_... -- npx -y kleap-cli{
"mcpServers": {
"kleap": {
"command": "npx",
"args": ["-y", "kleap"],
"env": { "KLEAP_API_KEY": "kleap_live_sk_..." }
}
}
}{
"mcpServers": {
"kleap": {
"command": "npx",
"args": ["-y", "kleap"],
"env": { "KLEAP_API_KEY": "kleap_live_sk_..." }
}
}
}Add the hosted connector at https://kleap.co/api/mcp and authorize with
OAuth (or paste your kleap_live_sk_ key). Same tools, no install.
Every stdio config is identical —
npx -y kleap-cli+ aKLEAP_API_KEYenv var — so any MCP client works.
Least-privilege keys: when you generate a key, pick a scope — Read-only (inspect sites, no changes), Build, or Full. Buying domains is never included by default. Give a read-only agent a read-only key.
3. Restart the client and just ask:
"Build me a one-page site for my bakery, publish it, and give me the live URL." "Add a contact form to my site and redeploy." "Change the headline to 'Roasted slow' and publish."
Works with any MCP-compatible agent: Claude · ChatGPT · Cursor · Claude Code · Codex.
Tools
Find & build — find_app · create_app · modify_app · read_files · write_files · rename_app · check_task · retry_task
Publish & domains — publish_app · get_publish_status · search_domains · check_domain · connect_domain
Account — list_apps · get_app · list_app_files · get_credits
Tool | What it does |
| Resolve a domain / URL / slug → app_id in one call |
| Create an Astro site from a prompt → returns a task (auto-deploys live) |
| Ask the app's AI to change it → returns a task |
| Read the current contents of files so you can edit them safely (not blind) |
| Write exact files directly (your code, deterministic) → then |
| Rename the display name (URL stays the same) |
| Long-poll a create/modify task to completion ( |
| Resume a failed/stalled build from partial state (new task_id) |
| Publish with verified-live (live-or-rollback, never a false "online") |
| Confirm a site is actually published + live |
| Find available domains (purchase stays user-confirmed in Kleap) |
| Connect a domain you already own to a live app |
| A domain's connection / DNS status |
| Your apps, an app's details, its files (read-only) |
| Remaining credit balance + plan |
App arguments are snake_case: app_id, task_id, prompt, message, visibility.
Recipes
Two ways to put code on a site — pick per task:
write_files(deterministic): your model writes the exact file contents; you push them and Kleap builds + deploys as-is. No Kleap-AI step → no Kleap credits, never stalls. Thenpublish_app. Unlike Lovable/v0/Bolt, your agent can write the code itself.modify_app(Kleap's AI): describe the outcome in plain English and Kleap's AI writes it. Like Lovable's message-passing — kept for when you'd rather it figure out the change.
Either way Kleap hosts it (build, deploy, SSL, DB, auth, domains, verified-live).
Edit existing files SAFELY (don't rewrite blind) —
list_app_files(app_id)→read_files(app_id, ["src/components/Header.astro"])→ edit only what must change with your own model →write_files(app_id, [{ path, content }])→publish_app(app_id). This read→edit→write loop is the reliable way to fix headers/footers, wrong phone numbers, broken links or dead forms without breaking the rest of the site.Edit a site named by its address —
find_app("mysite.ch")→read_files(...)→write_files(...)→publish_app(...), ormodify_app(app_id, "…")→check_task(task_id, wait=45).Many pages (programmatic SEO) — BEST: generate a dynamic route + a data file with your own model and push them in one
write_files, thenpublish_app:write_files(app_id, [{ path: "src/pages/[service]/[city].astro", content: … }, { path: "src/data/locations.json", content: … }])→publish_app(app_id)Deterministic, scales to thousands, no stall, no credits. (Or ask Kleap's AI to do the same in onemodify_app— never loop one call per page.)Don't babysit a 5-15 min build —
check_tasklong-polls (defaultwait=45), or pass awebhook_urltocreate_app/modify_appfor a fully hands-off flow.A build failed —
TASK_TIMEOUT/STALE_TASK= transient, callretry_task; it returns a new task_id — poll that one.TASK_FAILED= read the message, retry once.
The verified-live guarantee
Most tools tell the agent "it's online" the moment a deploy is requested. Kleap reports a site as published only once the new version is provably serving at its live URL — otherwise it rolls back and reports "not confirmed live." Your agent can never hand a user a dead link.
If check_task reports failed (a transient generation stall), call retry_task
with that task_id to resume from where it stopped — it returns a new task_id
to poll, and partial work is kept. Or skip the AI entirely and write_files the
exact code yourself, then publish_app.
FAQ
Do I need an API key? No. The easiest path is the OAuth connector
(https://kleap.co/api/mcp) — you sign in with your browser and never copy a
key. An API key is only needed for the local CLI / direct REST use.
Is it safe? Yes. Whether you connect with OAuth or an API key, an agent can
only ever touch your own Kleap apps. OAuth tokens and kleap_live_sk_ keys are
scoped, sent only over HTTPS, and revocable anytime in Settings → API key.
Credentials from kleap auth login / kleap auth key are stored in
~/.kleap/config.json (permissions 0600); kleap auth logout deletes that
file. A stored OAuth login is bound to the origin that issued it — if
KLEAP_API_URL points anywhere else, the CLI refuses to send the token
(CREDENTIAL_ORIGIN_MISMATCH) so a malicious/typo'd endpoint can't capture it.
For custom endpoints (e.g. staging), use KLEAP_API_KEY or kleap auth key —
an explicit secret you provide is sent where you point it. Details in
SECURITY.md.
How much does it cost? Connecting is free. Builds and edits use Kleap credits
(get_credits reports your balance) — see pricing.
Which agents work? Any MCP client: Claude Desktop, Claude Code, Cursor, ChatGPT (hosted connector), and others.
Requirements & run
Node ≥ 18. Run it directly:
KLEAP_API_KEY=kleap_live_sk_... npx -y kleap-cli
# → [kleap-mcp] ready (stdio) → https://kleap.co. Tools: list_apps, ...Override the API base with KLEAP_API_URL (default https://kleap.co).
Missing key → the server exits with a clear message. Note: a stored OAuth
login only works against the origin it was issued by — with a custom
KLEAP_API_URL, authenticate via KLEAP_API_KEY or kleap auth key instead
(see SECURITY.md).
Links
Kleap: https://kleap.co · MCP & CLI page: https://kleap.co/mcp
Issues & security: https://github.com/kleaphq/cli/issues
Maintained by the Kleap team. MIT © Kleap.
Available Tools
13 toolscheck_domainA
Check a domain's connection / DNS status for a Kleap app.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The domain, e.g. 'mybakery.com'. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states the tool checks connection/DNS status, which suggests a read-only operation, but does not explicitly confirm no side effects or disclose prerequisites (e.g., domain must be configured).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no wasted words. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one required parameter and no output schema, the description is nearly complete. It could be improved by briefly hinting at the result (e.g., 'returns status or errors'), but as is, it adequately covers the core functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and describes the domain parameter with an example. The description adds value by tying the parameter to the 'Kleap app' context, clarifying the purpose beyond the schema's basic type and example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Check' and resource 'domain's connection / DNS status' within the context of a Kleap app. It clearly distinguishes from sibling tools like connect_domain (action) and search_domains (search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking domain DNS/connection status but does not explicitly state when to use it versus alternatives like check_task or connect_domain. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_taskA
Poll an async task (app creation or edit). Returns status + result when done. If status is 'failed' (e.g. a transient generation stall), call retry_task with the same task_id to resume — don't start over.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | The task id. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses polling behavior and failure handling, but does not explicitly state read-only nature or other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words, front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, and retry guidance; lacks details on return format or error handling, but adequate given simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and description adds no extra meaning beyond the schema's parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it polls an async task for app creation or edit and returns status and result. Distinguishes from sibling retry_task by mentioning when to use it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to call retry_task if status is 'failed' and not to start over, providing clear when-to-use and alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
connect_domainA
Connect a domain the user ALREADY OWNS to a published Kleap app (sets up routing + automatic TLS). The app must be published first; the user points the domain's A record to Kleap. Does not buy anything.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes | The app id (must be published). | |
| domain | Yes | The domain to connect, e.g. 'mybakery.com'. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool modifies routing and enables TLS, and clarifies that it does not buy domains. However, it does not discuss what happens if the domain is already connected, potential side effects, error states, or permission requirements, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with the core action and key constraints. Every word adds value, with no redundancy or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 required parameters) and no output schema, the description should explain what the tool returns or what constitutes success/failure. It does not mention return values, error handling, or prerequisites beyond ownership and app publishing. Sibling tools are available for checking, but the description does not leverage them for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The tool description adds that 'app_id must be published' and gives an example domain, but these are only marginally helpful beyond the schema. The description does not significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Connect' and the resource 'a domain' with specific conditions: the domain must be owned by the user and the app must be published. It also describes what the tool does (sets up routing and automatic TLS) and differentiates from sibling tools like 'check_domain' and 'search_domains' by focusing on connection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit conditions for use: the app must be published, the user must point the domain's A record to Kleap, and it clarifies that it does not purchase domains. It lacks explicit mention of alternatives among siblings or when not to use this tool, but the context is clear enough to guide typical usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_appA
Create a new Kleap website from a natural-language prompt. Returns a task — poll check_task until it completes.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | What the website should be. | |
| visibility | No | 'public' (discoverable) or 'personal' (private). |