Skip to main content
Glama
Sign In

noback

by app.noback
OverviewDiscussions(1)Admin

update_app

Publishes a new version of an app you published, with the same checks as create_app. Send the credential you got from connect_status (or the editKey of an app published before approvals existed). The first time you publish, the person approves you once in their browser, with or without a noback account; nothing is needed before. Without credential it doesn't publish: it returns status approval_needed, connect (url, code, pollKey) and next. Then, by yourself: open connect.url in the person's browser (open on macOS, xdg-open on Linux, start on Windows, or navigate there if you have a browser), or if you can't, show them that link in one line in the language of the conversation; call connect_status with pollKey (it waits until they approve; call it again while it says pending); as soon as it says approved, call this tool again with the same content and credential: token. Don't ask the person to type anything. The data and the link stay as long as you keep the same app.db collections and fields and the same localStorage keys. Returns openUrl, version, message and warnings.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "appId": "<appId>"
    },
    "name": "update_app"
  }
}

Input Schema

NameRequiredDescriptionDefault
htmlNoThe complete contents of ONE HTML file, with its CSS and JS inline. Don't add the noback SDK by hand: noback injects window.app. Send html or zipBase64, not both.
appIdYesThe app's short id, as returned by create_app or list_apps (e.g. "a-x7k2pq").
editKeyNoOnly for apps published before connecting existed: the private edit key create_app returned then. Never put it in the HTML, the data or a shared link.
zipBase64NoA complete .zip package encoded in base64, instead of html: index.html at the root, an optional noback.toml, plus scripts, styles and files. Send html or zipBase64, not both.
credentialNoThe token connect_status returned after the person approved you. Send it on every create_app and update_app in this conversation (or as the header Authorization: Bearer <token>). Leave it out the first time: create_app then asks for approval. Never show it to the person or put it in an app.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / credential
      Added value: +{
+  "description": "The token connect_status returned after the person approved you. Send it on every create_app and update_app in this conversation (or as the header Authorization: Bearer <token>). Leave it out the first time: create_app then asks for approval. Never show it to the person or put it in an app.",
+  "minLength": 20,
+  "type": "string"
+}
    • changedInput schema / properties / editKey / description
      Previous value: -"The private edit key returned by create_app. Never put it in the HTML, the data or a shared link."New value: +"Only for apps published before connecting existed: the private edit key create_app returned then. Never put it in the HTML, the data or a shared link."
    • changedInput schema / required
      Previous value: -[
-  "appId",
-  "editKey"
-]New value: +[
+  "appId"
+]
  2. Changed4 schema fields changed
    • changedInput schema / properties / appId / description
      Previous value: -"Nombre corto de la app devuelto por create_app o list_apps."New value: +"The app's short id, as returned by create_app or list_apps (e.g. \"a-x7k2pq\")."
    • changedInput schema / properties / editKey / description
      Previous value: -"Clave privada de edición devuelta por create_app. Nunca la incluyas en el HTML ni en el link público."New value: +"The private edit key returned by create_app. Never put it in the HTML, the data or a shared link."
    • changedInput schema / properties / html / description
      Previous value: -"Contenido completo de UN archivo HTML; CSS y JS inline, sin SDK manual."New value: +"The complete contents of ONE HTML file, with its CSS and JS inline. Don't add the noback SDK by hand: noback injects window.app. Send html or zipBase64, not both."
    • changedInput schema / properties / zipBase64 / description
      Previous value: -"Paquete .zip completo en base64, en lugar de html. index.html en la raíz; noback.toml opcional."New value: +"A complete .zip package encoded in base64, instead of html: index.html at the root, an optional noback.toml, plus scripts, styles and files. Send html or zipBase64, not both."
  3. First observed

TDQS

A4/5.0
Behavior3/5

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

Annotations only declare that the tool is a non-read-only, non-destructive mutation, so the description adds real value by disclosing the approval gate, the approval_needed return shape, the returned fields, and the data/link persistence rule tied to unchanged collections, fields and localStorage keys. It still does not describe what "the same checks as create_app" actually validates (size limits, HTML rules) or what warnings look like, which is the main behavioral gap for a publish operation.

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 core action and the approval fallback are front-loaded and clearly ordered, but the description is long and drifts into cross-tool agent instructions (how to open a URL on macOS/Linux/Windows) that do not describe this tool's behavior. Sentences like "Don't ask the person to type anything" are operational guidance rather than tool semantics, costing some concision.

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?

With five parameters, a 100% schema coverage, and no output schema, the description does the needed work: it summarizes the return fields and explains the approval round-trip that dominates the calling contract. Only the nature of the create_app parity checks remains unexplained.

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

Parameters3/5

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

Schema coverage is 100% and each parameter already carries a detailed description, so the baseline is 3. The description does add a bit of meaning — that credential originates from connect_status and can alternatively be passed as an Authorization header, and that editKey is a legacy path — but most of this is already repeated in the schema text.

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?

"Publishes a new version of an app you published" gives a concrete verb and resource, and the phrase "with the same checks as create_app" immediately distinguishes it from the sibling that publishes the first version. An agent can tell the two apart without opening either 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?

The description lays out the full selection and sequencing logic: use it only after a successful publish, include the credential from connect_status (or legacy editKey), and if the response is approval_needed, poll connect_status with pollKey and retry with the returned token. It also states the one case where no credential is needed (first publish, in-browser approval).

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

All noback toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources