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

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.7/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and readOnlyHint=false, so the safety profile is covered. The description adds substantial context beyond that: the asset mutates immediately, the reply carries the new revision, previews of changed screens and warnings, the revision guard means a stale revision causes no change, and edits are applied atomically ("all or none").

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?

It is front-loaded well with the core purpose and the asset_id/handle fork, but the middle collapses a very large op surface into one sprawling run-on sentence, making it hard to scan. The content is largely non-redundant, but the wall-of-text form costs readability.

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 4-parameter mutation tool with no output schema, the description covers everything an agent needs: when to call it, auth per target type, revision/conflict semantics, atomicity, the shape of the reply, and the relationship to update_project/update_design. Nothing material is left unstated.

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 100%, so the schema already carries most parameter meaning and a baseline of 3 applies. The description nonetheless adds semantics the schema does not: "Send only what changes, with the revision get_asset returned" clarifies partial-update and revision-chaining behavior, and the handle/asset_id distinction is framed as a usage choice rather than a type.

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+resource ("change something") and immediately scopes it to two targets: a saved asset via asset_id or an in-conversation set/design via handle. It then enumerates concrete capabilities (restyle text, move/resize layers, add SVG art, reorder screens, set_canvas) and explicitly distinguishes itself from siblings by stating that update_project and update_design no longer apply once an asset is edited this way.

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 states the prerequisite ("after get_asset"), the two usage modes with their respective auth requirements, and the routing rule against alternatives (update_project/update_design stop applying). Sign-in instructions are spelled out per agent (Claude Code, Codex, other agents), leaving little to inference.

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.