Loading ToolBench
MCP server that receives why-did-you-render reports from the browser and exposes them as tools for AI coding agents to diagnose React performance issues
14 tools with consistent naming (verb_noun pattern: get-, list-, clear-, pause-, resume-, save-, compare-, delete-, wait-). All tools have descriptions (avg 85 chars, within 10-1024 range). Input schemas present for all tools with typed parameters. However, descriptions are terse (many under 100 chars) and lack context on WHEN to use tools or dependencies between them. Parameter descriptions are minimal, most are 1-2 sentences. No output schemas documented. Error handling guidance absent. Missing tool annotations (readOnlyHint, destructiveHint). Composition is sound: tools are single-responsibility and chainable (e.g., get-renders → compare-snapshots). No security issues detected (no secrets in params). Baseline: 549 production tools average 194 chars for tool descriptions and 72 chars for param annotations; this server averages ~85 and ~40 respectively.
Clear all stored render reports, optionally filtered by component or project
Compare two snapshots to identify changes in render behavior
Delete a saved snapshot
Retrieve commit information including render counts and affected components
List all projects that have sent render reports
Get a summary of render statistics grouped by component
Retrieve all render reports, optionally filtered by component name or project
Get all renders for a specific commit
Output schemas not documented. LLMs cannot infer what fields get-renders, get-render-summary, or compare-snapshots return, forcing them to guess downstream field names and risk broken tool chains.
Tool descriptions lack context on WHEN to use each tool and dependencies. E.g., 'Get all renders for a specific commit' does not explain that you must call get-commits first to obtain a commitId, or that this tool is useful for comparing render behavior across commits.
No error handling guidance. Tools like clear-renders and delete-snapshot are destructive but provide no recovery hints (e.g., 'Snapshots cannot be recovered after deletion. Consider saving a backup first.').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
Get the list of components being tracked by why-did-you-render
List all saved snapshots
Pause render collection on the client side
Resume render collection on the client side
Save a snapshot of current render data for later comparison
Wait for render reports to arrive from the client
Tool annotations missing. destructiveHint should mark clear-renders and delete-snapshot; readOnlyHint should mark get-* and list-* tools. These annotations help LLMs reason about side effects and plan safely.
Parameter descriptions are minimal (avg ~40 chars vs. baseline 72 chars). E.g., 'Optional project ID to filter renders' lacks guidance on format (UUID? slug? integer?) or what happens if the ID is invalid.