Skip to main content
Glama

appdesigns App Store screenshots

by click.appdesigns
OverviewDiscussionsAdmin

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

TableJSON Schema
NameRequiredDescriptionDefault
assetNoListing 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
animatedNofalse for a still image (the user asked for one): the moves are kept with motion turned off, so the Motion toggle brings them back.
variantsYesThe directions, each a whole design. The first is the one you would pick.
project_idNoA 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_nameYesThe app's name. It becomes the project name in the user's appdesigns library.
app_store_urlNoThe 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_asNoThe 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_fromNoThe 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.

  1. Changed10 schema fields changed
    • 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"
+}
  2. Changed1 schema field changed
    • 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."
  3. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only establish that this is a non-read-only, non-destructive, closed-world write. The description goes well beyond: it discloses the return payload (preview image per variant, warnings, design_handle, open_url), that checks run before returning, that nothing is public and no account is needed, and a 72-hour window before the design must be opened and saved.

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?

Front-loaded correctly with the when-to-use clause, but the enumeration of asset types ("a product page header, search result, or In-App Event card or page... an X, LinkedIn or Instagram post...") and layer types largely restates the asset enum and layer schema. Those clauses are long and duplicate structured data rather than adding value.

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?

With no output schema, the description takes on return-value disclosure itself (preview images, warnings, design_handle, open_url) and covers the lifecycle caveat of the 72-hour expiry plus the no-account requirement. For an 8-parameter creation tool, nothing needed to invoke it correctly 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 schema already carries per-field meaning. The description nevertheless adds cross-parameter workflow semantics: 1-4 variants where the first is the preferred direction, layers as background+art+icon+text+phone frames with moves, and how project_id/screenshots_from/same_project_as relate to prior tool calls.

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 and resource (create a listing art design) and scopes it precisely: listing art that loops as video or a still marketing image, delivered as an editable project. It names the sibling relationships explicitly (design_handle for update_design, project_handle from create_project), so an agent can separate it from update_design and make_screenshot_set 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?

"Use this when you have designed art for an app yourself and the user should get it as an editable project" gives the triggering condition, and it adds an alternative rule: "Use it, not same_project_as, to add to something the user already saved." It also clarifies that screenshots_from must come from a create_project set in the same conversation.

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 toolsInspect
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.

Resources