Loading ToolBench
MCP server that gives AI assistants context about Base UI (base-ui.com).
Server provides 2 tools with clear verb-noun naming (base_ui_list_docs, base_ui_get_doc) and reasonable descriptions (120-180 chars, within baseline 34-392 range). Both tools have input schemas with type definitions. However, parameter descriptions are minimal or absent in the visible schema definitions, and output schemas are not documented. Error handling guidance is not evident. The tools are read-only and well-scoped, but lack the depth of documentation expected for A-grade tools. Descriptions are adequate but could be more prescriptive about when to use each tool and what to expect.
Fetches a specific Base UI documentation page by path identifier (e.g., "react/components/accordion.md"). The identifier should come from the list-docs tool output.
Fetches the Base UI documentation index (llms.txt) and returns it with URLs replaced by identifiers that can be used with the get-doc tool.
Output schemas not documented. LLMs cannot infer what fields list_docs and get_doc return, forcing them to guess at response structure and plan downstream operations blindly.
Parameter descriptions are minimal. The 'path' parameter in base_ui_get_doc has a description, but no constraints on format, length, or valid patterns are specified. LLMs may pass invalid paths.
No error handling guidance. Descriptions do not explain what happens if a path is invalid, if docs are unavailable, or how to recover. Agents have no recovery strategy.
No pagination or result limits documented. If list_docs returns hundreds of entries, context window could be exhausted. No mention of limits or pagination strategy.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | 2026-07-28+ | v2 |
Tool composition assumes LLM will call list_docs first, then get_doc. This dependency is mentioned in get_doc description but not formalized. No batch variant for fetching multiple docs.