Loading ToolBench
Application MCP Server for creating custom MCP implementations with interactive assistant for app design preferences
Single tool with reasonable parameter coverage but significant clarity and design issues. The tool name 'question_app_design' lacks a clear action verb (should be 'gather_app_design_preferences' or similar). Description is lengthy (251 chars) but generic, it reads like an API doc rather than LLM-optimized guidance. Parameters are well-typed (Zod schema visible) with descriptions, but many descriptions contain prescriptive guidance ('The AI should...') that belongs in system prompts, not tool definitions. The tool appears to implement a multi-turn conversation flow as a single tool, which violates the single-responsibility principle. No output schema is documented. Error handling and recovery guidance are absent from the code.
Interactive assistant to gather comprehensive app design preferences, including style, color schemes, language support, typography, and functionality requirements, to tailor the app creation process to user needs.
Tool name does not start with action verb. 'question_app_design' is ambiguous, is it asking a question, querying an app, or designing one? Should be 'gather_app_design_preferences', 'collect_design_requirements', or 'start_app_design_wizard'.
Output schema is completely undocumented. The tool handler returns text responses (content[{type:text, text:...}]) but the LLM has no way to know the structure, when responses are complete, or what data to extract for downstream use. This violates the documented response-shaper pattern.
Multi-turn conversation logic embedded in a single tool. The tool implements a state machine (choose_style → design_style → custom_palette → palette → ...) with conditional prompts. This should be either (1) a prompt/resource that guides the LLM through a conversation, or (2) split into separate tools (e.g., gather_design_style, gather_palette, gather_fonts). A single tool doing one thing at a time is clearer for agent reasoning.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 42 | - | v1 |
Parameter descriptions are overly prescriptive and belong in system/user prompts, not tool definitions. E.g., 'The AI should list these options when prompting the user' and 'The AI should ask the user to provide a comma-separated list' are instructions to the LLM, not explanations of what the parameter means. This bloats descriptions and makes them less actionable.
No error handling or recovery guidance. The tool handler returns text prompts but does not validate inputs, check for missing required fields in conditional branches, or explain what to do if a user provides invalid data (e.g., invalid color hex code, unsupported language).
Tool description does not clarify when this tool should be called vs. alternatives. It should explicitly state: 'Call this tool to interactively gather app design preferences from a user. It guides the user through multiple rounds of questions.' Currently it reads like generic API documentation.
Parameters like 'choose_style', 'custom_palette', 'multi_language_support' are boolean flags that control conditional logic. The tool description doesn't explain the dependency: which parameters are required on first call? Which become relevant after others are set? LLMs need explicit dependency hints to use this tool correctly.