Skip to main content
Glama
Sign In

appdesigns App Store screenshots

by click.appdesigns
OverviewDiscussionsAdmin

Create a screenshot project

create_project

Use this when you can run shell commands on the user's machine and have their app's screenshots as local files (a coding agent). Not for a chat without a terminal, such as ChatGPT, where the upload command cannot run. Starts a screenshot set: 1 to 6 screenshots in store order, each with a screen name and a headline. Returns a project_handle and one upload command (bash and PowerShell forms) that sends every screenshot straight to storage; run it once, then call finish_project with the handle. Upload and call finish_project within 1 hour (an unfinished project lapses then); a finished one waits 72 hours to be opened. Nothing is public and no account is needed; the user saves the set to their account when they open the link finish_project returns.

Input Schema

NameRequiredDescriptionDefault
foldNoiPhone Duo only: inner-open (Unfolded, the open inner display), outer-closed (Cover, the folded cover display) or outer-open (Open back, the open phone from behind, showing its cover display). The editor's names work too. Leave it out for the display the canvas is.
storeNoWhich store the set is for.app_store
deviceNoA device id from list_devices. Defaults to iphone-17-pro-max for the App Store and pixel-11-pro for Google Play.
screensYesOne entry per screenshot, in the order the store should show them. The first sells the app.
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.
canvas_sizeNoA canvas size from list_devices, as WIDTHxHEIGHT, portrait or landscape (2868x1320 for a landscape iPhone set). Leave it out and finish_project takes the store size the screenshots are (a landscape capture makes a landscape set), else the store default (1320x2868 for iPhone, 2048x2732 for iPad, 2007x2853 for iPhone Duo, 1080x1920 for Play).
frame_colorNoA colour id of that device from list_devices. Leave it out to pick one that stands out from the background.
orientationNoWhich way up the set is, when canvas_size does not say: landscape for an app that runs in landscape (most games), and the phone is drawn on its side. Leave it out to follow the screenshots.
project_nameYesThe app's name. It becomes the project name in the user's appdesigns library.
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.
background_colorNo#RRGGBB. Use the app's brand or accent colour if you can find it in the code. Leave it out for a neutral light background.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / canvas_size / description
      Previous value: -"A canvas size from list_devices, as WIDTHxHEIGHT. Leave it out for the store default (1320x2868 for iPhone, 2048x2732 for iPad, 2007x2853 for iPhone Duo, 1080x1920 for Play)."New value: +"A canvas size from list_devices, as WIDTHxHEIGHT, portrait or landscape (2868x1320 for a landscape iPhone set). Leave it out and finish_project takes the store size the screenshots are (a landscape capture makes a landscape set), else the store default (1320x2868 for iPhone, 2048x2732 for iPad, 2007x2853 for iPhone Duo, 1080x1920 for Play)."
    • addedInput schema / properties / fold
      Added value: +{
+  "description": "iPhone Duo only: inner-open (Unfolded, the open inner display), outer-closed (Cover, the folded cover display) or outer-open (Open back, the open phone from behind, showing its cover display). The editor's names work too. Leave it out for the display the canvas is.",
+  "maxLength": 30,
+  "type": "string"
+}
    • addedInput schema / properties / orientation
      Added value: +{
+  "description": "Which way up the set is, when canvas_size does not say: landscape for an app that runs in landscape (most games), and the phone is drawn on its side. Leave it out to follow the screenshots.",
+  "enum": [
+    "portrait",
+    "landscape"
+  ],
+  "type": "string"
+}
  2. Changed2 schema fields changed
    • addedInput schema / properties / project_id
      Added value: +{
+  "description": "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.",
+  "pattern": "^[0-9a-f-]{36}$",
+  "type": "string"
+}
    • addedInput schema / properties / same_project_as
      Added value: +{
+  "description": "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.",
+  "maxLength": 100,
+  "minLength": 10,
+  "type": "string"
+}
  3. Changed1 schema field changed
    • changedInput schema / properties / canvas_size / description
      Previous value: -"A canvas size from list_devices, as WIDTHxHEIGHT. Leave it out for the store default (1320x2868 for iPhone, 2048x2732 for iPad, 1080x1920 for Play)."New value: +"A canvas size from list_devices, as WIDTHxHEIGHT. Leave it out for the store default (1320x2868 for iPhone, 2048x2732 for iPad, 2007x2853 for iPhone Duo, 1080x1920 for Play)."
  4. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare the generic profile (not read-only, not idempotent, not destructive), but the description adds real lifecycle facts: upload and finish within 1 hour or the project lapses, a finished project waits 72 hours to be opened, nothing is public, no account is needed, and the user saves the set on open. This is exactly the kind of context annotations cannot carry.

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?

Front-loads the when-to-use condition before any mechanics, and nearly every sentence carries information (precondition, exclusion, payload shape, return value, timing, privacy). It is dense rather than bloated, though the long single paragraph could be split for scanability.

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 an 11-parameter, no-output-schema tool, the description covers what an agent needs: what the tool produces (project_handle and upload command), the mandatory follow-up (finish_project), and the time budget for each stage. Nothing essential to a correct invocation is missing.

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 11 parameters thoroughly, including enums, defaults, and fallback behavior. The description adds little parameter-level detail beyond restating '1 to 6 screenshots in store order, each with a screen name and a headline', so baseline 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?

States a specific verb and resource: it 'starts a screenshot set' of 1-6 screens, and names its return artifacts (project_handle plus one upload command). It is clearly distinguishable from siblings like finish_project, make_screenshot_set, and create_design.

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?

Gives an explicit precondition ('when you can run shell commands on the user's machine and have their app's screenshots as local files') and an explicit exclusion ('Not for a chat without a terminal, such as ChatGPT, where the upload command cannot run'). It also routes the agent forward: run the upload command once, then call finish_project with the handle.

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