Loading ToolBench
MCP server for scaffolding Next.js applications with Docker support
The server defines 8 tools with consistent schemas and detailed parameter documentation. However, critical issues limit production readiness: (1) all tool descriptions are generic action statements without context about when/why to use them or what data they return; (2) parameter descriptions repeat verbatim across all 8 tools, indicating copy-paste rather than thoughtful differentiation; (3) no output schemas are documented, LLMs cannot infer what these tools return, forcing them to guess; (4) error handling is absent from all tool definitions; (5) 7 of 8 tools are WRITE operations with no idempotency guarantees, confirmation steps, or dry-run options, raising catastrophic risk; (6) tool names lack clarity on scope, 'setup_shadcn' vs 'generate_base_components' suggests overlapping responsibilities without explicit differentiation. The server does correctly use JSON Schema with types and enums, which is a baseline requirement met.
Generate base React components and layouts
Generate Dockerfile and docker-compose.yml
Generate comprehensive README.md
Create a new Next.js project with specified configuration
Configure authentication system
Generate database configuration and migrations
Initialize shadcn/ui with defaults and install all components
No output schemas documented. LLMs cannot infer what these tools return, success/failure indicators, generated files, configuration details, validation results, etc. This forces LLMs to guess and plan subsequent actions blindly.
Tool descriptions are one-line action statements ('Create a new Next.js project...') with no context about when/why to use each tool, prerequisites, dependencies between tools, or what problems they solve. Descriptions should be 50-200 chars with discovery guidance.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Run validation checks on the generated project
All 7 WRITE tools lack error handling, confirmation mechanisms, dry-run support, or idempotency guarantees. An LLM could accidentally scaffold two projects in the same directory, overwrite files, or apply incompatible database/auth combinations with no rollback path.
Parameter descriptions are identical across all 8 tools (verbatim copy-paste of config object descriptions). This suggests the schema was templated without differentiation, each tool should explain what aspect of the config it uses and how it differs from related tools.
Tool names lack specificity around what is created vs configured. 'setup_shadcn', 'setup_database', and 'setup_authentication' vs 'generate_base_components' use inconsistent verb patterns (setup vs generate). Also unclear if 'setup_shadcn' installs shadcn or only initializes config.
No documentation of tool dependencies or sequencing. The LLM has no guidance on which tools must run first (e.g., must scaffold_project run before setup_database?). Correct sequence is critical for a code generation tool.
The 'config' parameter is required and identical across all tools, but each tool likely uses only a subset of its fields. The schema should clarify which config fields are actually consumed by each tool and what happens if incompatible options are passed (e.g., auth='better-auth' but database='none').
'targetPath' and 'projectPath' parameters appear to be the same concept (both are directory paths) but have different names. This inconsistency will confuse LLMs and cause path mismatches across tool calls.