Skip to main content
Glama
Sign In

appdesigns App Store screenshots

by click.appdesigns
OverviewDiscussionsAdmin

Make a set in another language

translate_asset

Use this when the user wants a screenshot set or listing asset in another language (a localization for the App Store or Google Play): one they saved (asset_id), or one you made in this conversation (handle). You translate every text layer yourself (get_asset lists them, with their ids); this makes a copy in that language, its images copied and the original untouched, wrapping a long translation and moving the captions under it down as the editor's own Translate set does. A saved set's copy is saved into the same project (asset_id back); a copy of yours is a new set with its own handle and link, which joins the original's project when the user saves them. Returns a preview of every screen (check the line breaks) and warnings; fix any line with edit_asset. One call per language. With asset_id (something the user saved) it needs the user signed in to appdesigns (in Claude Code type /mcp, pick appdesigns and choose Authenticate (or run claude mcp login appdesigns in a separate terminal), in Codex run codex mcp login appdesigns; other agents open the sign-in page themselves); with handle (a set or design you made in this conversation, not saved yet) it needs no sign-in.

Input Schema

NameRequiredDescriptionDefault
textsYesEvery text layer that has words, translated. Keep names and brands as written; match the source's tone and length where the language allows.
handleNoInstead of asset_id: the project_handle create_project returned or the design_handle create_design returned, for something you made in this conversation that the user has not saved yet. Needs no sign-in.
asset_idNoThe asset_id list_projects returned.
languageYesApp Store Connect's code for the language, such as de-DE, fr-FR, ja, es-MX or pt-BR.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / handle
      Added value: +{
+  "description": "Instead of asset_id: the project_handle create_project returned or the design_handle create_design returned, for something you made in this conversation that the user has not saved yet. Needs no sign-in.",
+  "maxLength": 100,
+  "minLength": 10,
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "asset_id",
-  "language",
-  "texts"
-]New value: +[
+  "language",
+  "texts"
+]
  2. Added

TDQS

A4.6/5.0
Behavior4/5

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

Annotations declare non-read-only, non-idempotent, non-destructive, and the description is consistent, adding real value beyond them: the original is untouched, images are copied, a saved copy lands in the same project, a copy of an unsaved set gets its own handle/link and joins the project on save. It also details exact auth steps per agent (Claude Code /mcp, Codex login command). Return behavior (screen previews + warnings) is disclosed, though line-break-wrapping behavior is described only loosely.

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 trigger and the two modes, and every sentence carries real information (behavior, return, auth). It is dense with long parenthetical clauses, so it reads more as a wall of text than a scannable spec, but nothing is truly redundant given the tool's complexity.

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 compensates fully: it describes the return (a preview of every screen plus warnings) and the remedy (fix lines with edit_asset), covers both input modes, the per-language call limit, and per-agent authentication. Nothing an agent needs 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 description coverage is 100%, so the baseline is 3, but the description adds semantics beyond the schema: it explains where text-layer ids come from (get_asset lists them), that every word-bearing text layer must be translated, that asset_id comes from list_projects and handle from create_project/create_design, and the 'one call per language' constraint on language.

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+resource ('makes a copy in that language' of a 'screenshot set or listing asset') and immediately distinguishes the two modes (asset_id for saved sets vs handle for sets made in-conversation). It names sibling tools (get_asset, edit_asset) so the agent can place it in the workflow without opening schemas.

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 opens with an explicit trigger ('Use this when the user wants... in another language'), names the alternative inputs and when each applies (asset_id = saved, needs sign-in; handle = unsaved, no sign-in), and states 'One call per language.' Exclusions and prerequisites are explicit.

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