Skip to main content
Glama
Sign In

appdesigns App Store screenshots

by click.appdesigns
OverviewDiscussionsAdmin

Make a screenshot set from attached screenshots

make_screenshot_set

Use this when the user has attached screenshots of their own app in this conversation and wants App Store or Google Play screenshots made from them: store listing images, framed screenshots or app mockups for the App Store or Play Store. Each screenshot is put in a real device frame on a background with the screen name and headline you write, at the store's exact size, and open_url opens the set as an editable project in the appdesigns editor. Takes 1 to 6 screenshots (PNG, JPEG, WebP or GIF, at most 20 MB each, all the same way up; landscape ones make a landscape App Store set) in store order, with one screens entry per screenshot in the same order. Each must be a raw capture of the app as the device shows it. Do not use it for images that already have a device frame, a background or marketing text (the user needs to attach the raw screenshots instead), to invent app screens that do not exist, or when nothing is attached (the user needs to attach screenshots first). The screenshots are stored privately so open_url can load them; it works for 72 hours or until the user saves the set to their account. Nothing is public and no account is needed to make the set.

Input Schema

NameRequiredDescriptionDefault
storeNoWhich store the set is for: app_store for iPhone or iPad screenshots, play for Android.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 attached screenshot, in the same order as screenshots. The first sells the app.
canvas_sizeNoA canvas size from list_devices, as WIDTHxHEIGHT. Leave it out for the store default, or the store size the screenshots are; landscape screenshots make a landscape App Store set.
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.
screenshotsYesThe screenshots the user attached, in store order, one per screens entry.
project_nameYesThe app's name. It becomes the project name in the user's appdesigns library.
background_colorNo#RRGGBB, for example the app's brand colour as seen in the screenshots. Leave it out for a neutral light background.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 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."New value: +"A canvas size from list_devices, as WIDTHxHEIGHT. Leave it out for the store default, or the store size the screenshots are; landscape screenshots make a landscape App Store set."
    • 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. Added

TDQS

A4.6/5.0
Behavior4/5

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

Annotations only tell the agent this is a non-read-only, non-destructive, non-idempotent write. The description adds real lifecycle context the annotations cannot: private storage, a 72-hour retention window or until saved, no account required, and that open_url exposes an editable project. It stops short of saying what happens on repeat invocations or whether existing sets are overwritten, so not a perfect 5.

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?

It is long but front-loaded with the core use case, and the dense constraint clause is information-rich rather than padded. There is mild redundancy in the closing privacy statements ('stored privately... Nothing is public and no account is needed'), which keeps it from a 5.

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 9-parameter mutation tool with no output schema, the description covers inputs, ordering rules, storage/lifecycle behavior, the open_url follow-up, and the privacy model. An agent has everything needed to invoke it correctly and set user expectations.

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 baseline is 3, but the description adds constraints absent from the schema: 1–6 screenshots, accepted formats (PNG/JPEG/WebP/GIF), a 20 MB per-file cap, uniform orientation, and strict store-order correspondence between screenshots and screens entries. These materially reduce invocation errors.

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 states a specific verb and artifact ('make App Store or Google Play screenshots... store listing images, framed screenshots or app mockups') and scopes it to screenshots the user attached in this conversation. It is clearly distinguishable from siblings like replace_screenshots or create_project.

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 gives explicit when-to-use (user attached their own raw app screenshots and wants store images) and when-not-to-use (already-framed images, inventing screens, nothing attached), and tells the agent what to do instead in each excluded case. This is textbook routing guidance.

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