Loading ToolBench
MCP server for paid, deterministic social image rendering with exact typography. Pays per call in USDC over x402
Three tools with complete, well-structured schemas and clear descriptions. Tool names follow verb_noun convention (render_*, list_*). Descriptions are detailed and explain cost/behavior. All parameters have types and descriptions. However, output schemas are not formally documented, responses are inferred from code. Error handling is present but minimal. No tool annotations (readOnlyHint/destructiveHint). Missing idempotency guidance for expensive paid operations.
List available formats, bundles and prices. Free — makes no payment.
Render one spec into a whole set of platform formats in a single paid call, and return every PNG. Cheaper and fewer round trips than rendering each format separately.
Render a social image with exact typography and return the PNG. The text in the output is exactly the text supplied — unlike diffusion image models, which garble lettering. Deterministic: the same spec always produces the same pixels. Costs $0.03 in USDC per call.
Output schemas not formally documented. render_image and render_bundle return PNG + text, but no schema definition visible. LLMs cannot plan downstream operations or validate responses.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). render_image and render_bundle are expensive ($0.03 - $2.00 per call) and irreversible, but LLMs have no metadata signaling this. Should mark as destructive and non-idempotent.
Error handling lacks recovery guidance. Errors like 'Payment did not settle' or 'format must be one of...' are thrown but do not guide the LLM on next steps (retry, ask user, check config).
No dry-run or confirmation step for paid operations. Agents can accidentally invoke render_bundle (campaign-pack: $2.00) without user confirmation. Should support a preview or confirmation pattern.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
Parameter descriptions use example values (e.g., 'e.g. #d8232f' for accent color). LLMs may reuse these literally. Should use enum constraints or regex patterns instead.