Loading ToolBench
MCP server providing tools to extract and retrieve documentation, API information, usage examples, slots, data attributes, and accessibility features from HeroUI component documentation
The HeroUI MCP server has basic tool structure with Zod-based schema validation and consistent tool definitions. However, it suffers from significant gaps in parameter descriptions, output schema documentation, and error handling guidance. 6 of 8 tools have identical or nearly identical parameter schemas (single 'componentName' string), which raises concerns about whether schemas are properly defined or merely inferred. The 'add' tool uses string-typed numeric parameters rather than number types, creating unnecessary conversion logic. Parameter descriptions are present but minimal (1-2 lines), falling short of the 72-char baseline for A+ tools. Output schemas are not documented, responses are returned as generic text content without structured field documentation. No tools declare risk levels explicitly via annotations. Error messages use generic patterns without recovery guidance.
Add two numbers
Extract accessibility sections from HeroUI component documentation showing ARIA support and accessibility features
Extract API sections from HeroUI component documentation showing props, types, and configuration options
Extract data attributes sections from HeroUI component documentation showing available data attributes
Get component documentation from HeroUI including overview, features, and installation instructions
Extract slots sections from HeroUI component documentation showing available slots and their usage
Get usage examples and code snippets for HeroUI components
Parameter types use strings instead of appropriate types. The 'add' tool accepts numeric inputs as z.string() rather than z.number(), forcing manual Number.parseInt() validation inside execute(). This creates unnecessary error surface and wastes tokens on type conversion.
No output schema documentation. All tools return generic {content: [{type: 'text', text: string}]} without documenting what fields or structure the text response contains. LLMs cannot plan downstream operations or extract structured data.
Parameter descriptions are minimal (8-40 characters). The rubric baseline is 72 chars average for A+ tools. E.g., 'Name of the HeroUI component (e.g., 'button', 'input')' uses example values instead of formal constraints. Descriptions should state format, range, and provide recovery hints.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 54 | - | v1 |
List all available HeroUI components from the cached documentation
Error handling is generic. The ValidationError for invalid numbers in 'add' returns a string error with no recovery guidance. LLMs cannot determine if the error is retryable, user-fixable, or fatal, and have no hint for what to try next.
No tool annotations (toolAnnotations=false). Tools are marked as READ_ONLY in the specification but declare no explicit readOnlyHint, destructiveHint, or idempotentHint in the tool definition. This prevents clients from enforcing operation policies or optimizing caching.
Six tools (get_component_*) have identical single-parameter schemas. This pattern suggests parameters may be inferred rather than explicitly validated. The Zod schema definitions are not visible in the source, so schema completeness cannot be fully verified.
No pagination for list_components. If HeroUI has many components, returning all of them in one response could exhaust context. The tool should accept limit and offset/cursor parameters and return a total count.