Loading ToolBench
MCP server for comparing image generation models. A collection is a grid: rows are prompts (plus optional input images and common settings), columns are models (plus model settings). The server fills every missing cell and skips cells whose content did not change.
Imaginator demonstrates solid tool definition quality with consistent naming patterns (verb_noun), comprehensive parameter schemas using Zod, and clear descriptions for most tools. All 26 tools have explicit descriptions and input schemas with typed parameters. However, output schemas are not documented in the visible code, parameter descriptions vary in depth, and error handling guidance is minimal. The server follows good composition patterns (single responsibility per tool, proper chaining via IDs) and includes tool annotations (destructiveHint, readOnlyHint). Main gaps: output schema documentation, richer error recovery guidance, and some parameter descriptions lack format/constraint details.
Delete an asset.
Get a single asset by id.
List uploaded and generated assets.
Upload an image or video asset (base64 or multipart/form-data).
Get a single cell with its version history and current status.
Pin a cell to a specific generation (hold its output while sampling more).
Ask for another sample in a cell (same request, new generation).
Output schemas not documented in tool definitions. LLMs cannot plan downstream calls or extract required fields without knowing what each tool returns.
Error handling lacks recovery guidance. Tools return errors but do not tell LLMs what to do next (retry, lookup alternative, ask user). E.g., 'collection not found' should suggest available collections.
Parameter descriptions lack format/constraint details. E.g., 'slug' parameter has no regex pattern or length constraint; 'timeout' has no min/max bounds; 'size' enum values are documented but not all params with enums are equally clear.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 67 | 2026-07-28+ | v2 |
Re-run a failed or unsupported cell.
Unpin a cell (resume using the latest generation).
Create a new collection with initial columns and rows.
Delete a collection and all its data.
Export a collection as JSON (with frozen assets, without live references).
Get a collection with all its cells, progress, and metadata.
Import a collection from a JSON export.
List collections with status and cell counts.
Update collection metadata (title, description, status, defaults).
Wait for a collection to reach a stable state (running → blocked or settled). Returns early on any change; loop on it.
Add one or more columns to a collection.
Delete one or more columns from a collection.
Update a column (model, settings, recipe, count).
Get a generation by id or address.
List available models with capabilities and their settings schema.
Add one or more rows to a collection.
Delete one or more rows from a collection.
Update a row (prompt, negative prompt, inputs, settings, sparse columns, paused, notes).
View images from cells or generations (returns inline images or links).
Destructive operations (delete_*) lack confirmation/dry-run support. Agents can delete collections, columns, rows, and assets without a safety gate. No confirmation_request pattern implemented.
Batch operations return aggregate success/failure. If add_rows fails on row 3 of 10, the LLM cannot determine which rows succeeded and which failed, forcing a full retry.