Loading ToolBench
MCP server for RendrKit — generate designed images from text
RendrKit MCP server has 8 tools with generally clear names and descriptions. Tool naming follows verb_noun conventions (generate_image, list_templates, etc.). Most descriptions are present and reasonably detailed (150-250 chars typical). However, several critical gaps emerge: (1) Input schemas use Zod validation internally but the actual JSON Schema passed to registerTool() is partially obscured in the provided code; (2) several parameters lack inline descriptions in the parameter definitions themselves, forcing LLMs to infer meaning; (3) no output schemas are documented; (4) error handling is present but generic; (5) the batch_render tool has truncated code in the sample. Tools show good domain-specific guidance (e.g., generate_image explains prompt mode vs direct mode), but lack depth in parameter constraints and response structures. Security baseline met (API key via env var), composition is sound (each tool has one responsibility), but documentation completeness is below A-grade standards.
Generate multiple images from the same template with different data. Perfect for e-commerce catalogs, certificates, social media series. Up to 20 items per batch.
Clone a template with custom default values. Creates a reusable preset (e.g., your brand's product card template). Use the returned ut_ID for future generations.
Generate a marketing image. Two modes: (1) Prompt mode — provide a text prompt and AI picks the template. (2) Direct mode (recommended) — provide templateId + slots for precise control. Use list_templates to see available templates.
Get details of a previously generated image
Check current usage statistics including images generated this month and plan limits
List all saved brand kits. Brand kits contain colors, fonts, and logos for consistent image generation.
No output schemas documented for any tool. LLMs cannot plan downstream operations without knowing response structure. E.g., generate_image returns what? {id, url, variants: [...], timestamp}? This forces agents to guess or make wasteful follow-up calls.
Parameter descriptions in schema definitions are sparse or missing constraints. E.g., 'variants' (number) lacks min/max; 'size' enum values are clear but no guidance on which size for which platform; 'background' enum lacks examples of visual difference.
Tool descriptions are inconsistent in length and detail. 'get_image' is 38 chars (too brief); 'list_brand_kits' is 116 chars (adequate). Brevity like get_image doesn't help LLMs disambiguate when to call it.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 59 | - | v1 |
List all available image templates with their slot definitions. Use this to discover which templates exist and what slots they accept for direct rendering with generate_image.
Upload an image to get a hosted URL that can be used as photo_url in templates. Provide either a public URL to re-upload or base64-encoded image data.
Mutual exclusivity and dependencies undocumented. E.g., generate_image has 'prompt' vs 'template_id' mode, but parameter descriptions don't state they are mutually exclusive or what happens if both are provided. upload_image accepts url XOR base64, but the constraint is implicit. Agents need explicit guidance.
No pagination support on list_* tools. list_templates, list_brand_kits, and implicitly list_user_templates (referenced in api-client.ts but not registered as a tool) have no limit, offset, or cursor parameters. If a user has 1000 brand kits, the response could exhaust context window.
Error handling is minimal. No tool has documented recovery guidance. E.g., if generate_image fails due to invalid template_id, the error should suggest list_templates first. RendrKitApiError is thrown but LLM receives generic HTTP status + body, no actionable guidance.
batch_render code is truncated in the sample. Cannot fully verify error handling (error handling for partial batch failures), output structure, or per-item success/failure reporting. This creates uncertainty in scoring.