kad.dev alpha
kad.dev · docs

MCP server and agent tools

Updated Oct 8, 2026

The server is https://kad.dev/mcp. Chat clients connect with OAuth and your kad.dev sign-in; coding agents use a personal access token. The agent acts on your account, within your limits, and gets these docs as tool descriptions.

Connect

  • Claude: Settings → Connectors → Add custom connector. The consent screen lists the two scopes, mcp:read and mcp:deploy.
  • ChatGPT: Settings → Connectors → Advanced, enable Developer mode, then Add custom connector.
  • Claude Code, Codex, OpenCode: the key icon in the dashboard header shows these commands with your token filled in:
claude mcp add --transport http kad https://kad.dev/mcp --header "Authorization: Bearer <token>"

export KAD_TOKEN='<token>'
codex mcp add kad --url https://kad.dev/mcp --bearer-token-env-var KAD_TOKEN

Any other agent can read /agent-setup/prompt.md. A token can be minted read-only; write tools refuse it. To disconnect, remove the connector in your client or revoke it under Chat connectors, behind the same key icon.

The tools

Tool Does
list_projects, list_deployments projects, commits, which one is canonical
create_project, deploy_files a project from a Git URL, or from files sent in the chat; intent names the commit
sync_files, publish_draft, stop_draft writes files into a draft, a temporary running copy of the app, and returns dev_url, with no commit and no build; publish_draft makes it live in one commit; stop_draft stops it and discards its unsaved changes
get_build_status, get_build_logs, get_runtime_logs, probe_app build result, per-step build log, app output, a server-side HTTP GET
expose_commit, promote_commit, rollback_commit visibility, canonical, rollback
get_rollback_status rollback_commit returns at once; this reports the rollback's progress and its end
set_env_vars merges by default and restarts the app
provision_postgres, provision_storage, query_sql, execute_sql, snapshot_now backends

deploy_files names five common presets, static, vite, astro, fastapi and go; other presets, including node, are accepted by name.

Drafts

A draft is a temporary running copy of an app with managed source. Draft runtimes support static, vite, react, vue, svelte, sveltekit, remix, nextjs, astro, nuxt, angular, gatsby, fastapi, flask, django, node, and configured sanic presets. Go, rust and spring-boot drafts need the server's rollout flag. Dockerfile has no draft runtime. sync_files edits the draft without a commit or build. Startup can return starting; call sync_files again to check readiness. Start notes are delivered once in note, including after a slow start.

Copy is the default data choice. Where enabled and available, the draft copies the database and app files at start and reads the bucket live; writes stay in the draft. data: "empty" on the first sync_files, or Empty in the start dialog, starts without that data. A running draft keeps its choice. The reply reports unavailable copies and fallbacks; database and app-file copies depend on the server's rollout flags. Stopped drafts do not keep database, bucket or app-file changes.

A new draft starts with the project's default_public, with or without data. The owner can switch public/private on the draft row; restarts keep that choice. Apps with Google login keep their login and cannot be made public. get_app_status reports the draft's public flag. dev_url is private unless the draft is public; do not suggest sharing it unless the owner made it public. A public draft with copied data shows that copy to anyone with the link. A draft changes nothing about canonical_host or deploy_url.

A draft stops after 30 minutes without a sync, or earlier when the platform restarts; an account runs at most three. When it stops by itself, the files it received are kept for 24 hours. The next sync_files on the project starts a new draft, brings them back and says so in note. stop_draft stops a draft and discards those unsaved changes for good.

To make the work live, iterate with sync_files, then call publish_draft once: it commits what the draft holds, like Save in the dashboard, so no file is sent again. One publish per small edit fills the timeline and is slow. The draft keeps running after it.

Approvals

Read tools never ask. Settings → Agents lists every gated tool with auto (the default) or ask, per project and per tool: promote_commit, demote_commit, delete_commit, stop_commit, set_env_vars, update_settings, execute_sql, redeploy, deploy_project, deploy_files, expose_commit.

illustration
An agent calls promote_commit set to ask: the chat shows pending_approval, a plan card appears in the header, you approve, it runs

A call set to ask returns pending_approval and a plan id instead of running. A plan card appears in the dashboard header; approving it there executes the call, and the plan expires after 15 minutes. The agent waits with await_plan or polls get_plan_status. A deploy_files that creates a new app has no project to gate, so it runs.

This gate is kad.dev's own. Your client can also ask before it calls a write tool; that prompt belongs to the client.

Limits

  • No custom domain and no object delete over MCP: dashboard only. delete_project deletes a project; it cannot be undone.
  • The 20 builds per day include agent builds. With no free permanent slot, create_project makes a 72-hour project and says when it ends.
  • Your conversation is not kept: a tool call carries only its arguments; kad.dev logs the client's name and write actions.
BUILT SLOWLY · SOLO · EU-HOSTED | BUILD 2a0ff80