Loading ToolBench
Universal Next.js code analysis tool to identify unused files, dead code, and redundant API endpoints with advanced pattern detection and project health scoring
The server implements 4 tools with clear action verbs and reasonable structure, but has significant gaps in schema visibility, parameter descriptions, and error handling guidance. Tool names follow verb_noun patterns (analyze-project, get-job-status, get-analysis-report, get-file-details), which is good. However, the source code provided is truncated mid-implementation, making it impossible to verify complete input schemas and output structures. The visible Zod schema definitions for analyze-project are well-structured with type constraints (min/max for confidenceThreshold, enum for format), but other tools' schemas are not shown. Parameter descriptions exist but are minimal (10-40 chars) and lack context about when to use tools and what to expect. Error messages in the code are localized via i18n, which complicates assessment but appears to provide some guidance. The server uses READ_ONLY risk classification, which is appropriate.
Analyze a Next.js project to identify unused files, dead code, and redundant API endpoints
Get the analysis report for a completed analysis job
Get detailed analysis information for a specific file from a completed analysis
Get the status of an ongoing or completed analysis job
Input schemas not visible for 3 of 4 tools (get-job-status, get-analysis-report, get-file-details). Source code is truncated; cannot verify schema completeness, type definitions, or parameter constraints.
Parameter descriptions are minimal (10-40 characters) and lack context. E.g., 'The job ID returned from analyze-project' for jobId is functional but does not explain when to call get-job-status vs waiting, or what statuses mean. Descriptions should be 50-200 chars and include decision context.
Output schemas not documented. Code returns text content via ContentBlock unions, but the structure of job status, analysis reports, and file details is not explicitly defined. LLMs need to know what fields to extract and how to chain results to next tools.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 37 | - | v1 |
Error messages are localized via i18n (tSync function), making it impossible to verify whether errors are actionable. E.g., 'Job not found' is returned, but the code does not suggest alternatives like list-jobs or explain what jobId format is expected. Error responses should guide recovery.
analyze-project description does not state that the tool is async and returns immediately with a jobId. LLMs need explicit guidance that they must poll get-job-status to wait for results. This is a critical composition dependency.
No pagination support visible. If analyze-project returns large reports or get-analysis-report returns many findings, there is no offset/limit mechanism shown. Large results will blow context windows without pagination.
Tool composition assumes LLM will know to call analyze-project, poll get-job-status, then retrieve reports. No guidance on expected sequence. If analysis can take minutes, timeout handling is not documented.