Loading ToolBench
The AI-powered backend diagnostic MCP that understands what you're building and makes sure it actually works.
Backend Max defines 41 tools with consistent naming (verb_noun pattern: run_diagnosis, scan_routes, audit_security) and comprehensive descriptions (avg ~150 chars, well above 20-char minimum). All tools have input schemas with type definitions and parameter descriptions. However, output schemas are NOT documented in the source, critical for LLM planning. Many tools lack error handling guidance, recovery paths, and actionable error messages. Parameter descriptions are present but generic; few specify constraints (ranges, enums, formats). No tool annotations (readOnlyHint/destructiveHint) visible despite clear risk levels (WRITE vs READ_ONLY marked in metadata). Tool composition is reasonable but some tools combine multiple concerns (e.g., run_diagnosis does scanning + documentation + ledger updates). Missing pagination/limit guidance for list-returning tools.
Audit API versioning strategy. Checks for version consistency, deprecation warnings, and breaking change handling.
Analyze authentication surface on a live backend. Tests for common auth vulnerabilities and misconfigurations.
Detect breaking changes in the API that could affect clients.
Audit cookie security on a live backend. Checks for missing Secure, HttpOnly, and SameSite flags.
Audit CORS configuration on a live backend. Detects overly permissive CORS policies.
Analyze DNS and infrastructure configuration for a domain. Checks for DNS security, SPF, DKIM, DMARC, etc.
Audit error handling across all API routes. Checks for try/catch coverage, consistent error response formats, unhandled promise rejections, and missing global error handlers.
Output schemas not documented. LLMs cannot plan downstream tool calls or extract required fields (e.g., does scan_routes return endpoint IDs for use in check_contracts?). Critical for tool composition.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels marked in metadata (READ_ONLY vs WRITE). Agents cannot distinguish safe from destructive operations.
Error handling lacks recovery guidance. Tools return bare descriptions (e.g., 'Audit error handling') without specifying what errors can occur, how to interpret them, or what the LLM should do next.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | <=2025-11-25 | v2 |
Audit external API calls and integrations. Checks for proper error handling, timeouts, and retry logic.
Audit GraphQL schema and resolvers for security, performance, and best practices.
Audit HTTP security headers on a live backend. Checks for missing security headers like CSP, X-Frame-Options, etc.
Audit database migrations for safety, consistency, and rollback capability.
Audit backend performance: checks for N+1 queries, missing indexes, unoptimized database calls, and inefficient algorithms.
Audit Prisma schema and usage: checks for N+1 queries, missing indexes, unoptimized relations, and schema design issues.
Audit rate limiting and caching strategies. Checks for missing rate limits on sensitive endpoints and inefficient cache usage.
Scan for hardcoded secrets, API keys, and credentials in the codebase.
Audit backend security: checks for auth patterns, SQL injection risks, XSS vulnerabilities, CORS misconfigurations, and insecure dependencies.
Audit Next.js Server Actions for missing validation, error handling, auth checks, and unprotected database calls.
Audit TLS/SSL certificate and configuration on a live backend. Checks for certificate validity, weak ciphers, etc.
Build a dependency graph of all API endpoints, showing which endpoints call which other endpoints and external services.
Verify frontend-backend contracts. Finds all API calls in frontend code and cross-references them against backend route definitions. Detects mismatches, dead endpoints, and phantom calls.
Apply fixes to all detected issues in the project. Modifies source code.
Apply a proposed fix to a specific issue. Modifies source code.
Generate living API documentation from the codebase. Returns endpoint descriptions, parameters, response types, and examples.
Get a summary of changes since the last diagnosis.
Identify common patterns and anti-patterns in the codebase.
Get the current project understanding.
Get the issue ledger — a persistent record of all issues found, their status, and when they were fixed.
Analyze a project for the first time to understand what it does. Scans routes, package.json, database schema, and README to build a project understanding. Run this before any diagnosis.
Test error handling on a live backend by sending malformed requests and checking for information disclosure.
Query the API dependency graph to find call chains, circular dependencies, and impact analysis.
Run a full backend diagnosis — scans routes, checks contracts, audits errors, env vars, security, and performance. Generates documentation and updates the issue ledger. This is the main entry point.
Run an incremental analysis on changed files since the last diagnosis. Faster than full diagnosis.
Run live tests against the backend to verify endpoints work correctly. Makes actual HTTP requests.
Scan project dependencies for security vulnerabilities, outdated packages, and license compliance issues.
Scan for all environment variables used in the project. Returns which are defined, which are missing, and which may be secrets.
Discover API endpoints by analyzing frontend JavaScript. Extracts all fetch/axios calls to identify the API surface.
Scan and parse all API routes in a Next.js project. Returns the full API surface: endpoints, HTTP methods, parameters, and file locations.
Calculate a technical debt score for the backend based on code quality, test coverage, and architectural issues.
Trace TypeScript types through the codebase to find type mismatches and unsafe type assertions.
Update the project understanding with user-provided corrections or additions.
Visualize the middleware stack and execution order in the backend.
Parameter descriptions are generic and lack constraints. 'focus' enum in run_diagnosis is well-defined, but most tools lack range/format specs. E.g., baseUrl parameter has no validation hint (must be valid URL).
run_diagnosis combines multiple concerns (scanning, documentation, ledger updates). Should split into separate tools (scan_backend, generate_docs, update_ledger) for better composability.