Loading ToolBench
MCP (Model Context Protocol) server for Silex website builder desktop application. Provides static tools for website management and screenshot capture, plus dynamic tools loaded from grapesjs-ai-capabilities registry.
Three tools are explicitly registered in src-tauri/src/mcp.rs with JSON schemas and descriptions. All tools have action enums or string parameters with type declarations. However, descriptions are minimal (16-29 chars for tool summaries), and parameter descriptions lack actionable detail. The website tool conflates multiple responsibilities (list, create, delete, rename, duplicate, open, dashboard) into one tool with an enum action. The eval_js tool exposes arbitrary code execution with minimal guardrails. Output schemas are not documented. Error handling and recovery guidance are absent. Tool composition violates single-responsibility principle.
Execute arbitrary JavaScript in the editor webview and return the result. Requires an open project.
Capture a screenshot of the Silex editor UI or canvas preview.
Manage websites in Silex: list, create, delete, rename, duplicate, open, or navigate to dashboard.
website tool conflates 7 separate operations (list, create, delete, rename, duplicate, open, dashboard) into a single tool with an enum action parameter. This violates single-responsibility principle and forces the LLM to reason about which action to invoke rather than selecting the appropriate tool.
Parameter descriptions are minimal or generic. 'action': 'The action to perform' (20 chars) does not explain what each action does or when to use it. 'website_id': 'Website ID (required for delete, rename, duplicate, open)' is conditional without explaining what the ID looks like or how to obtain it.
No output schemas documented for any tool. LLM cannot know what fields to expect from website (list action), take_screenshot (image inline), or eval_js (return value type). This prevents downstream tool chaining and forces the LLM to guess at response structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | 2026-07-28+ | v2 |
eval_js tool executes arbitrary JavaScript in the editor webview with minimal safety guardrails. Description does not mention sandboxing, scope limitations, or what APIs are available. A 30-second timeout is the only constraint mentioned. No confirmation or dry-run support for irreversible side effects.
Error handling and recovery guidance completely absent. If website creation fails, take_screenshot produces an empty image, or eval_js times out, the tool response does not guide the LLM on what to do next or how to self-correct.
Tool names do not follow verb_noun convention. 'website' is a noun alone; should be 'list_websites', 'create_website', 'delete_website', etc. 'take_screenshot' is correct; 'eval_js' is vague (eval, run, execute are all used for code execution). Ambiguous names reduce LLM clarity.
website_id parameter requires opaque IDs but no mechanism shown to list or search websites by name. User says 'delete my portfolio website', but the tool requires a website_id. The LLM must first call website with action='list', parse the response, find the matching name, extract the ID, then retry the delete. This is inefficient and error-prone.
take_screenshot output_file parameter is optional but no guidance on where files are saved, what directory structure exists, or how to retrieve the file later. If the LLM passes a path, where does it land? Is it relative to the Silex project, user's home, or temp?