Skip to main content
Glama

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 PNG or JPEG screenshots (at most 6 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

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

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

Annotations cover the safety profile (not read-only, not destructive, not open-world), and the description goes well beyond them by disclosing storage privacy, the 72-hour lifetime until save-to-account, that nothing is public, and that no account is required. It does not explain failure modes (e.g., what happens on >6MB or mixed-orientation input) beyond constraints.

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-loaded with the triggering condition and the when-not-to-use rules before the mechanics. It is long, but nearly every clause carries a constraint; a couple of store-listing examples could be trimmed without loss.

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 9-parameter mutation tool with no output schema, the description covers inputs, constraints, privacy, and that open_url opens the result as an editable project. It stops short of describing the returned reference (URL id, expiry token) that the agent would pass to open_url, which is the main remaining gap.

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 baseline is 3, but the description adds cross-parameter semantics the schema cannot: screens entries must be in the same order as screenshots, one per screenshot, the first sells the app, and mixed orientation is disallowed (landscape input yields a landscape App Store set).

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 (make a screenshot set from attached screenshots) and names the concrete deliverables: App Store/Play listing images, framed screenshots, mockups. It is clearly distinguishable from siblings like create_design or replace_screenshots because it is scoped to raw user-attached captures.

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?

Explicitly gives both when-to-use (user attached their own app screenshots and wants store images) and when-not-to-use (already-framed images, inventing screens, nothing attached), with the corrective action for each exclusion. This is exactly the routing an agent needs against 17 siblings.

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