Read-only MCP endpoint for App Store and Google Play screenshot templates and current store screenshot size requirements. No API key, no account, no install step.
Scored across 3 tools
Each tool targets a distinct need: screenshot requirements/specs, browsing templates, and inspecting one template. The boundary between list_templates and get_template is clear because get_template explicitly says to use it after list_templates for a specific design.
All names use snake_case with a predictable verb_noun structure: get_screenshot_specs, get_template, list_templates. Minor inconsistency is that get_template/list_templates imply 'screenshot template' while get_screenshot_specs names its resource more explicitly.
Three tools is slightly lean but appropriate for a focused reference server covering screenshot specs and template discovery/inspection. Each tool has a clear role and no unnecessary duplication.
The surface covers the stated domain well: requirements lookup, template browsing, and detailed template inspection. Minor gaps could include category/style enumeration or direct editor integration, but the core reference workflow is complete.
Look up current App Store and Google Play screenshot requirements: exact pixel sizes, accepted formats, minimum and maximum screenshot counts, transparency rules, and official Apple or Google sources. Filter by store or device type.
| Name | Required | Description | Default |
|---|---|---|---|
| store | No | Store to look up. Omit to return both stores. | |
| device | No | Device or asset type to filter by. Omit to return every target. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful context that the requirements are current and sourced officially, but it does not discuss caching, rate limits, or how the data is maintained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tightly written sentences with no filler. The core purpose is front-loaded, and the filtering behavior follows immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining return values, and it does so by naming the key requirement categories. It could go further by describing the shape of the returned data, but an agent has enough to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both the 'store' and 'device' enums are already fully documented with their omit-behavior. The description's phrase 'Filter by store or device type' adds no meaning beyond the schema, making the baseline score appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb, 'Look up,' and names the exact resource: App Store and Google Play screenshot requirements. It enumerates the returned content (pixel sizes, formats, counts, transparency rules, sources), making its purpose clearly distinct from the template-oriented siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states that results can be filtered by store or device type, matching the two optional parameters. It does not name alternatives or exclusions, but this is a self-contained lookup tool with no similar sibling to disambiguate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one AppScreenshoot screenshot template in detail, including its connected screen sequence, headline and subtitle copy, preview images, canvas size, and editor link. Use this after list_templates to inspect or recommend a specific design.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Template slug from list_templates, for example violet-beauty. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds substantive context by enumerating what the response contains, which matters because there is no output schema; only error behavior for an invalid slug is left unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. The payload description comes first and the usage routing second, which is the right order for an agent scanning the definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, naming the returned fields is exactly the right compensation, and the single required parameter is fully documented elsewhere. Minor gap: no mention of what happens when a slug is unknown or not found.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the slug parameter's description already names its source (list_templates) and gives an example (violet-beauty). The description adds no syntax or format detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one AppScreenshoot screenshot template in detail') and enumerates the content returned: screen sequence, headline/subtitle copy, preview images, canvas size, and editor link. This clearly separates it from the sibling list_templates, which is a listing operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly prescribes the workflow: 'Use this after list_templates to inspect or recommend a specific design,' which tells the agent when to call it and in what order. It stops short of stating when-not to use it (e.g., what to do if only a summary is needed), so it falls just below top marks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse AppScreenshoot's published App Store and Google Play screenshot templates. Filter by category, visual style, free tier, or a keyword. Returns the template slug, name, colors, first preview image, and links to its detail page and editor.
| Name | Required | Description | Default |
|---|---|---|---|
| free | No | When true, only return templates available on the free tier. | |
| limit | No | Maximum templates to return. Defaults to 12, capped at 50. | |
| query | No | Keyword to match against each template's name, category, style, or description. | |
| style | No | Partial style match, for example Editorial, Airy, Violet, or Bold. | |
| category | No | Exact category, for example Beauty, Fitness, Finance, or Travel. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only and closed-world behavior. The description adds value beyond them by disclosing the return payload (slug, name, colors, first preview image, links to detail page and editor), which matters since there is no output schema. It omits ordering and whether results are paginated beyond limit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences with no waste; the core action leads, filtering follows, and the return shape closes. Each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with a single sibling detail-fetch, the description covers purpose, filtering, and return fields adequately given the fully documented schema. Minor gaps remain around result ordering and total counts, but 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so every parameter is already documented in the schema. The description restates the same filter dimensions (category, style, free, keyword) without adding syntax, matching behavior, or default details, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Browse) and resource (published App Store and Google Play screenshot templates), plus the fields returned. It does not explicitly name the sibling get_template or clarify list-vs-single, but the 'browse...templates' framing makes the distinction inferable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Filter by category, visual style, free tier, or a keyword' implies the browsing use case, but there is no statement of when to use this versus get_template or get_screenshot_specs, and no prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_screenshot_specsget_templatelist_templates
Add one secure layer between your agents and this server.