Skip to main content
Glama
hermoso-ai

Hermoso

Official
by hermoso-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Fetch App Store screens

fetch_app_screens
Idempotent

Pulls real App Store or Google Play screenshots into a brand's workspace so app-ui-tour ads can use them. Provide a store link, package ID, or app name for a confident match.

Instructions

Pull an APP brand's REAL store screenshots (Google Play or App Store) into the workspace brand, so a screen-hungry native format can use them. Use when the brand has 0–1 app screens on file and you want make_template_ad(template:'app-ui-tour'), or the user asks to 'pull my app's screenshots'. A store link or package id goes in storeUrl and is read exactly; else pass appName (defaults to the saved brand's name). FREE — a keyless store lookup. It needs a CONFIDENT match: an ambiguous or unknown app returns 0 screens and saves nothing, which you should relay plainly rather than retrying with guesses. On success the screens are saved to the brand (durable URLs) and are immediately usable.

Input Schema

NameRequiredDescriptionDefault
appNameNothe app's name to look up on the App Store — defaults to the saved brand's name
brandIdNoa profile id/name from list_brands to save the screens onto; omit to use the active profile
storeUrlNoa Google Play / App Store link or package id

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.454
    • addedInput schema / properties / storeUrl
      Added value: +{
+  "description": "a Google Play / App Store link or package id",
+  "type": "string"
+}
  2. Changed1 schema field changedv0.1.374
    • changedInput schema / properties / brandId / description
      Previous value: -"a brand id/name from list_brands to save the screens onto; omit to use the active brand"New value: +"a profile id/name from list_brands to save the screens onto; omit to use the active profile"
  3. Addedv0.1.161

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true, openWorldHint=true, and the description adds real context on top: it is free and keyless, requires a confident match, returns 0 screens and saves nothing on failure, and on success writes durable URLs to the brand. Minor gap: it doesn't say where in the brand the screens land or how many are typically pulled, but the risk/outcome picture is well covered.

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-loads what the tool does, then purpose, then inputs, then failure behavior - a sensible order. It is denser than it needs to be (parenthetical template syntax and repeated emphasis in caps), but nearly every clause carries actionable information.

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 still explains the return contract (screens saved to the brand as durable, immediately usable URLs) and the failure contract (0 screens, nothing saved). For a 3-param, all-optional tool with full schema coverage and rich annotations, nothing an agent needs to call 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 coverage is 100%, so the baseline is 3; the description adds a precedence rule the schema does not encode - storeUrl is 'read exactly' and takes priority, with appName as the fallback that defaults to the saved brand's name. That precedence and the strictness of storeUrl matching are genuinely useful selection guidance.

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 ('Pull an APP brand's REAL store screenshots ... into the workspace brand') and scopes it to Google Play / App Store. It also names the downstream consumer (make_template_ad with template 'app-ui-tour'), so an agent can place it among the many generate/render siblings without ambiguity.

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?

Gives explicit triggering conditions: brand has 0-1 app screens on file, or the user asks to pull screenshots, plus the specific follow-on call. It also states the negative path - ambiguous/unknown matches return 0 screens and should be relayed, not retried with guesses - which is a when-not-to-use rule most descriptions omit.

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

Deploy Server

Other Tools