Skip to main content
Glama
mtbun

storeshots-mcp

by mtbun
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

build_project

Renders a whole store listing from a storeshots.json config: every screen x preset x language, plus an optional feature graphic and showcase strips. Re-renders only outputs whose inputs changed and removes outputs of deleted screens.

Instructions

Renders a whole store listing from a storeshots.json config: every screen x preset x language, plus an optional feature graphic and showcase strips. Re-renders only outputs whose inputs changed and removes outputs of deleted screens. Config shape: {"background":"#hex","presets":["ios-phone","android-phone"],"languages":["en","tr"],"outputDir":"output","screens":[{"screenshot":"shots/home.png","copy":{"en":["Track","your daily mood"],"tr":["Takip et","ruh halini"]},"variant":"tilted"}],"panorama":{"to":"#hex"},"featureGraphic":{"screen":1},"showcase":true}. Screenshot paths are relative to the config and may use {lang}, {preset}, {platform} (ios|android). Prefer this over generate_set when the user will iterate on a set. If the result includes a star field, follow its instructions: ask the user its yes/no question once, and star only on an explicit yes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
forceNoRe-render everything, ignoring the cache
langsNoOnly build these languages
configYesPath to the project config, usually storeshots.json
dryRunNoReport what would be rendered without writing
presetsNoOnly build these presets

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.5.0

TDQS

A4.6/5.0
Behavior4/5

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

No annotations provided, so description carries full burden. Discloses caching behavior ('re-renders only outputs whose inputs changed'), cleanup ('removes outputs of deleted screens'), and special star field handling. Omits permission or overwrite details, but covers key behaviors.

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?

Well-structured and front-loaded: first sentence defines the action. The config example is lengthy but necessary for correct invocation; no superfluous text.

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

Completeness4/5

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

Given no output schema, the description covers action, config format, caching, cleanup, and alternative routing. It hints at a return `star` field but does not detail the full output format; minor gap.

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

Parameters5/5

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

Schema coverage is 100%, so baseline 3. Description significantly enhances the `config` parameter by providing the full expected JSON structure and explaining placeholder syntax for screenshot paths, which is not in 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 specific verb 'renders' and resource 'whole store listing' with scope 'every screen x preset x language'. Explicitly distinguishes from sibling generate_set, aiding tool selection.

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 states preference over generate_set when user will iterate on a set, and provides instructions for handling the `star` field in results. The alternative condition is clear, though no explicit when-not conditions are given.

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