Skip to main content
Glama

appdesigns App Store screenshots

Change an asset

edit_asset
Destructive

Use this to change something, after get_asset: one the user saved (asset_id) or a set or design you made in this conversation (handle). Rewrite or restyle text, move, resize or recolour layers, add art you draw as SVG, a library piece (search_library), a phone frame or new text, remove or reorder layers, move or resize the phone or change its model, colour and fold, change the background or the loop, turn the whole set landscape or portrait or give it another size of the same asset (set_canvas), rename, duplicate, reorder or remove screens. Send only what changes, with the revision get_asset returned; the asset changes at once (like an edit in the editor) and the reply has the new revision, previews of the changed screens and warnings. A set or design changed this way keeps changing here: update_project and update_design no longer apply to it. With asset_id (something the user saved) it needs the user signed in to appdesigns (in Claude Code type /mcp, pick appdesigns and choose Authenticate (or run claude mcp login appdesigns in a separate terminal), in Codex run codex mcp login appdesigns; other agents open the sign-in page themselves); with handle (a set or design you made in this conversation, not saved yet) it needs no sign-in.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
handleNoInstead of asset_id: the project_handle create_project returned or the design_handle create_design returned, for something you made in this conversation that the user has not saved yet. Needs no sign-in.
changesYesApplied in order, all or none. Layer positions count from 0 at the bottom of the screen's layers list, the phone included.
asset_idNoThe asset_id list_projects returned.
revisionYesThe revision get_asset (or the last edit_asset) returned. If the asset changed since, nothing changes and you read it again.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changed
    • addedInput schema / properties / changes / items / properties / canvas
      Added value: +{
      +  "description": "set_canvas: the new canvas. Text keeps its place and size, as in the editor, so check the previews and move what needs it.",
      +  "properties": {
      +    "orientation": {
      +      "description": "Turns the set, and the phone with it (the editor's orientation toggle). A size alone keeps the phone's stance, as the size chip does.",
      +      "enum": [
      +        "portrait",
      +        "landscape"
      +      ],
      +      "type": "string"
      +    },
      +    "size": {
      +      "description": "WIDTHxHEIGHT of the same asset: another iPhone display or the twin turned the other way, the Duo's other display, another marketing size (320 to 4096 a side).",
      +      "maxLength": 12,
      +      "type": "string"
      +    }
      +  },
      +  "type": "object"
      +}
    • changedInput schema / properties / changes / items / properties / layer / description
      Previous value: -"set_layer: only the fields to change (motion {\"move\":\"none\"} stops it). add_layer: a whole new text, svg or library layer, with create_design's fields."New value: +"set_layer: only the fields to change; fields get_asset shows that only describe a layer (id, kind, box, what, frame, model_name, screenshot, locked) are ignored. Text: text, x, y, size, font, weight, color, align, line_height, wrap_width, rotation, motion (float, drift or sway). Picture: x, y, width or height, rotation, opacity, flip, tint (library pieces), svg or library (new art), motion. Phone frame layer: phone (a device id), color, fold, orientation, x, y, width or height, rotation, opacity, flip, motion. The screen's phone (\"device\"): shown, model, color, fold (inner-open/Unfolded, outer-closed/Cover, outer-open/Open back), x, y, height or width, rotation (-15 to 15), motion (listing assets). motion {\"move\":\"none\"} stops a move. add_layer: a whole new text (id, text, x, y, size), svg (id, svg, x, y, width), library (id, library, x, y, width) or phone frame (id, phone, x, y, height or width, and color, fold, orientation; screenshot \"screen\" shows the screen's own screenshot, else fill it with replace_screenshots) layer, with create_design's fields."
    • changedInput schema / properties / changes / items / properties / op / description
      Previous value: -"set_layer changes the fields you give of layer id (\"device\" is the phone); add_layer adds layer (on top, or at position to); remove_layer and move_layer (to a position in the screen's layer list, 0 is the bottom) take id; set_background, set_loop and set_title change the screen's; duplicate_screen copies the screen (to the screen number to, default right after it); remove_screen removes it; move_screen moves it to screen number to."New value: +"set_layer changes the fields you give of layer id (\"device\" is the phone); add_layer adds layer (on top, or at position to); remove_layer and move_layer (to a position in the screen's layer list, 0 is the bottom) take id; set_background, set_loop and set_title change the screen's; duplicate_screen copies the screen (to the screen number to, default right after it); remove_screen removes it; move_screen moves it to screen number to; set_canvas changes the canvas of every screen (canvas), as the editor's size chip and orientation toggle do."
    • changedInput schema / properties / changes / items / properties / op / enum
      Previous value: -[
      -  "set_layer",
      -  "add_layer",
      -  "remove_layer",
      -  "move_layer",
      -  "set_background",
      -  "set_loop",
      -  "set_title",
      -  "duplicate_screen",
      -  "remove_screen",
      -  "move_screen"
      -]New value: +[
      +  "set_layer",
      +  "add_layer",
      +  "remove_layer",
      +  "move_layer",
      +  "set_background",
      +  "set_loop",
      +  "set_title",
      +  "duplicate_screen",
      +  "remove_screen",
      +  "move_screen",
      +  "set_canvas"
      +]
    • changedInput schema / properties / changes / items / properties / screen / description
      Previous value: -"Which screen, from 1, as numbered after the changes before this one."New value: +"Which screen, from 1, as numbered after the changes before this one. Every op but set_canvas, which changes them all."
    • changedInput schema / properties / changes / items / required
      Previous value: -[
      -  "op",
      -  "screen"
      -]New value: +[
      +  "op"
      +]
    • addedInput schema / properties / handle
      Added value: +{
      +  "description": "Instead of asset_id: the project_handle create_project returned or the design_handle create_design returned, for something you made in this conversation that the user has not saved yet. Needs no sign-in.",
      +  "maxLength": 100,
      +  "minLength": 10,
      +  "type": "string"
      +}
    • changedInput schema / properties / revision / description
      Previous value: -"The revision get_asset (or the last edit_asset) returned. If the asset was saved since, nothing changes and you read it again."New value: +"The revision get_asset (or the last edit_asset) returned. If the asset changed since, nothing changes and you read it again."
    • changedInput schema / required
      Previous value: -[
      -  "asset_id",
      -  "revision",
      -  "changes"
      -]New value: +[
      +  "revision",
      +  "changes"
      +]
  2. Added

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only declare destructive=true, idempotent=false, readOnly=false; the description goes well beyond that by disclosing the revision-conflict behavior ('If the asset changed since, nothing changes and you read it again'), that the edit takes effect immediately like an editor edit, that the reply carries the new revision plus previews and warnings, and the full auth requirement per mode (signed in for asset_id, no sign-in for handle, with per-client login instructions).

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 routing and auth information is front-loaded, but the middle is one very long run-on sentence enumerating layer/screen/background/canvas operations that the schema already documents, which adds length without new decision-relevant content. It is information-dense yet hard to scan.

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 complex, destructive, no-output-schema tool, the description covers everything an agent needs before calling: prerequisites (get_asset first), the required revision token, both addressing modes, the auth difference between them, immediate-effect semantics, conflict behavior, and what the reply contains (revision, previews, warnings).

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 description coverage is 100%, so parameters are already documented in structured data. The description adds useful framing ('Send only what changes, with the revision get_asset returned'), but the op-by-op behavior it recounts largely mirrors the schema's own op enum and layer descriptions, so it does not meaningfully exceed the 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?

States a specific verb (change) and resource (an asset) and immediately distinguishes the two mutually exclusive target modes: asset_id for 'one the user saved' versus handle for 'a set or design you made in this conversation'. It also names the operation vocabulary (layers, screens, background, loop, canvas) so the agent knows the scope of the edit without opening the 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?

Explicitly gated on 'after get_asset', requires the returned revision, and gives a clear routing rule against siblings: 'A set or design changed this way keeps changing here: update_project and update_design no longer apply to it.' It also names search_library and set_canvas as the paths for specific sub-needs, which is exactly the when-to-use/when-to-use-something-else guidance an agent needs.

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.