Loading ToolBench
MCP server for Grasshopper/Rhino integration with AI mentoring. Provides tools for interacting with Rhino/Grasshopper instances, GH file operations, component library access, and code generation for GHPython/C# scripts with AI mentoring features including performance prediction, alternative logic suggestion, auto grouping, and component highlighting.
The server defines 21 tools with explicit schemas and descriptions present in bridge.py. However, there are significant quality gaps that prevent a higher score: (1) Many tool descriptions are minimal (10-30 chars), failing the 10-1024 character guideline and offering insufficient context for LLM tool selection. (2) Parameter descriptions are sparse or missing entirely, tools like 'predict_performance', 'suggest_alternatives', 'auto_group_components', 'apply_layout_preferences' have empty input schemas with no parameters documented. (3) Output schemas are not documented anywhere in the source, violating the critical check that LLMs need to know what fields to expect. (4) Error handling is not visible, no recovery guidance, no error categorization, no retryability hints. (5) Several tool names are vague (e.g., 'suggest_alternatives', 'learn_layout_patterns'), the name alone does not convey the action or subject. (6) Many tools lack actionable details: 'predict_performance' does not state what it predicts performance for, and 'apply_layout_preferences' does not explain what preferences it applies or from where. The server does show good schema structure where present and attempts a comprehensive feature set, but inconsistent rigor across tools and missing output documentation significantly reduce production readiness.
Apply learned layout preferences when creating new components
Automatically group components by function and suggest visual organization
Generate GHPython or C# code from description
Get a specific code template
List available code templates for GHPython or C#
Get all components in a category
List all component categories and subcategories
Four tools ('predict_performance', 'suggest_alternatives', 'auto_group_components', 'apply_layout_preferences') have empty inputSchema properties (empty object {}), no parameters are defined or described. This violates the critical check that every parameter needs a description.
No output schemas are documented anywhere in the source code. LLMs cannot plan downstream tool calls or extract the right data without knowing what fields to expect from each tool's response.
Many tool descriptions are extremely brief (10-30 characters): 'gh_solve' (43 chars), 'gh_canvas_state' (69 chars), 'component_categories' (48 chars). These fall well short of the 10-1024 character guideline and provide insufficient context for LLM tool selection. They do not answer WHAT the tool does, WHEN to use it, or what it returns.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 64 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Search for Grasshopper components by name, description, or keywords
Get current state of the Grasshopper canvas (components, connections)
Get summary of a .gh or .ghx Grasshopper definition file
Find components by name in a Grasshopper definition
Get raw XML content of a .gh or .ghx file
List all components in a Grasshopper definition
Load a .gh/.ghx file into Grasshopper
Trigger a solve/recompute of the current Grasshopper definition
Highlight specific components in the Grasshopper canvas
Learn and remember user's preferred Grasshopper canvas layout patterns from existing definitions
Predict performance improvement before applying optimizations. Shows expected improvement percentage, confidence level, and effort required. Use this to guide users on which optimizations are most effective.
Execute Python code in Rhino's environment (requires bridge listener)
Check if Rhino/Grasshopper is running and connection status
Suggest alternative component patterns or logic approaches
Tool names are vague and do not clearly convey the action or subject: 'suggest_alternatives' (alternatives to what?), 'apply_layout_preferences' (which preferences? from where?), 'predict_performance' (performance of what?). Names should be verb_noun and specific (e.g., 'suggest_component_alternatives', 'apply_user_layout_preferences').
No error handling guidance is present in any tool description. Tools do not indicate whether calls are retryable, what errors are user-fixable, or what recovery steps LLMs should take. This prevents agents from self-correcting on failures.
Many tools that take file paths ('gh_load_definition', 'gh_file_summary', 'gh_list_components', 'gh_find_components', 'gh_get_xml') do not document acceptable file formats, path constraints (absolute vs. relative), or error behavior when a file is missing or invalid.
The 'code_templates' tool has a parameter 'language' that is not marked as required, but the description suggests it is necessary ('Language: python or csharp'). Parameter requirements and enums should be explicit in the schema.
The 'code_generate' tool accepts complex nested parameters ('inputs', 'outputs' as arrays of objects) but provides no example structure or validation rules. LLMs may struggle to construct the correct nested format without examples or constraints.
Tools like 'rhino_execute_python' and 'gh_load_definition' perform irreversible or risky operations (code execution, file loading) but do not mention this in descriptions or offer confirmation/dry-run patterns to prevent accidental misuse.