Skip to main content
Glama
mtbun

storeshots-mcp

by mtbun

generate_set

Batch-renders an ordered screenshot set for one preset and language. Item N becomes {lang}_{NN}.png. Returns per-item results plus any warnings.

Instructions

Batch-renders an ordered screenshot set for one preset and language. Item N becomes {lang}_{NN}.png. Returns per-item results plus any warnings.

Input Schema

NameRequiredDescriptionDefault
langNoBCP-47 language code for locale-aware uppercasing, e.g. "en", "tr", "de"en
frameNoCustom device frame. Supply your own frame PNG and the pixel rectangle where the screenshot goes; overrides the built-in frame. Omit to use the built-in frame.
itemsYesOrdered list of screenshots to render
presetYesPlatform preset id
variantNoComposition variant (portrait presets only): text-top = headline above a device that bleeds off the bottom; text-bottom = whole device visible with the headline underneath; tilted = text-top with the device rotated. Vary it across a set so the screenshots do not all look identical.text-top
panoramaNoTurn the set into one continuous background: a horizontal gradient from `background` to `panorama.to` flows across all panels, so they line up as a single image in the store. Omit for solid per-panel backgrounds.
outputDirYesDirectory for the set; files are named {lang}_{nn}.png in item order
backgroundYesBrand background color as 6-digit hex, e.g. "#E31837"
noGradientNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.5.0
    • addedInput schema / properties / variant / $ref
      Added value: +"#/properties/items/items/properties/variant"
    • removedInput schema / properties / variant / enum
      Removed value: -[
      -  "text-top",
      -  "text-bottom",
      -  "tilted"
      -]
    • removedInput schema / properties / variant / type
      Removed value: -"string"
  2. Changed4 schema fields changedv0.4.0
    • addedInput schema / properties / frame
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "Custom device frame. Supply your own frame PNG and the pixel rectangle where the screenshot goes; overrides the built-in frame. Omit to use the built-in frame.",
      +  "properties": {
      +    "image": {
      +      "description": "Path to a transparent PNG device frame",
      +      "type": "string"
      +    },
      +    "screenHeight": {
      +      "description": "Screen rectangle height in the frame image, px",
      +      "exclusiveMinimum": 0,
      +      "type": "integer"
      +    },
      +    "screenWidth": {
      +      "description": "Screen rectangle width in the frame image, px",
      +      "exclusiveMinimum": 0,
      +      "type": "integer"
      +    },
      +    "screenX": {
      +      "description": "Left of the screen rectangle in the frame image, px",
      +      "type": "integer"
      +    },
      +    "screenY": {
      +      "description": "Top of the screen rectangle in the frame image, px",
      +      "type": "integer"
      +    }
      +  },
      +  "required": [
      +    "image",
      +    "screenX",
      +    "screenY",
      +    "screenWidth",
      +    "screenHeight"
      +  ],
      +  "type": "object"
      +}
    • addedInput schema / properties / items / items / properties / variant
      Added value: +{
      +  "description": "Per-item composition variant; falls back to the set-level variant",
      +  "enum": [
      +    "text-top",
      +    "text-bottom",
      +    "tilted"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / panorama
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "Turn the set into one continuous background: a horizontal gradient from `background` to `panorama.to` flows across all panels, so they line up as a single image in the store. Omit for solid per-panel backgrounds.",
      +  "properties": {
      +    "to": {
      +      "description": "End color of the panoramic gradient (6-digit hex)",
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "to"
      +  ],
      +  "type": "object"
      +}
    • addedInput schema / properties / variant
      Added value: +{
      +  "default": "text-top",
      +  "description": "Composition variant (portrait presets only): text-top = headline above a device that bleeds off the bottom; text-bottom = whole device visible with the headline underneath; tilted = text-top with the device rotated. Vary it across a set so the screenshots do not all look identical.",
      +  "enum": [
      +    "text-top",
      +    "text-bottom",
      +    "tilted"
      +  ],
      +  "type": "string"
      +}
  3. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description must carry the full behavioral burden. It does disclose the output naming convention ({lang}_{NN}.png), item ordering, and that per-item results and warnings are returned, but it never states that files are written to outputDir, whether existing files are overwritten, or how partial failures are handled.

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

Conciseness5/5

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

Three short sentences, front-loaded with the core purpose and no filler. The naming rule and return summary each earn their place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter tool with nested objects and no output schema, the description is thin: it touches returns and naming but says nothing about frame/panorama/variant interactions or failure behavior. The rich schema compensates for most parameter detail, but the behavioral surface is under-covered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 89%, so the schema already documents nearly every parameter, including frame, variant, panorama, and lang. The description adds only the filename mapping tied to lang and item order, which is marginal value over the structured fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource with scope qualifiers ('batch-renders an ordered screenshot set for one preset and language'), which implicitly separates it from the single-shot compose_screenshot sibling. It never names a sibling explicitly, so an agent must infer the batch-vs-single boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The word 'batch' and 'ordered set' imply this is the multi-item entry point versus compose_screenshot, but the description gives no explicit when-to-use, when-not-to-use, or alternative-routing guidance. Usage is only inferable from the scope wording.

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