Loading ToolBench
MCP server for Agentic React runtime selection and devtools integration, providing tools for React component inspection, selection, state management, and source code lookup during local development
The server defines 9 tools with consistent naming (all verb-prefixed: highlight-, get-, set-, copy-) and basic schemas. However, significant quality gaps limit production readiness. All tools have descriptions (good baseline compliance), but most descriptions are brief (10-40 chars) and lack depth required by pattern:tool-description. Input schemas are present for all tools with basic type declarations, but lack comprehensive validation constraints (enums, ranges, patterns). Parameter descriptions exist but are minimal (many 15-30 chars). The tools are read-only except for 2 write operations (set-selection-mode, copy-last-selection-context), which lack confirmation/dry-run safety patterns. Error handling and recovery guidance are not visible in tool definitions. Output schemas are undocumented, LLMs must infer what fields each tool returns. The server uses HTTP transport (good for protocol readiness) but tool annotations (readOnlyHint, destructiveHint, idempotentHint) are not declared despite the risk metadata being present in the input. Overall, this is a competent early-stage implementation with room for maturity in description depth, schema richness, and error guidance.
Copy the latest captured selection context from the browser runtime into clipboard.
Get the React component props, states, and contexts in JSON structure format.
Get the React component tree of the current page in ASCII format.
Find matching HTML elements by search strings and return deterministic candidates.
Get the latest captured selection context, optionally enriched with source snippets from the project filesystem.
Find matching elements using search strings and return deterministic React source context for the best candidate.
Tool descriptions lack depth and context. Most are 10-50 chars, falling below the 50-200 char sweet spot for LLM-optimized descriptions. E.g., 'Get the wasted re-rendered components of the current page' (57 chars) does not explain WHEN to call this tool, WHAT the output contains, or HOW to interpret results. This forces LLMs to infer behavior, increasing misselection risk.
Output schemas are completely undocumented. LLMs have no visibility into what fields each tool returns, their types, or how to chain results. E.g., 'get-component-tree' returns 'ASCII format', but what fields? What structure? Does it include component IDs needed by 'highlight-component'? Undocumented outputs force agents to call tools blind and parse results via trial-and-error.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 48 | - | v1 |
Get the wasted re-rendered components of the current page
Highlight React component based on the component name.
Enable or disable browser element selection mode for context capture.
Write operations (set-selection-mode, copy-last-selection-context) lack confirmation/dry-run safeguards. These tools modify state or interact with the browser clipboard without requiring user confirmation or offering a preview step. Pattern:confirmation-request requires destructive operations to support dry-run or confirmation, preventing accidental side effects from agent mistakes.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are absent from tool definitions, despite metadata clearly distinguishing READ_ONLY vs WRITE risks. The current MCP spec (2026-07-28) expects these hints in the tool schema. Without them, LLMs cannot reason about safe retry behavior, leading to unintended side effects if an operation partially succeeds.
Parameter descriptions are minimal (15-30 chars in many cases). E.g., 'maxDepth' is described as 'Maximum depth of component tree to retrieve', but what are valid bounds? What does depth=0 mean? What is the default? Are there performance implications? Vague constraints force LLMs to guess valid inputs.
Error handling and recovery guidance are not visible in tool definitions. When a tool fails (e.g., component not found, selection context empty), there is no documented path for the agent to recover. Pattern:recovery-guide requires error responses to tell the LLM what to do next, but no tool definition includes error cases or alternative actions.
get-unnecessary-rerenders accepts no parameters, making it impossible to filter by component name, depth, or severity. This violates pattern:constrained-input, tools should accept parameters to control scope and reduce noise. Without parameters, the tool returns all re-renders regardless of relevance, wasting tokens and forcing the agent to parse unwanted results.
format parameter in copy-last-selection-context uses an enum (text|json) but lacks guidance on WHEN to use each. The description does not explain what the output looks like in each format, or how the agent should choose. This invites arbitrary enum selection instead of informed decisions.