Loading ToolBench
Turn any documentation site into a local MCP server. Crawls documentation sites, indexes them with BM25 search, and exposes tools for listing docs, searching pages, and fetching page content.
Pinax has 5 well-named, read-only discovery and fetch tools with clear descriptions (avg 120 chars). All tools have input schemas with type definitions and parameter descriptions. However, output schemas are not documented in the visible code, the tool descriptions mention what they return (e.g., 'Returns structured text with headings and paragraphs' for get_page) but no formal JSON schema is visible. Error handling is basic: resolve() returns formatted error messages with available options, which is good, but no per-tool error guidance or recovery hints. No tool annotations (readOnlyHint, etc.) despite all being read-only. Parameter descriptions are adequate but could be more prescriptive about constraints (e.g., search_pages limit default and max). Overall solid for a documentation discovery tool, but lacks output schema documentation and tool annotations that would push it to 75+.
Fetch and extract the main content from a documentation page. Returns structured text with headings and paragraphs. Caches results within a session and across restarts.
Get all pages in a specific documentation section.
List every documentation site indexed in this Pinax instance. Call this first to discover available `docs` values for the other tools. In single-docs mode this returns a one-entry list.
List the high-level documentation sections (categories) available for one indexed docs site, with a sample of pages per section. Call this first to get an overview of what's available.
Fuzzy-search documentation pages by URL or title. Returns up to 50 best matches. Use this when the user asks about a specific feature, API, or concept. Omit `docs` to search across every indexed site at once — each hit then carries a `docs` field.
Output schemas not documented. Tool descriptions mention what they return (e.g., 'Returns structured text', 'Returns up to 50 best matches') but no formal JSON schema is visible in the code. LLMs cannot plan downstream operations without knowing the exact response structure.
No tool annotations despite all tools being read-only. The MCP spec supports readOnlyHint to signal safe tools. This helps agents reason about side effects and retry safety.
search_pages 'limit' parameter lacks explicit bounds. Description says 'default 50' but does not state max or min. Unbounded numeric parameters invite LLMs to pass absurd values.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
Error handling is basic. resolve() returns formatted messages with available options (good), but individual tools lack recovery guidance. E.g., if get_page fails to fetch a URL, the error should suggest search_pages or list_sections as alternatives.
get_section_pages description is minimal (18 chars: 'Get all pages in a specific documentation section.'). While not under 20, it lacks context on when to call it vs search_pages or list_sections.