Skip to main content
Glama

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

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

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

Annotations already establish read-only/idempotent/non-destructive, and the description adds substantial context on top: the full return shape (screens, backgrounds, bottom-first layers with id/position/style, animation loop, warnings, preview images), the fact that it returns the revision edit_asset needs, and detailed auth requirements per identifier including exact login commands.

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?

Dense but front-loaded: usage context comes first, then return shape, then auth. It is a single long run-on paragraph with heavy parentheticals, which hurts scanability, but almost every clause carries information an agent needs (revision linkage, auth commands, layer ordering).

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 carries the return-value burden and does so thoroughly (screens, layers, styles, loop, warnings, previews, revision). Combined with the auth guidance and identifier selection rules, 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 beyond the schema by tying each identifier to an auth consequence: asset_id requires signing in to appdesigns (with concrete login steps), while handle requires none. The previews parameter is not elaborated in the description, relying entirely on the schema.

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 ('read one asset') and immediately scopes it to two use cases: pre-edit inspection and answering 'what does it look like'. It distinguishes itself from siblings by naming edit_asset and by explaining the two lookup keys (asset_id vs handle) that separate it from list_projects-style tools.

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 call it ('before changing an asset with edit_asset, or when the user asks what one looks like') and gives the conditional selection rule between asset_id and handle, including which one requires sign-in. Nothing about when to use it is left to inference.

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