appdesigns App Store screenshots

Create a listing art design

create_design

Use this when you have designed art for an app yourself and the user should get it as an editable project: App Store listing art that loops as a video (a product page header, search result, or In-App Event card or page), or a still marketing image (an X, LinkedIn or Instagram post, a link preview, a Product Hunt image, a 16:9 image, Google Play's feature graphic). Takes 1 to 4 variants (directions for the user to choose from), each a background and layers: art you draw as SVG, library pieces, the app's icon, text, and phone frames showing the app (an iPhone, the iPhone Duo open from behind and from the front...), with moves and a loop on listing art. Checks everything and returns a preview image of each variant, warnings, a design_handle for update_design, and open_url, which opens the design in the appdesigns editor, where the user keeps a direction, tweaks any layer, saves it and exports it. Nothing is public and no account is needed. The design waits 72 hours to be opened and saved.

Input Schema

Name	Required	Description	Default
`asset`	No	Listing art: header (3840x1646), search_result (3840x2560), event_card (3840x2160) or event_page (2160x3840). Stills: x_post (1600x900), linkedin_post (1200x627), link_preview (1200x630), instagram_square (1080x1080), instagram_portrait (1080x1350), instagram_tall (1080x1440), product_hunt (1270x760), wide_image (1920x1080), play_feature_graphic (1024x500).	header
`animated`	No	false for a still image (the user asked for one): the moves are kept with motion turned off, so the Motion toggle brings them back.
`variants`	Yes	The directions, each a whole design. The first is the one you would pick.
`project_id`	No	A project_id from list_projects (the user signed in): the new asset is saved into that saved project of theirs. Use it, not same_project_as, to add to something the user already saved.
`project_name`	Yes	The app's name. It becomes the project name in the user's appdesigns library.
`app_store_url`	No	The app's App Store link, if it is on the App Store: the editor's preview phone then shows its real name and icon, app_icon layers use its icon, and a phone layer can show one of its App Store screenshots.
`same_project_as`	No	The project_handle or design_handle of an earlier asset from this conversation (screenshots, a header...). The user's save then files this one in the same project, once they have saved that one.
`screenshots_from`	No	The project_handle of a screenshot set you made with create_project in this conversation (finished, not yet saved): a phone layer's screenshot n then shows that set's n-th capture, instead of an App Store screenshot. No sign-in needed.

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedOct 17, 2026

changedInput schema / properties / app_store_url / description

Previous value: -"The app's App Store link, if it is on the App Store: the editor's preview phone then shows its real name and icon, and app_icon layers use its icon."New value: +"The app's App Store link, if it is on the App Store: the editor's preview phone then shows its real name and icon, app_icon layers use its icon, and a phone layer can show one of its App Store screenshots."

changedInput schema / properties / asset / description

Previous value: -"header (the product page header, 3840x1646), search_result (3840x2560), event_card (3840x2160) or event_page (2160x3840)."New value: +"Listing art: header (3840x1646), search_result (3840x2560), event_card (3840x2160) or event_page (2160x3840). Stills: x_post (1600x900), linkedin_post (1200x627), link_preview (1200x630), instagram_square (1080x1080), instagram_portrait (1080x1350), instagram_tall (1080x1440), product_hunt (1270x760), wide_image (1920x1080), play_feature_graphic (1024x500)."

changedInput schema / properties / asset / enum

Previous value: -[
-  "header",
-  "search_result",
-  "event_card",
-  "event_page"
-]New value: +[
+  "header",
+  "search_result",
+  "event_card",
+  "event_page",
+  "x_post",
+  "linkedin_post",
+  "link_preview",
+  "instagram_square",
+  "instagram_portrait",
+  "instagram_tall",
+  "product_hunt",
+  "wide_image",
+  "play_feature_graphic"
+]

addedInput schema / properties / screenshots_from

Added value: +{
+  "description": "The project_handle of a screenshot set you made with create_project in this conversation (finished, not yet saved): a phone layer's screenshot n then shows that set's n-th capture, instead of an App Store screenshot. No sign-in needed.",
+  "maxLength": 100,
+  "minLength": 10,
+  "type": "string"
+}

addedInput schema / properties / variants / items / properties / layers / items / properties / fold

Added value: +{
+  "description": "phone, iPhone Duo: inner-open (Unfolded), outer-closed (Cover) or outer-open (Open back, the open phone from behind); the editor's names work too.",
+  "maxLength": 30,
+  "type": "string"
+}

addedInput schema / properties / variants / items / properties / layers / items / properties / frame_color

Added value: +{
+  "description": "phone: a colour id of the device from list_devices; default its first.",
+  "maxLength": 40,
+  "type": "string"
+}

addedInput schema / properties / variants / items / properties / layers / items / properties / height

Added value: +{
+  "description": "phone only: its height as a share of the canvas height, instead of width.",
+  "exclusiveMinimum": 0,
+  "maximum": 3,
+  "type": "number"
+}

addedInput schema / properties / variants / items / properties / layers / items / properties / orientation

Added value: +{
+  "description": "phone: upright or on its side; default the way up of the screenshot it shows, else the canvas's (Open back is always on its side).",
+  "enum": [
+    "portrait",
+    "landscape"
+  ],
+  "type": "string"
+}

addedInput schema / properties / variants / items / properties / layers / items / properties / phone

Added value: +{
+  "description": "A phone frame showing the app: a device id from list_devices (iphone-duo, iphone-17-pro-max...). Takes width or height, frame_color, fold, orientation and screenshot.",
+  "maxLength": 40,
+  "type": "string"
+}

addedInput schema / properties / variants / items / properties / layers / items / properties / screenshot

Added value: +{
+  "description": "phone: show screenshot n: the n-th screen of the set screenshots_from names (your own captures), else the app's n-th App Store screenshot (app_store_url). Leave it out for an empty screen, which replace_screenshots fills.",
+  "maximum": 10,
+  "minimum": 1,
+  "type": "integer"
+}

Changed1 schema field changedOct 16, 2026

changedInput schema / properties / variants / items / properties / layers / items / properties / svg / description

Previous value: -"Art you draw: one standalone <svg> with a viewBox and a transparent background, cropped tight to the drawing. Paths, shapes, gradients, clip paths, masks and blur filters only; no <text>, <image>, scripts, CSS animation or outside files."New value: +"Art you draw: one standalone <svg> with a viewBox and a transparent background, cropped tight to the drawing. Paths, shapes, gradients, clip paths, masks and filters only; no <text>, <image>, scripts, stroke-dasharray, feMorphology, CSS animation or outside files."

AddedOct 16, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations cover the mutation profile (readOnly=false, destructive=false, openWorld=true, idempotent=false), but the description adds substantial non-annotation behavior: nothing is public, no account is needed, the design waits 72 hours to be opened and saved, and it returns a preview image, warnings, a design_handle, and open_url. These lifecycle and side-effect details go well beyond the structured fields.

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 usage condition is front-loaded, but the body is a dense run-on sentence heavy with nested parentheticals enumerating asset types and layer kinds. Much of it earns its place (return values, editor handoff, 72-hour window), yet the packing makes it harder to scan than necessary.

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?

For a complex, non-idempotent creation tool with no output schema, the description compensates by naming the return contents (preview image per variant, warnings, design_handle, open_url) and the post-creation editor workflow. It is largely complete, though the relationship to create_project/make_screenshot_set could be sharper.

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 the schema already documents all 8 parameters in depth. The description adds only marginal param meaning (variants are directions, design_handle feeds update_design, open_url opens the editor), so the baseline of 3 applies.

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 and scope: creating app listing art designs (looping video headers, search results, event cards, and still marketing images) as an editable project. It distinguishes itself from siblings by naming create_project's screenshot sets, update_design for later edits, and the editor flow, so an agent can route correctly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a clear trigger ("use this when you have designed art for an app yourself and the user should get it as an editable project") and points to update_design for subsequent tweaks. It does not explicitly state when NOT to use it versus create_project or make_screenshot_set, so no exclusion guidance is present.

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

All appdesigns App Store screenshots tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Create a listing art design

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources