Loading ToolBench
MCP server that renders LDraw/LEGO models to images with real part geometry via headless Blender + ImportLDraw, and answers bill-of-materials, colour and part queries.
Six tools with complete schemas and descriptions. Naming is clear and verb-driven (render_*, check_*, bill_of_*, lookup_*, search_*). Descriptions are detailed (100 - 300 chars) and explain WHAT, WHEN, and constraints. All parameters have types and descriptions. Output is Image or structured data. Error handling surfaces refusals as ToolError with actionable messages. Main gaps: no tool annotations (readOnlyHint/destructiveHint), no pagination for search_parts (limit capped at 200 but no cursor/offset), and parameter descriptions could be more concise per LLM-optimization baseline (50 - 200 chars ideal; these run 100 - 300).
Bill of materials for an LDraw model: part x colour x quantity rows. Give `path` (a .ldr/.mpd file) or `ldr` (inline LDraw text), not both. MPD sub-models are expanded with their multiplicity, and colour 16 inherits the colour of the line that referenced the sub-model. Part descriptions and colour names come from the LDraw library when one is installed; without it the counts are the same and those fields are null. A colour code that LDConfig.ldr does not define is listed in `unknown_color_codes`, and a part the library lacks in `parts_not_in_library`.
Report whether the LDraw rendering stack is available and why not.
Look up LDraw colours in the library's LDConfig.ldr. `query` is a colour code (`4`, or a direct colour `0x2FF8800`) or part of a name (`dark blue`, `Trans_Red`). Returns code, name, RGB, edge colour, alpha and finish for each match; an unknown code returns no matches.
Render an LDraw model file (.ldr/.mpd/.dat) to a PNG image. Views are rendered at each comma-separated azimuth (degrees) and stitched side by side. Higher samples = cleaner but slower. Bounds: resolution 32..2048 px per view, samples 1..1024, 1..8 azimuths, and resolution^2 x samples x views at most 2**27.
Render inline LDraw content (the text of a .ldr file) to a PNG. Useful for quick experiments without writing a file first. Same bounds as render_ldraw_file.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All six tools are read-only but lack explicit annotation for LLM planning.
search_parts lacks pagination cursor/offset. Limit capped at 200 but no next_cursor or offset parameter to iterate large result sets.
Parameter descriptions exceed LLM-optimization baseline (50 - 200 chars). render_ldraw_file and render_ldraw_text descriptions run 200+ chars, risking token waste.
bill_of_materials parameter descriptions are verbose (200+ chars).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
Search the LDraw library's parts by description or file-name substring. Case-insensitive, runs of spaces collapsed (`brick 2 x 4` matches the header `Brick 2 x 4`). Returns at most `limit` parts (max 200) plus the total number of matches.
No explicit output schema documentation in tool docstrings. Image format is clear, but structured tools (bill_of_materials, lookup_color, search_parts) should document field names and types.