Loading ToolBench
Model Context Protocol server built with Next.js for analyzing and auditing Next.js projects
Three tools with clear names and reasonable descriptions, but significant gaps in parameter documentation and output schema specification. All tools are read-only file analyzers with good naming (analyze_, inspect_, audit_) following verb_noun convention. Descriptions are adequate (100-150 chars) but lack actionable context for LLM selection. Critical issue: no output schemas documented anywhere, LLMs cannot plan downstream calls or extract structured data. Parameter descriptions exist but are minimal. Error handling is present in code but not surfaced in tool definitions.
Analyzes a Next.js project and returns metadata including router type (App Router vs Pages Router), Next.js version, dependencies, and scripts
Audits a Next.js project's bundle sizes against a performance budget threshold, identifying pages that exceed the budget and providing optimization recommendations
Inspects and lists all API routes in a Next.js project, including their paths, types (api, page, layout, loading, error, not-found), and whether they are dynamic
No output schemas documented. Tools return complex objects (PackageInfo, RouteInfo[], PerformanceAuditResult) but LLMs have no visibility into field names, types, or structure. Prevents downstream tool chaining and forces LLMs to guess at response format.
Parameter descriptions are minimal (5-10 words). 'Absolute path to the Next.js project root directory' lacks context on format validation, error cases, or what happens if path is invalid. Should include: expected format, validation rules, and recovery guidance.
audit_performance_budget accepts numeric budgetKb with no constraints. Missing: min/max bounds, units clarification, and guidance on typical values. Unbounded numbers let LLMs pass absurd values (e.g., 999999999 KB).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2026-07-28+ | v2 |
No error handling guidance in tool definitions. Code throws errors for missing package.json and invalid JSON, but tool descriptions do not explain what to do if projectPath is invalid or not a Next.js project. LLMs cannot self-correct.
Tool descriptions lack WHEN-to-use context. 'Analyzes a Next.js project' is WHAT, but missing: when should LLM call this vs inspect_api_routes? What prerequisites? What does it enable downstream? Incomplete docstrings force LLMs to guess.