Loading ToolBench
RocketSmith defines 2 tools with partial schema coverage. rocketsmith_setup has a complete input schema with enums and descriptions; gui_server similarly has typed parameters with descriptions. However, both tools lack documented output schemas, critical for LLM planning. Descriptions are adequate (150 - 250 chars) but generic; they explain WHAT but not WHEN to use each tool or error recovery paths. Parameter descriptions are present but minimal (10 - 30 chars). No error handling guidance, no recovery hints, and no indication of which operations are destructive or idempotent. Tool naming follows verb_noun convention (setup, gui_server) but 'gui_server' is vague, does not clearly signal start/stop/dev actions. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite gui_server performing write operations.
Manage the RocketSmith GUI server. Use action='start' to launch the GUI (copies bundle to project, starts backend, opens browser). rocketsmith_setup also calls start automatically — use this tool to recover if the GUI did not open or to launch it explicitly. Use action='dev' to launch in development mode with Vite HMR for frontend hot-reloading. Use action='stop' to shut down a running GUI server. Pass project_dir for all actions.
Check or install rocketsmith dependencies (Java, OpenRocket, PrusaSlicer). Always call this at the start of a session with ``project_dir`` set to the user's project directory. This registers the project directory for the lifetime of the MCP server process so all subsequent tools resolve paths correctly without requiring an explicit ``project_dir`` argument. It also starts the GUI server automatically and opens the browser. Actions: - check: Return the current installation status of each dependency. - install: Install any missing dependencies for the current platform, then return status. Supported platforms for automatic install: - macOS: Java via Homebrew, OpenRocket JAR downloaded directly, PrusaSlicer via Homebrew cask - Linux: Java via apt, OpenRocket JAR downloaded directly, PrusaSlicer via Homebrew or AppImage - Windows: Java via winget (Temurin), OpenRocket JAR downloaded directly, PrusaSlicer via winget
Output schemas not documented. Both tools return structured objects (DependencyStatus, implicit server state) but LLMs cannot plan downstream calls without knowing response fields. Agents cannot extract gui_url, gui_pid, or gui_error reliably.
No error handling guidance. Tools can fail (missing dependencies, port conflicts, file I/O errors) but descriptions do not explain failure modes or recovery steps. LLMs receive raw errors with no actionable next steps.
No tool annotations. gui_server performs destructive operations (stop kills processes, start overwrites files) but lacks destructiveHint. rocketsmith_setup modifies system state (installs dependencies) but lacks idempotentHint. LLMs cannot reason about retry safety.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | <=2025-11-25 | v2 |
Parameter descriptions are minimal (10 - 30 chars). 'Path to the user's project directory' is adequate, but 'Bind address' and 'Backend port' lack context (format, constraints, defaults). LLMs cannot validate inputs before calling.
Tool naming ambiguity. 'gui_server' does not signal that it manages lifecycle (start/dev/stop). A verb-first name like 'manage_gui_server' or separate tools (start_gui, stop_gui, dev_gui) would clarify intent and reduce LLM confusion.