Skip to main content
Glama

Edit hosted app source

edit_app_source
Destructive

Change some files of a hosted app without resending the rest, and put the result live as a new version. files adds or replaces files by path, with their full contents as text; delete_files removes paths, and a path the app does not have is ignored without an error, so take paths from get_app_source. Every other file is kept as it is in expected_version. expected_version must be the app's live head_version_number, from list_apps or list_app_versions: if the app changed since, the call fails with stale_app and the live number, so read the files again and redo the change. The result must still meet deploy_app's limits: an index.html, text files only, at most 50 files and 1 MB. Like a deploy, the change makes the app read the board as you; if someone else deployed it last, signed-in visitors have to reload before their next change. The new files can take about a minute to be served. The previous version stays in the history (Playbook keeps the last 50), so revert_app can undo this. An app not deployed since Playbook began keeping versions has no stored files: the call fails with source_unavailable, and deploying its files once with deploy_app starts its history. Requires write scope and permission to edit the board the app shows.

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": {
      "slug": "<slug>",
      "expected_version": "<expected_version>"
    },
    "name": "edit_app_source"
  }
}

Input Schema

NameRequiredDescriptionDefault
slugYesSlug of the app, from list_apps
filesNoFiles to add or replace: full contents as text, keyed by path, e.g. { "app.js": "…" }
commentNoA note stored with the new version, shown by list_app_versions
delete_filesNoPaths of files to remove
organizationNoWorkspace slug, as returned by list_organizations. Omit it when the account has a single workspace — it is then resolved from your token. Pass it only when the account has several, or when you mean a workspace other than the obvious one.
expected_versionYesThe app's live `head_version_number`, as you last read it

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the destructive/non-idempotent annotations it discloses partial-update semantics (other files kept), that unknown paths are silently ignored, two named error conditions (stale_app with live number, source_unavailable), a propagation delay of about a minute, that the change alters the board identity visitors see and may force a reload, and that history retains 50 versions. It also states the required write scope and board permission.

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

Conciseness4/5

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

The purpose is front-loaded and nearly every sentence carries actionable information (limits, errors, retry, undo). It is dense and long for a tool description, but only marginal trimming would be possible without losing behavioral detail.

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 destructive, non-idempotent mutation with a nested-object parameter and no output schema, the description covers constraints (index.html required, text only, 50 files / 1 MB), concurrency, failure modes, recovery, and side effects on the live app. Nothing an agent needs to call it safely is missing.

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, but the description adds real meaning: files are added-or-replaced by path with full text contents, delete_files paths that don't exist are ignored without error, and expected_version is specifically the live head_version_number used for optimistic concurrency. That optimistic-locking semantics goes beyond the schema's terse 'as you last read it'.

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 description opens with a specific verb and resource plus the key differentiator: 'Change some files of a hosted app without resending the rest, and put the result live as a new version.' That immediately separates it from deploy_app (full deploy), get_app_source (read), and revert_app (undo), so an agent can choose correctly 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?

It explicitly routes to siblings for inputs ('take paths from get_app_source', 'expected_version ... from list_apps or list_app_versions'), states the failure-and-retry path for stale_app, and names deploy_app as the way to bootstrap history when source_unavailable occurs. It even states the when-not case indirectly by requiring the app already have stored versions.

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