Skip to main content
Glama
Sign In

appdesigns App Store screenshots

by click.appdesigns
OverviewDiscussionsAdmin

Read one asset

get_asset
Read-onlyIdempotent

Use this before changing an asset with edit_asset, or when the user asks what one looks like: one the user saved (asset_id) or a set or design you made in this conversation (handle). Returns its screens, each with its background, its layers bottom first (text, pictures and the phone, each with an id, a position as a share of the canvas and its style) and its loop if it is animated, plus warnings about what may look off, and a preview image of each screen. Also returns the revision edit_asset needs. 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. Read-only.

Input Schema

NameRequiredDescriptionDefault
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.
previewsNoWhich screens to preview, from 1. Default: all of them.

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"
+}
    • removedInput schema / required
      Removed value: -[
-  "asset_id"
-]
  2. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare read-only/idempotent/non-destructive, but the description adds substantive behavioral context beyond them: the auth dance for asset_id versus none for handle, and the fact that the returned revision is the token edit_asset requires. That is genuinely useful operational detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with usage, which is good, but the body is one sprawling sentence with deeply nested parentheticals (auth instructions inside a clause about asset_id) that is dense and hard to parse. Content earns its place, but the packaging is not tight.

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?

There is no output schema, so the description must carry return-value semantics — and it does, detailing screens, layers, styles, loops, warnings, previews and the revision field. Combined with full auth guidance, an agent has everything needed to call it correctly.

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 meaning: it explains that asset_id is a user-saved object needing sign-in while handle is an in-conversation artifact needing none, clarifying why two identifiers exist. It doesn't add much on the previews parameter beyond the schema's 'from 1, default all.'

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+resource (read one asset) and enumerates exactly what comes back: screens with backgrounds, layers, styles, loops, warnings, preview images, and the revision. It also names the sibling it complements (edit_asset), so the agent can place it without opening the schema.

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 says when to use it ('before changing an asset with edit_asset, or when the user asks what one looks like') and gives the two mutually exclusive access paths (asset_id vs handle) with their differing sign-in requirements. There is little left to infer.

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