Loading ToolBench
An MCP server that lets LLMs design real LEGO models. Semantic tools, LDraw export, no GUI automation.
LegoMCP has 27 well-named tools with consistent verb_noun patterns (create_model, search_parts, add_part, etc.). All tools have descriptions (avg ~80 chars, within baseline 34 - 392). Input schemas are present and typed for all tools. However, descriptions are terse and lack LLM-optimization guidance (e.g., 'when to use', 'what it returns', dependencies). Parameter descriptions are minimal, many lack format/constraint details. Output schemas are not documented. Error handling is absent from tool definitions. No tool annotations (readOnlyHint, destructiveHint). Composition is strong: tools chain well (search_parts → add_part → render_model). Naming is clear and action-oriented. Overall: solid foundation, but descriptions and output documentation need expansion to reach A-grade.
Add a LEGO part instance to the model at a specified position and rotation
Analyze exposed connector ports on a subassembly
Build a floor structure
Build a closed rectilinear perimeter from a list of points
Build a rectangular room with walls
Build a wall structure from point A to point B with specified height and color
Merge 1x1-brick voxel constructions into bonded standard brickwork
Create a new LEGO model with the given name
Output schemas not documented. Tools like render_model, get_model_info, list_parts, get_build_sequence return data but LLMs cannot see what fields to expect. This forces agents to guess at response structure and breaks downstream tool chaining.
Descriptions lack LLM-optimization guidance. Most descriptions are 40 - 70 chars and state only WHAT the tool does, not WHEN to use it or what it returns. E.g., 'Move a part instance to a new position' omits coordinate system (LDU), whether it validates collisions, or what happens if the part doesn't exist.
Parameter descriptions are minimal or missing constraint details. E.g., rotation param in add_part lists valid values ('identity, rot90y, ...') in description but should use an enum constraint. Color param accepts 'integer' but lacks guidance on valid LDraw color ID ranges or how to discover them.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Export the model to LDraw .ldr format
Export the model to LDraw .mpd (multi-part) format
Get the orderable parts list for the current model
Get a support-respecting step-by-step build order for the model
Get information about the current model
Get detailed information about a specific part
Import a model from an LDraw .ldr or .mpd file
List all parts currently in the model
Move a part instance to a new position
Find parts that can sit on top of a specified part
Redo the last undone operation
Remove a part instance from the model
Render the current model to a PNG image
Restore the model to a previously saved checkpoint
Rotate a part instance to a new orientation
Save the current model state as a named checkpoint for later restoration
Search the LEGO parts catalog by name or description
Undo the last operation
Check the model for collisions, floating parts, and structural issues
No error handling guidance in tool definitions. Tools like import_ldr, add_part, and validate_model can fail (invalid file, part not found, collision detected) but definitions do not explain what errors are possible, whether they are retryable, or what the LLM should do next.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Agents cannot distinguish safe read-only tools (get_model_info, list_parts) from destructive ones (remove_part, delete model). This forces agents to reason about safety instead of relying on metadata.