Loading ToolBench
An MCP server providing access to the Gentleman Programming Book with tools for reading chapters, searching content, and semantic search capabilities.
The server provides 7 well-named tools with consistent verb_noun patterns (list_*, read_*, search_*, get_*, build_*, semantic_*). All tool descriptions are substantive (100-200+ chars) and explain the purpose, when to use, and any prerequisites. Input schemas are fully visible with proper JSON Schema types (string, number) and descriptions. However, output schemas are not documented in the code, tool handlers return results but the response structure is inferred rather than explicitly declared. Parameter validation rules are mentioned in descriptions (e.g., locale 'es'/'en') but not formalized as enums. Error handling is generic ('Error X: %v') without recovery guidance. No tool annotations (readOnlyHint/destructiveHint) despite 6 READ_ONLY and 1 WRITE tool. This is a solid middle-tier server with clear naming and descriptions but lacks the structured output documentation and error recovery patterns expected of production tools.
Build or rebuild the semantic search index. Required before using semantic_search. Takes a few minutes.
Get the complete table of contents for the book, including all chapters and their sections.
List all chapters in the Gentleman Programming Book. Returns chapter metadata including ID, name, order, and sections.
Read a specific chapter from the book. Can read the entire chapter or a specific section.
Search for content in the book using keywords. Returns relevant snippets with chapter and section information.
Search the book using semantic similarity (AI-powered). More accurate than keyword search. Requires OPENAI_API_KEY or Ollama running locally.
Output schemas not documented. Tool handlers (handleListChapters, handleReadChapter, etc.) return mcp.CallToolResult but the response structure (fields, types, pagination) is not declared in code. LLMs cannot plan downstream calls or extract data reliably without knowing what fields to expect.
Parameters with constrained values (locale: 'es' or 'en') are documented as strings with description 'Language locale: ...' but NOT declared as enums in schema. This invites LLMs to pass arbitrary locale values (e.g., 'fr', 'pt') that will fail at runtime. Should use JSON Schema enum constraint.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 31 | - | v1 |
Check the status of the semantic search engine (availability, index status, chunk count).
No tool annotations (readOnlyHint/destructiveHint/idempotentHint) despite clear READ_ONLY and WRITE classifications visible in the data. The server marks tools in metadata but does not use MCP 2026-07-28 tool annotations feature to communicate safety properties to the LLM.
Error responses are generic. Code shows 'fmt.Sprintf("Error listing chapters: %v", err)', this tells the LLM nothing actionable. No recovery guidance (e.g., 'Book path not found, check BOOK_PATH env var'), no categorization (retryable vs fatal), no suggested next steps.
semantic_search and build_semantic_index depend on external services (OpenAI API / Ollama) but no timeout or graceful degradation is visible. If these services hang, the tool blocks indefinitely. No partial-result fallback if enrichment fails.