Loading ToolBench
MCP server for ReDesign, a tool that runs UI/UX screenshots through AI models to generate reimagined HTML prototypes. Provides tools to manage runs, inputs, models, and API key health.
ReDesign MCP server demonstrates solid tool engineering with comprehensive parameter schemas and clear descriptions. All 11 tools have explicit JSON Schema input definitions with type declarations and parameter descriptions. However, output schemas are not documented in the source code provided, and some tools conflate multiple concerns. Tool naming follows action-verb conventions (run, get, list, cancel, retry, repeat), which is positive. Descriptions range from 50-180 characters and are actionable, though they occasionally reference implementation details (preflight_id, mock mode) rather than pure user intent. No security issues detected in parameter exposure. The server achieves B+ range for definition quality due to strong schema presence but undocumented outputs and minor naming ambiguities.
Composite recipe: queue a reimagine batch and optionally wait for it. wait:false (default) returns { runId, note } immediately, poll get_run yourself. wait:true polls internally (up to timeout_secs, default 120, capped at 300) and returns a structured digest: { runId, status, jobs: [{ input, model, prompt, variant, status, outputFile, caption, error }], captionSummary }. Set mock:true for a no-API-spend dry run.
Cancel an in-flight run by runId.
Get one run's manifest by runId: status, per-job results, and the output directory.
API key-pool health per provider (counts + cooldowns only, never the key values).
List discovered inputs (the screenshots / grouped screenshot sets found in ./input).
List recent runs (newest first) with their status and ok/error counts.
Output schemas not documented in source code. Tool descriptions explain what each tool returns at a high level (e.g., 'Returns preflightId, resolved job count, and estimated cost'), but no formal structured output schema is visible. LLMs cannot infer downstream field names for chaining tools.
snapshot and batch_reimagine tools combine multiple concerns. snapshot returns 'models, prompt presets, inputs, references, API key-pool health, and recent runs', six distinct data types in one call. batch_reimagine is both a composite orchestration and a wait-for-completion tool. Consider splitting these into focused single-responsibility tools.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 68 | 2026-07-28+ | v2 |
Validate and estimate a run without queueing it. Returns preflightId, resolved job count, and estimated cost; submit that token with run or batch_reimagine to avoid duplicate paid batches after a lost response.
Repeat a prior run from its durable original recipe. Returns the new run id without reconstructing selections from current UI state.
Re-run only the failed, skipped or cancelled jobs of a finished run, instead of paying for the whole fan-out again. Omit jobIds to retry all of them. Returns { runIds, jobCount }; each returned run id streams and completes like any other run.
Queue a reimagine job: send input screenshot(s) through models × prompts and collect reimagined HTML. Returns { runId } immediately, poll get_run for progress. Set mock:true for a no-API-spend dry run.
Full snapshot of the app: models, prompt presets, inputs, references, API key-pool health, and recent runs.
Parameter descriptions reference implementation details ('mock mode', 'prepaid run token', 'preflight_id token') that are relevant to the API surface but not user intent. Descriptions should state WHAT the parameter controls (e.g., 'Validate without spending money') rather than HOW to use implementation details.
No error recovery guidance in tool descriptions. If a run fails, retry_run offers a path forward, but tools don't explain when to use run vs. repeat_run vs. retry_run vs. batch_reimagine. An agent must infer the decision tree from names alone.
Pagination and result limits not explicitly declared. snapshot and list_runs return 'recent runs' but do not specify 'recent' (count, time window) or offer pagination. Large result sets risk context window exhaustion.