Loading ToolBench
AI-powered App Store & Play Store asset generator — MCP server for Claude Code. Generates store screenshots, mockups, and ASO metadata for iOS and Android apps.
Server has 9 tools with schemas and descriptions present, but quality is inconsistent. Tool names lack clear verb-noun structure (e.g., 'generate_all', 'navigate_and_interact' violates single-responsibility naming). Descriptions are verbose (200-400+ chars) and lack LLM-optimized brevity. Parameter descriptions exist but many lack type clarity and constraint documentation. Output schemas are not documented. Error handling guidance is absent. No tool annotations (readOnlyHint/destructiveHint). STDIO transport caps protocol readiness at 50.
Build the project for simulator/emulator using the local toolchain (flutter build, xcodebuild, gradle). Returns the artifact path.
Scan a project directory to detect platform (Flutter/Swift/Kotlin), framework, screens, navigation routes, and build configuration. Returns a ranked list of screens with store-worthiness scores.
Export generated store assets to Fastlane directory structure for iOS and Android. Organizes screenshots, metadata, and preview images.
END-TO-END: Run the entire store asset pipeline in one call. Auto-detects the host's MCP sampling support and runs in one of two modes: ATOMIC mode (Claude Desktop, Cursor, …): one call does everything — detect, build, screenshot, design unique mockup HTML via sampling, render at every store size, write ASO metadata copy, export Fastlane directory. BOOTSTRAP mode (Claude Code CLI — sampling not supported): the tool runs all DETERMINISTIC stages (detect, build, screenshot, analyze) and returns a 'work order' — a structured packet with design briefs and instructions. The agent then uses the individual tools (generate_mockup render, export_assets) guided by the included `instructions_for_agent` field to finish the job. Use this as the DEFAULT entry point. Other tools are for fine-grained control.
Generate App Store and Play Store metadata (title, subtitle, description, keywords) using LLM sampling. Supports multiple locales and tones.
Tool 'generate_all' violates single-responsibility principle. Description conflates two modes (atomic/bootstrap) with conditional logic, making it ambiguous when to call it. Should split into separate tools or clarify mode selection upfront.
Tool 'navigate_and_interact' combines multiple unrelated actions (tap, type, scroll, swipe, back, wait, deep_link) into one tool. Each action has different parameter requirements and semantics. Should split into tap_element, type_text, scroll_screen, swipe_screen, go_back, wait_for_animation, open_deep_link.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields. Every tool must document return type structure (e.g., detect_project returns {screens: [{name, score, route}], platform, framework}).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 50 | 2026-07-28+ | v2 |
AI-driven mockup generation with 3 modes: - "analyze": Extract dominant colors, dimensions, and design brief from a screenshot. Returns context for you to write a custom HTML mockup tailored to this specific app. - "render": Take your custom HTML and render it to a store-ready PNG via Puppeteer. Use {SCREENSHOT_BASE64} as placeholder for the screenshot, {WIDTH}/{HEIGHT} for dimensions. - "batch_render": Render the same HTML at all required store sizes (6.7", 6.1", iPad, etc). WORKFLOW: Call analyze first, then design a unique HTML mockup for this app, then call render.
Interact with the running app in the simulator: tap elements, type text, scroll, swipe, go back, or open deep links. Returns a screenshot and the UI accessibility tree after the action.
Control iOS Simulator or Android Emulator: list available devices, boot, shutdown, install app, launch app, or reset state.
Capture a high-resolution screenshot from the simulator with optional status bar masking (9:41 time, full battery, full signal).
Descriptions exceed 200 chars and lack LLM-optimized brevity. 'generate_all' description is 400+ chars with nested conditional logic. Descriptions should be 50-150 chars stating WHAT, WHEN, and RETURN in plain language.
No error handling guidance. Tools like build_project and simulator_control can fail (build errors, device not found) but descriptions do not explain recovery steps or error categories (retryable vs user-fixable). Add error guidance to descriptions.