Loading ToolBench
Offline MCP Server for local Qt 4.8, Qt 5, and Qt 6 documentation
Two well-named tools with clear, actionable descriptions and complete input schemas. Both tools have solid parameter documentation and meaningful output structures. Naming follows verb-noun convention (read_*, search_*). Descriptions are concise and explain purpose, parameters, and return value. Schemas include all expected types and field descriptions. However, error handling lacks recovery guidance (no suggestions for next steps on failure), and output structure documentation is implicit rather than explicitly formalized. Tool annotations (readOnlyHint, destructiveHint) are absent. No pagination metadata despite search returning multiple results, search_documentation returns 'results array' but no documented limit enforcement or next_cursor mechanism visible in signature.
Fetch a page from the active local Qt documentation set and return Markdown. Args: path: Root-relative Markdown path (for example, 'qtcore/qobject.md') fragment: Optional HTML fragment (e.g., '#details') section_only: If True with fragment, return only that section start_index: Character offset to start from (for pagination) max_length: Maximum characters to return (defaults to configured limit) Returns: Dictionary with title, path, markdown, links, and pagination info
Search the active local Qt documentation set for relevant pages. Args: query: Search terms (FTS5 query syntax supported) limit: Maximum number of results to return (default: 10, max: 50) scope: Search scope - 'all', 'api', or 'guides' (currently 'all' only) Returns: Dictionary with results array containing title, path, score, and context snippet
Error responses lack recovery guidance. ToolError exceptions are raised but source does not show next-step suggestions (e.g., 'Try a different query term' or 'Check path format with search_documentation'). LLMs cannot self-correct without actionable error messages.
search_documentation accepts 'limit' parameter (default 10, max 50) but tool description does not explicitly state pagination behavior or document how to fetch next page. For a search tool, pagination support is missing, no next_cursor or offset/page parameters visible despite results being paginated.
Tool annotations missing. Both tools are read-only (no state mutation), but readOnlyHint is not declared in fastmcp registration. This prevents clients from optimizing caching/batching and makes tool safety classification opaque.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | A | 80 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 67 | - | v1 |
Output schema for search_documentation is inferred from description ('results array containing title, path, score, and context snippet') but not formally documented in code. LLM cannot verify expected fields in responses. read_documentation output includes 'content_info' pagination object that is conditionally present, callers cannot reliably detect it.
No concrete examples or constraints on 'path' parameter format. Description says 'Root-relative Markdown path (for example, qtcore/qobject.md)' but does not specify allowed characters, max length, or what happens with invalid paths. LLM must infer format from one example.
'scope' parameter in search_documentation accepts 'all', 'api', or 'guides' but description notes 'currently all only'. This is misleading, if only 'all' works, the parameter should be removed or hidden. Documenting unimplemented features confuses LLMs.