Loading ToolBench
MCP server that scaffolds fullstack applications from declarative UI mockup descriptions, generating UI components, API routes, and Prisma ORM schemas with TypeScript strict typing
This MCP server has severe definition quality issues. Only one tool is present (execute_skill_action), and while it has a name and basic description, the implementation is fundamentally broken. The mcp_server.py file contains no actual tool registration mechanism, it merely prints a static JSON string and exits. There is no MCP protocol implementation, no input schema validation, no actual tool invocation logic, and no connection between the declared tool in documentation and any executable code. The tool has an input schema visible in documentation (ui_mockup_description and stack_preset), but this schema is not enforced or validated anywhere in the server code. The description is generic (28 characters) and provides no actionable guidance on when to use the tool, what it actually does internally, or what the user should expect. The server appears to be a stub or incomplete POC rather than a functioning MCP server. Per the hard scoring rules: tool definitions are inferred from documentation rather than visibly implemented in code (capping at 50 max), and the descriptions are under 50 characters (capping description at 40).
Execute a skill action for the declarative design to fullstack app scaffolder
No actual MCP protocol implementation. The mcp_server.py file prints a static JSON response and exits, there is no stdio message loop, no tool invocation handler, and no connection to client requests. The server cannot receive or process tool calls.
Tool definition is not visible in the actual MCP server code. The tool name, description, and schema appear only in documentation/comments, not in any executable registration logic.
Input schema lacks proper JSON Schema format validation in code. While the documentation mentions ui_mockup_description (string) and stack_preset (string), there is no runtime validation, no enum constraint on stack_preset values, no minimum/maximum length constraints, and no error handling for invalid inputs.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 31 | 2026-07-28+ | v2 |
Tool description is too short (28 characters) and provides no actionable context. It does not explain when to use this tool vs. alternatives, what it actually returns, what prerequisites exist, or what side effects occur.
No parameter descriptions in the actual schema. The parameters ui_mockup_description and stack_preset have no descriptions beyond their type. LLMs cannot infer what valid values for stack_preset are (e.g., is 'NEXTJS14_TAILWIND_PRISMA' the only option, or one of many?).
stack_preset parameter accepts free-form strings with no enum constraint. The example shows 'NEXTJS14_TAILWIND_PRISMA', but the schema does not declare this as an enum. LLMs will hallucinate invalid stack names. Should declare enum: ['NEXTJS14_TAILWIND_PRISMA', ...].
No output schema documented. The client.py example shows a response structure (scaffolding_job_id, stack, ui_components_generated_count, etc.), but this is not formally documented as the tool's return type. LLMs cannot plan downstream operations without knowing what fields to expect.
No error handling or recovery guidance. If scaffolding fails, what error does the tool return? Can the agent retry? Should it suggest alternatives? There is no error classification, no actionable error messages, and no guidance on what to do next.
Tool performs a write operation (scaffolds a fullstack app) but has no confirmation step, dry-run option, or idempotency guarantee. Agents may accidentally create multiple scaffolding jobs for the same UI description. Should support a 'dry_run' parameter or confirmation request.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). The tool modifies state (creates scaffolded apps), but there is no explicit destructiveHint annotation to warn agents of irreversible consequences.