Skip to main content
Glama

Agent C — App Store Screenshots

by io.theagentc
OverviewDiscussionsAdmin

Design a screenshot set

design_set

Claude art-directs a full App Store screenshot set from the uploaded screenshots: opening shot, headline per slide, close-ups, palette. Returns watermarked preview images, the slide list and a link to open it in the Agent C studio. Takes ~40-60 seconds.

Input Schema

NameRequiredDescriptionDefault
focusNoOptional: what to emphasize (feature, audience, angle).
app_idYesapp_id from list_apps / add_app
deviceNoScreenshot size: iPhone 6.9" (1320x2868), 6.5" (1284x2778), iPad 13" (2064x2752), or the optional iPhone Duo inner (2007x2853) / outer (1398x2034) displays. iPad and Duo need the app's real iPad / Duo simulator screenshots uploaded first (replace=false); iPhone-only apps should skip iPad. Duo is export-only: App Store Connect's API doesn't accept Duo uploads yet, so send_to_app_store refuses Duo sets.iphone_69
openerNoOpening slide: hand holding the phone, big app icon, lifestyle photo, or a plain phone. auto lets Claude pick.auto
includeNoWhat to make: the screenshot set, screenshots + the App Store product page header (iOS 27), or only the headerscreenshots

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / device / description
      Added value: +"Screenshot size: iPhone 6.9\" (1320x2868), 6.5\" (1284x2778), iPad 13\" (2064x2752), or the optional iPhone Duo inner (2007x2853) / outer (1398x2034) displays. iPad and Duo need the app's real iPad / Duo simulator screenshots uploaded first (replace=false); iPhone-only apps should skip iPad. Duo is export-only: App Store Connect's API doesn't accept Duo uploads yet, so send_to_app_store refuses Duo sets."
    • changedInput schema / properties / device / enum
      Previous value: -[
-  "iphone_69",
-  "iphone_65",
-  "ipad_13"
-]New value: +[
+  "iphone_69",
+  "iphone_65",
+  "ipad_13",
+  "iphone_duo_inner",
+  "iphone_duo_outer"
+]
  2. Changed1 schema field changed
    • addedInput schema / properties / include
      Added value: +{
+  "default": "screenshots",
+  "description": "What to make: the screenshot set, screenshots + the App Store product page header (iOS 27), or only the header",
+  "enum": [
+    "screenshots",
+    "both",
+    "header"
+  ],
+  "type": "string"
+}
  3. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare non-read-only, open-world, non-destructive. The description adds real value beyond them: a ~40-60 second runtime estimate and the shape of the output (watermarked previews, slide list, studio link). It does not say whether a new set is created or an existing one overwritten, which is the main remaining ambiguity.

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?

One dense paragraph, front-loaded with the action and what is produced, with runtime appended last. Every sentence carries information; nothing is padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so describing the return shape (previews, slide list, studio link) is necessary and done. Missing is the lifecycle context an agent needs: that the result is a set later editable via edit_set or exported via export_set, and any cost/credit implications of a 40-60 second generation.

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 coverage is 100% and three enums are fully documented in the schema (device sizes, opener styles, include modes). The description contributes nothing about focus, app_id, or device behavior, so baseline 3 is right.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb and artifact: art-directs a full App Store screenshot set (opening shot, headlines, close-ups, palette). This clearly distinguishes it from edit_set/export_set/get_set. It stops short of explicitly naming the sibling it differs from, so not a 5.

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

Usage Guidelines3/5

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

'from the uploaded screenshots' implies the upload prerequisite, and the app_id param points at list_apps/add_app, but the description never says when to call this versus edit_set (revise an existing set) or get_set. Usage is inferable rather than stated.

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

All Agent C — 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