Turn raw app screenshots into polished App Store and Google Play marketing screenshots from Cursor, Claude, or any other MCP client.
This is a small stdio MCP server that talks to the hosted StoreShots API. Rendering happens on the server, so you don't need Chrome, Puppeteer, or a design tool on your machine. Give your agent a few screenshots and some headlines, and it saves store-ready PNGs (or a ZIP) into your project.
1–5 screenshots per set, from local files or URLs
5 curated styles: glow, midnight, sunset, mint, trailing, plus custom colours
Device frames: iphone, iphone-duo, android, ipad
Every required store size in one call: ios-6.9 (1320×2868), ios-6.5 (1242×2688), android-phone (1080×1920), ipad-13 (2064×2752)
Headlines and captions for each slide
Downloads a ZIP and/or PNGs straight into your project
Sign up with your email at https://storeshots.qaimos.co.uk/account.html. The key (ss_...) is only shown once, so copy it somewhere safe.
Cursor: add this to ~/.cursor/mcp.json (or to .cursor/mcp.json in a project). You can also use the "Install in Cursor" button above.
{
"mcpServers": {
"storeshots": {
"command": "npx",
"args": ["-y", "storeshots-api-mcp"],
"env": { "STORESHOTS_API_KEY": "ss_your_key_here" }
}
}
}Claude Desktop: open Settings → Developer → Edit Config, then add the same block to claude_desktop_config.json:
{
"mcpServers": {
"storeshots": {
"command": "npx",
"args": ["-y", "storeshots-api-mcp"],
"env": { "STORESHOTS_API_KEY": "ss_your_key_here" }
}
}
}Claude Code:
claude mcp add storeshots --env STORESHOTS_API_KEY=ss_your_key_here -- npx -y storeshots-api-mcpVS Code, Windsurf, and other clients: run npx -y storeshots-api-mcp over stdio with STORESHOTS_API_KEY set in the environment.
Requires Node.js 18.17 or newer.
Make App Store screenshots from ./shots/home.png and ./shots/stats.png in the midnight style with the headlines "Build habits that stick" and "See your progress", and save them to ./store-assets.
Related MCP server: Shots
Tool | What it does |
| Lists the available styles with their colours and layouts |
| Lists the device frames and store output sizes |
| Renders one set from |
| Downloads a job's ZIP and/or PNGs to |
| Shows your paid credits, the free sets left this month, and the available credit packs |
| Returns a Stripe Payment Link for a pack, which you open in the browser. The tool itself never charges you |
Variable | Required | Default |
| yes | none. Get a free key at account.html |
| no |
|
| no |
|
| no |
|
Free: 3 sets per month, with a small "Made with StoreShots" watermark
Starter: 10 sets for $3, no watermark
Pro: 20 sets for $5, no watermark
Each set is one generate_screenshots call and includes every size you ask for. You can buy them with buy_credits or on storeshots.qaimos.co.uk.
Screenshots are uploaded over HTTPS to the StoreShots API, rendered there, and deleted after 24 hours. Your API key is sent as an X-API-Key header.
npm install
npm run inspect # opens the MCP Inspector against src/index.jsnpm test runs an end-to-end test against a local copy of the StoreShots PHP API, which isn't part of this repo.
Website: https://storeshots.qaimos.co.uk/
MCP Registry: uk.co.qaimos.storeshots/storeshots
MIT
Return the Stripe Payment Link for a credit pack, personalised for this API key (client_reference_id + prefilled email). Nothing is charged by this tool — give the link to the user to pay in their browser; credits are added automatically after payment.
| Name | Required | Description | Default |
|---|---|---|---|
| pack | Yes | Pack id from get_balance (starter = 10 sets for $3, pro = 20 sets for $5). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and openWorldHint=true, which alone would leave ambiguity about side effects. The description resolves this by stating the tool charges nothing itself and that fulfillment happens after payment in the browser. It doesn't cover link expiration or idempotency, but the key behavioral question is answered.
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, front-loaded with what is returned, followed by the operational caveat and post-payment flow. Zero filler.
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 must convey the return value, and it does ('the Stripe Payment Link... personalised for this API key'). Combined with the schema's pointer to get_balance for valid pack ids and the explanation of what happens after payment, an agent has everything needed to call and use this tool.
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 single 'pack' parameter is fully documented with concrete pack ids and prices. The description adds nothing about the parameter itself (its personalization detail concerns the returned link), so this is the baseline 3.
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 states a specific verb and resource ('Return the Stripe Payment Link for a credit pack') and adds the personalization scope (client_reference_id + prefilled email). No sibling tool produces payment links, so it is trivially distinguishable from list_styles, get_balance, etc.
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?
It gives clear operating context: nothing is charged by this tool, the link is meant to be handed to the user to pay in their browser, and credits land automatically afterward. There is no competing alternative to route against, so explicit exclusions are unnecessary; only error/retry guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn 1–5 raw app screenshots (local file paths or http(s) URLs) into framed App Store / Google Play marketing screenshots with headlines. One call = one set (all requested sizes) = 1 credit; free keys get 3 watermarked sets per month. Returns a jobId; set download_to (or call get_output) to save the PNGs/ZIP locally.
| Name | Required | Description | Default |
|---|---|---|---|
| style | No | Style id (default glow). See list_styles. | |
| theme | No | Optional colour overrides. | |
| device | No | Device frame. Omit to use each target's default device. | |
| appName | No | Used for file names. | |
| targets | No | Output sizes (default ios-6.9, ios-6.5, android-phone). | |
| captions | No | Caption per slide, same order as screenshots. | |
| headlines | No | Headline per slide, same order as screenshots. | |
| download_to | No | If set, download the results into this local directory right away. | |
| screenshots | Yes | 1–5 local image paths (absolute, ~ or relative to cwd), file:// or http(s) URLs. PNG/JPEG/WebP, ≤10 MB each. One slide per screenshot. | |
| download_format | No | What to download when download_to is set (default zip). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the bare annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false): it discloses the cost model (1 credit per set), a free-tier quota with watermarking, and the async jobId return with two retrieval paths. These are exactly the facts an agent needs before committing to a billable, non-atomic operation.
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?
Purpose is front-loaded and every clause carries information (input contract, pricing/quota, return and download path) with no filler. It is dense to the point of being packed into three long sentences, which slightly hurts scannability.
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 10-parameter, nested-object, no-output-schema tool, the description covers the essentials an agent cannot get elsewhere: credit cost, free-tier watermark limit, async jobId, and how to persist results. Combined with 100% schema coverage, nothing critical is missing for correct invocation.
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 every parameter (style, theme, targets, captions, headlines, download_to, download_format) is already documented inline, including enum meanings and ordering ties to screenshots. The description only restates the screenshots and download_to semantics, adding no new syntax or constraint 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?
Opens with a concrete verb+resource+transform: raw app screenshots into framed App Store / Google Play marketing screenshots with headlines, plus the input contract (1–5 local paths or http(s) URLs). An agent can distinguish this from list_styles/list_devices/get_output without opening any schema.
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?
Gives clear operational context: one call produces one full set, set download_to to save immediately, otherwise call get_output, and free keys are capped at 3 watermarked sets per month. It does not explicitly state when NOT to use it (e.g. for non-store assets) or route to buy_credits/get_balance when credits run out, so it stops short of full when/when-not/alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show remaining paid credits, free generations left this month, and available credit packs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered structurally. The description adds what the response contains, which is genuinely useful, but says nothing about auth requirements, caching/staleness of balance data, or whether it hits an external service despite openWorldHint.
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?
A single front-loaded sentence that enumerates the three return fields with zero filler. Every clause 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?
With no parameters and no output schema, the description's enumeration of returned values is exactly the information an agent needs and would otherwise lack. Nothing essential is missing for a trivial no-arg read tool.
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?
The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter-related gaps exist.
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 ('Show') and enumerates the three resources returned: paid credits, free generations this month, and credit packs. The read-only retrieval purpose is obvious against the sibling buy_credits, though the description never names that sibling to draw the contrast explicitly.
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?
Usage is only implied: an agent can infer this is the pre-check before buy_credits, but the description never says when to call it or when not to. No prerequisites or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download a job's ZIP and/or individual PNGs to a local directory (default ~/StoreShots/). Jobs expire after 24h.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Default zip. | |
| job_id | Yes | ||
| output_dir | No | Local directory to save into. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare this is not read-only (it writes files to disk) and not destructive, which the description is consistent with. The description adds real behavioral context beyond the annotations: the default output location ~/StoreShots/<jobId> and the 24-hour job expiry, both of which affect invocation.
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?
A single compact sentence front-loads the action, the artifacts, and the destination, with the expiry caveat appended. No wasted words.
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 download tool with no output schema, the description covers what is retrieved, the format options, and where files land. It could mention whether returned paths are reported or how partial failures are handled, but nothing essential to correct invocation 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?
With schema coverage at 67%, the description usefully restates the format choices (ZIP, PNGs, or both) and clarifies the default local directory, supplementing the schema's terse 'Default zip.' and 'Local directory to save into.' notes.
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 (Download) and resource (a job's ZIP and/or individual PNGs), plus the destination. It implicitly distinguishes itself from generate_screenshots by being the retrieval step, though it does not name any sibling explicitly.
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 24h expiry note gives a useful timing constraint for when this must be called, but there is no explicit when-to-use guidance or routing against alternatives such as generate_screenshots or list_styles.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List device frames (iphone, iphone-duo, android, ipad) and store output targets (ios-6.9 1320x2868, ios-6.5 1242x2688, android-phone, ipad-13).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds useful context by enumerating the exact device frames and output targets it surfaces, but says nothing about ordering, pagination, or format beyond those values.
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?
A single front-loaded sentence with zero filler. Every token—verb, resources, and concrete enumerated values—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 no-parameter, no-output-schema list tool whose annotations carry the safety profile, the description is largely complete; the enumerated values effectively preview the return content. It could be stronger by noting that returned values feed generate_screenshots, but nothing essential 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?
The tool takes zero parameters, so the baseline is 4. There is no parameter behavior for the description to clarify, and the schema/annotations already cover the empty input contract.
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 ('List') and precise resources ('device frames' and 'store output targets'), then enumerates concrete values (iphone, iphone-duo, android, ipad; ios-6.9 1320x2868, etc.). This makes it immediately distinguishable from list_styles and the other siblings without opening any schema.
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?
Usage is implied rather than stated: the enumeration of valid device frames and output targets signals this is a discovery tool to consult before calling generate_screenshots. However, there is no explicit when-to-use instruction, no named alternative, and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the curated screenshot styles (ids for generate_screenshots.style) with colours and layouts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful context about what is returned (colours and layouts), which is more than the annotations give, but there is no disclosure of ordering, caching, or rate behavior.
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?
A single sentence with no filler; the resource is front-loaded and the linkage to the consuming tool is packed into a parenthetical rather than a separate sentence.
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 hinting at return values, and 'with colours and layouts' does so adequately for a simple stateless listing tool. Nothing critical is missing for correct invocation.
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?
Zero parameters, so per the baseline this is a 4. The description correctly signals there is nothing to pass and instead points at where the output is used, adding a small amount of value beyond the empty schema.
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 (List) and resource (curated screenshot styles), and the parenthetical '(ids for generate_screenshots.style)' ties it directly to the sibling that consumes the values, distinguishing it from other list_* tools. Not quite a 5 only because it doesn't contrast against list_devices explicitly, but the resource itself is unambiguous.
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 link to generate_screenshots.style implies this should be called before generating screenshots to pick a style, but it never states when to use it, prerequisites, or that no parameters are needed. Usage is inferred rather than spelled out.
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.
v0.1.1buy_creditsgenerate_screenshotsget_balanceget_outputlist_deviceslist_stylesScored across 6 tools
Each tool has a clearly distinct purpose: two reference listers (styles vs devices), one generation action, one output retrieval, and two billing operations. No overlapping functionality; an agent can easily select the right tool.
All tool names follow a consistent snake_case verb_noun pattern (list_*, generate_*, get_*, buy_*). No deviations or mixed conventions.
Six tools cover the full workflow without redundancy: two lookups, one core action, one retrieval, and two billing helpers. Well-scoped for the service.
The surface covers style/device discovery, generation, output download, and credit management. Minor gap: no explicit job status or history tool, though get_output implies retrieval; agents can work around this.
Design and export App Store / Play Store screenshots, localized across all 48 App Store locales.
Generate exact-size App Store and Google Play screenshots, feature graphics, and listing copy.
App Store and Google Play screenshots MCP: your agent captures the app, you edit and export. Free.
Generate designed, localized App Store screenshot sets from your raw app captures.
