Loading ToolBench
MCP server for scaffolding fullstack AI applications with Next.js framework
This MCP server has a single tool 'build_app' with severe definition quality issues. The tool lacks a proper input schema, only informal Python type hints are visible, not a formal JSON Schema. The description is minimal (67 characters), and parameters lack detailed descriptions explaining constraints, valid values, or usage context. The output schema is completely undocumented; callers have no way to know what fields to expect. The tool performs a WRITE operation (app scaffolding) but the description does not acknowledge this or discuss idempotency/side effects. No error handling, validation, or recovery guidance is visible. The implementation in client.py is a mock that returns hardcoded placeholder data, not a real scaffolder, this suggests the server is incomplete or a proof-of-concept stub. The tool violates multiple critical patterns: tool-description (incomplete docstring), constrained-input (no enums or format specs), response-shaper (no documented output schema), and command-tool (no acknowledgment of state modification).
Build a fullstack AI application with specified framework and prompt
No formal input schema visible, only Python type hints (prompt: str, framework: str). JSON Schema with type definitions, descriptions for each parameter, and enum constraints for 'framework' are missing entirely.
Output schema completely undocumented. The tool returns a dict with 'project_structure' (list) and 'build_status' (string), but callers have no formal definition to rely on. LLMs cannot reliably extract or chain on these fields.
Parameter descriptions are absent or trivial. 'prompt' and 'framework' have one-line descriptions but lack format constraints, valid values, length bounds, or usage hints. The 'framework' parameter has a default ('nextjs') but no enum of supported frameworks.
Tool description (67 chars) is too brief and lacks critical context: WHEN to use it, WHAT it returns, WHETHER it modifies state, what happens on retry, and which parameters are required vs optional.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 30 | 2026-07-28+ | v2 |
No error handling or recovery guidance. The mock implementation always returns success, but a real scaffolder could fail (invalid framework, invalid prompt, insufficient resources). Errors must tell the LLM what to do next.
State modification not acknowledged. 'build_app' is a WRITE operation that creates a project structure, but the description does not say so. Agents need to know which calls are side-effecting and whether they can be safely retried.
No input validation or constraints. The 'framework' parameter accepts any string, but only certain frameworks are likely supported (nextjs, react, svelte, etc.). Without an enum or pattern, LLMs will hallucinate unsupported values.
Mock implementation with hardcoded output. The client.py implementation returns placeholder data ('READY_TO_DEPLOY', hardcoded file list) rather than real scaffolding. This suggests the server is incomplete or a stub, not production-ready.