Skip to main content
Glama

Publish

publish
Destructive

Create an app from its files, or change one.

A change takes app_id and base_version (the version get_app_context or the last publish returned) and only the files and assets that changed. To change part of a file, send edits instead of the file: "edits": [{"path": "index.html", "find": "old text", "replace": "new text"}]. find must occur once, unless count says how many times, and a miss refuses the publish and says what it found. Without base_version a publish replaces every file. A stale base is refused, so someone else's change is reloaded rather than overwritten. An app is named by an app_id from a reply or list_apps, never found by name.

A create omits app_id and takes intent. Files are a single client-side page: index.html plus css/js, plain text, no build step, no server. A picture, font or sound is an asset: listed in assets with its sha256 and byte count, and the reply says where to PUT its bytes before publishing again. Changes start from the files get_app_context returned, not the HTML at the app URL. Files carry literal angle brackets.

Every call takes work_context (goal, current_state, decisions, open_work, verification, known_issues; no credentials, transcripts, or stored records) and summary (one line of 200 characters or fewer, in the person's words). When work stops unpublished, checkpoint_app saves that context with the exact base_version.

An app that stores data uses window.cloche and declares collections in schema. get_deploy_instructions returns the runtime API, the purpose-built AI surface, the authoring rules, and the less common publishes: rename, reserve an address before the files exist, share or invite while creating, slug, icon.

A local folder with server code (Flask, Express, SQLite, login routes, database URLs) is rewritten into this shape before publishing. Its server is neither uploaded nor run, its credentials are dropped, and no auth is invented: window.cloche and schema replace them. A rewrite of any existing tool, including a browser localStorage app, keeps every persisted entity and field from the source store, including optional fields and nested groups such as folders, as schema collections and fields, and adds no feature the source lacked.

Data from a private or external source travels as data_publication with the files, never as rows in files or work_context: the collections and fields the app reads and the recipe of read-only tool calls that produces them. Its shape is the example get_deploy_instructions returns. Those collections are shared in schema, and the app reads them through window.cloche.data like stored ones.

Cloche runs the recipe for each person who opens the app with that person's own access to the source, so everyone sees what they can already see there. No model or generated code runs it. An owner's publish goes live; an editor's reading anything new waits for approval at the Data address this call returns, where the owner can keep a copy.

A changed source, argument, selection, collection, or field is a new publication: the files go again with the complete publication details.

The result's bundle_bytes is what the app's files now total, for checking the change. An app far smaller than before was sent truncated, not edited. get_app_context with version returns a past version. Its files published against the live base_version put a damaged live version back.

Files are live only when this call returns ready.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
iconNowhen creating: a Tabler icon name saying what the app is, e.g. list-check. An unknown name is read by its words, then the app name
nameNodisplay name; with app_id and no files: rename
roleNofor a grant share, user or editor; for a link, omit or user -- a link cannot be editor
slugNofull label on rename; creation adds the organization handle. Earlier names open until removed
editsNowith base_version, change part of a file without sending it whole
filesNothe app bundle's files, inline
shareNowhen creating: how to share it once live: "link", "public", or "grant" by subject_or_email; omit to keep it private
app_idNoomit to create; otherwise the app_id from a reply or list_apps
assetsNobinary files (images, fonts, audio, video) by path, sha256 and byte count; the reply says where to PUT the bytes before a second publish
intentNowhen creating: what the app is for, in the author's own words
schemaNocollections this app stores; needs files on create; omit for an app that stores nothing. A replace takes the whole schema again
summaryNoone line of 200 characters or fewer, naming what this is or what changed, in the words the person would use for it
base_versionNothe version get_app_context or your last publish returned; files may then carry only what changed
organizationNowhen creating: which organization to create it in; omit to use your personal one
work_contextYescompact continuation state for the next session: no credentials, transcripts, or stored app records
removed_pathsNopaths to delete from the version named by base_version
contract_versionNo
data_publicationNowith files: the collections and fields this app reads from a source, and the recipe of read-only tool calls that produces them; never rows
subject_or_emailNowho to invite when share is "grant": their email address, or their Cloche account id
development_tokenNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesthe app's own URL; it stays private unless you shared it
nameNo
app_idNo
reasonNoset when status is "failed" with what stopped the publish or "awaiting_upload" with the next step to finish the upload
statusNo"ready" when the files are live, "failed" when nothing went live, "reserved" when this call only took the address and there are no files yet, "awaiting_upload" when this call went no further than naming the bytes it needs -- nothing is live
uploadsNoset when status is awaiting_upload: a signed url per asset that takes its raw bytes by PUT. The same publish arguments sent again then complete it
versionNothe version this publish put live, and the base_version of the next change to this app
data_urlNowhere the owner keeps a copy, and approves a data update that waits
deploy_idNo
share_urlNothe link people open, when share was "link"; the app's own URL stays private
access_noteNoset on every publish while the app is private with nobody invited and no link, so only its owner can open it; this result's own message already says it
asset_bytesNowhat this app's assets total now, against asset_cap_bytes
bundle_bytesNowhat this app's files total now, against bundle_cap_bytes
asset_cap_bytesNo
continue_promptNousually absent today; when present, a short message the person can paste into any agent to keep working
bundle_cap_bytesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / data_publication / properties / recipe / properties / snapshot / additionalProperties / properties / cells
      Added value: +{
      +  "description": "With columns: path on a row to its values, like $.f.",
      +  "type": "string"
      +}
    • addedInput schema / properties / data_publication / properties / recipe / properties / snapshot / additionalProperties / properties / columns
      Added value: +{
      +  "description": "When rows are lists of values: path to the column names, like $.schema.fields[*].name. Fields then name columns.",
      +  "type": "string"
      +}
    • addedInput schema / properties / data_publication / properties / recipe / properties / snapshot / additionalProperties / properties / value
      Added value: +{
      +  "description": "With columns: path on each value, like $.v.",
      +  "type": "string"
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / slug / description
      Previous value: -"Latin URL words before the handle. On an existing app, moves its address and the old one redirects"New value: +"full label on rename; creation adds the organization handle. Earlier names open until removed"
  3. Changed1 schema field changed
    • changedInput schema / properties / icon / description
      Previous value: -"when creating: a Tabler icon name saying what the app is, e.g. list-check; a name Cloche does not carry falls back to its own mark"New value: +"when creating: a Tabler icon name saying what the app is, e.g. list-check. An unknown name is read by its words, then the app name"
  4. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true and idempotentHint=false, but the description adds substantial extra context: 'Without base_version a publish replaces every file', 'a stale base is refused', an edit 'miss refuses the publish', 'Files are live only when this call returns ready', and truncated bundles can be detected via bundle_bytes. This goes well beyond what the annotations provide.

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 create/change distinction is front-loaded, but the body is a dense, fragment-heavy wall of text that mixes creation rules, rewrite policy, data_publication mechanics, and return-value notes. For a 20-parameter tool length is defensible, yet many sentences could be trimmed or moved to parameter descriptions for scanability.

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

Completeness4/5

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

Given the complexity and the presence of an output schema, the description covers nearly everything an agent needs: create vs change, base_version discipline, assets, schema collections, data_publication, summary/work_context, and rewrite rules. Only minor fields (contract_version, development_token) are left unaddressed, so it is close to complete.

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 description coverage is 90%, so the baseline is 3, but the prose adds cross-parameter meaning the schema cannot: app_id is 'never found by name', base_version is cross-referenced to get_app_context, edits require base_version, and assets require a second publish to PUT bytes. A couple of params (contract_version, development_token) remain unexplained in both places.

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?

The opening 'Create an app from its files, or change one' states a specific verb (create/change) and resource (app) and immediately splits the two modes. The description also distinguishes this tool from siblings by scope (checkpoint_app saves context when work stops unpublished; get_app_context reads versions) so an agent can route without opening schemas.

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?

It names alternatives with the condition that selects them: 'To change part of a file, send edits instead of the file', and 'When work stops unpublished, checkpoint_app saves that context'. It also clarifies that an app is identified by app_id from list_apps, and that get_deploy_instructions covers rarer publishes (rename, reserve, share), giving explicit routing.

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.