Skip to main content
Glama

Deploy files

deploy_files
Destructive

Creates an app from source files, or commits and builds a change to one: every call is a commit and a build, about two minutes. For an edit to an existing app on any preset with a draft runtime, use sync_files first, then publish_draft for one commit. Drafts support Copy/Empty data; startup can answer starting and delivers start notes once. Draft visibility starts at default_public and the owner can change it on the draft row; Google-login apps keep their login. dev_url is private unless the draft is public; do not suggest sharing it unless the owner made it public. Chat-native deploy: publish app source directly, no external git repo needed. Five presets cover almost everything: static (plain HTML/CSS/JS, no install, no build — the default for a page or prototype), vite (front-end needing a build), astro (content sites), fastapi (Python — the default as soon as there is an API, a database or file uploads; also serves your HTML), go (same range as fastapi for a fraction of the memory). The first three run no process and therefore cannot use Postgres or object storage, so start on fastapi or go when the app is likely to need either. Other presets (nextjs, nuxt, remix, sveltekit, flask, django, rust, spring-boot, react, vue, svelte, angular, gatsby, dockerfile) are honored when named but are heavier or harder to edit; node runs a Node server. A payload carrying a server entrypoint (server.js, main.go, …) on the static preset is refused rather than published as inert files; pass framework on the same call to switch preset. get_settings shows whether a database or file storage already exists; kad provisions managed Postgres (DATABASE_URL) and S3-compatible object storage (S3_ENDPOINT/S3_BUCKET/S3_ACCESS_KEY/S3_SECRET_KEY/S3_REGION/S3_FORCE_PATH_STYLE) and injects them into the app's environment, so the app needs no external database or storage provider; uploaded files belong in the object storage, not in Postgres columns. Pass files[] (path+content) to create or update an app; kad commits them to a managed repo and builds+deploys. Omit app_id to create a NEW app (app_name required); pass app_id to update an existing one (send only changed files, plus delete_paths[] to remove files). Write intent as a Conventional Commits subject — it is the commit message shown in the app's timeline. Every call is a commit and a build: iterate with sync_files (a draft) and call this once with the final files, not once per small edit; a running draft keeps running afterwards. Returns project_id, commit_sha, job_id, build_log_stream_url, the deploy_url and canonical_host the platform assigned (hostnames are not derivable from the app name), whether the commit shipped public, and the managed backends already wired in. A new app is created as a temporary 72h project when the plan has no free permanent slot; for a temporary project the reply also carries expires_at and a notice stating the deadline and how the project is kept. Each file accepts an optional sha256 (hex) to verify against; on any mismatch the whole call fails before anything is committed, naming the offending file(s), and the response echoes each file's actual sha256 in files[]. Requires a read-write token.

Input Schema

NameRequiredDescriptionDefault
filesNofiles to create or overwrite
modelNothe coding-agent model, best-effort, recorded for analytics
app_idNoexisting project id to update; omit to create a NEW app
intentNocommit subject for this deploy, in Conventional Commits form — 'feat(gallery): photo upload', 'fix: contact form validation'. It is the message shown in the app's commit timeline; an un-prefixed subject is prefixed automatically
app_nameNodisplay name for a NEW app (required when app_id is omitted)
frameworkNoframework preset for a NEW app. Prefer static (plain HTML/CSS/JS, no dependency install or build) whenever the request can be satisfied by static files. Use a server framework only when the requested behavior requires server-side execution. Omit to auto-detect from the files; pass it explicitly when detection fails
delete_pathsNopaths to remove (updates only)

Output Schema

NameRequiredDescriptionDefault
filesNo
job_idNo
noticeNo
publicYes
statusNopresent, and always "pending_approval", only when this call was parked instead of run immediately because the project's (or kad-back's own) plan-mode setting requires a human to approve it first
messageYes
plan_idNopoll get_plan_status with this id for the eventual outcome
frameworkNo
approve_atNothe kad.dev dashboard URL a human approves or rejects this plan from
attempt_idNo
commit_shaYes
deploy_urlNo
expires_atNo
project_idYes
managed_envNo
expires_in_sNothe plan can no longer be approved after this many seconds
is_canonicalYes
canonical_hostNo
managed_resourcesNo
build_log_stream_urlNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond annotations (which only say destructive/openWorld/not-idempotent) by disclosing cost ('about two minutes' per commit+build), refusal behavior (server entrypoint on static preset is refused unless framework is passed on the same call), failure semantics (sha256 mismatch aborts the entire call before anything is committed), token requirements, and the temporary 72h project outcome with expires_at. It also states side effects on drafts ('a running draft keeps running afterwards') and privacy of dev_url — exactly the kind of context annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The first sentence is well front-loaded, but the body is a dense, semicolon-chained block that mixes deploy mechanics, preset taxonomy, provisioning, sha256 verification and return fields in one unbroken paragraph. Several clauses (S3_* env var list, the long parenthetical list of 15 alternate presets) are heavy relative to what an agent needs to select and call the tool. Valuable content, but it would be more usable split into short sections.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter destructive mutation with an output schema and annotations, the description covers the missing pieces: timing/cost, failure modes, prerequisites (read-write token), side effects, and creation-mode caveats. Return values are summarized at a level consistent with the output schema rather than duplicating it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description adds real meaning on top by explaining the create-vs-update contract (omit app_id for new + app_name required; pass app_id and send only changed files plus delete_paths), the Conventional Commits form of intent and that it becomes the timeline message, and the preset-selection logic behind framework. It still repeats some schema text rather than adding new semantics for every field, so it lands just above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource pair: 'Creates an app from source files, or commits and builds a change to one', which cleanly covers both the create and update modes. It explicitly distinguishes itself from the nearest siblings by naming sync_files and publish_draft as the draft-editing path. An agent can tell this apart from deploy_project or redeploy without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use routing: 'For an edit to an existing app on any preset with a draft runtime, use sync_files first, then publish_draft for one commit', plus 'iterate with sync_files ... call this once with the final files, not once per small edit'. It also gives a decision rule for preset choice (static default, fastapi when an API/DB/uploads are needed) and for app_id vs app_name. Exclusions and alternatives are both present.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources