Loading ToolBench
A self-hosted documentation framework built on Astro that provides MCP tools for searching, listing, and fetching documentation pages, with support for both lexical and AI Search retrieval backends.
Four tools with complete JSON schemas and descriptions. Tool names follow verb_noun convention (search, list, fetch, feedback). Descriptions are well-written (100-200 chars), explaining WHAT, WHEN, and WHY. Input schemas properly typed with required fields and additionalProperties=false. However, output schemas are not documented in the source code, LLMs cannot see what fields to expect from responses. Parameter descriptions are present but minimal. Error handling guidance is absent, no recovery hints or categorization. The feedback tool accepts free-form strings without validation constraints.
Send feedback about the documentation or the agent's response. Use this to report errors, suggest improvements, or provide context about what worked or did not work.
Fetch the full text of a page by its ID. Use this when you need to read a complete page, or when search returned only a small part of a long page and you want the rest. The response includes the page's Markdown source, line by line, so you can quote it accurately.
List all pages in the documentation, with their titles, descriptions, and types. Use this to browse what the documentation covers when a search returns nothing or when you want to see the full scope of available pages.
Search the documentation and return the most relevant passages, grouped by the page they come from. Use this before answering any question about the documentation — it searches the current published documentation directly, which is more reliable than recalling it. Pages are ordered by relevance; passages within a page are in reading order. Each passage reports its line range within the page, so you can tell whether you are seeing a small part of a long page and should call `fetch` for the rest. An empty result means nothing matched closely, not that the topic is missing — the response says what to do next, usually `list_pages` followed by `fetch`.
Output schemas not documented. LLMs cannot see what fields search(), list_pages(), fetch(), or feedback() return. This forces agents to guess at response structure and risks failed downstream tool calls.
No error handling guidance. Tools do not document what errors can occur, whether they are retryable, or what the LLM should do next. E.g., search() with no matches returns 'empty result' but does not guide recovery.
feedback tool accepts unvalidated free-form strings. No length limits, format constraints, or validation. LLMs could submit excessively long or malformed feedback.
search() limit parameter has no maximum constraint in schema (maximum: null). Unbounded numeric parameters let LLMs request thousands of passages, wasting context and tokens.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 67 | 2026-07-28+ | v2 |
Parameter descriptions are minimal. 'id' in fetch is described as 'The page ID, as returned by list_pages or search' but does not explain format, length, or character restrictions. LLMs cannot validate inputs.