Loading ToolBench
MCP server for accessing Calibre library metadata and EPUB content
calibre-mcp provides 5 well-named, action-oriented tools (search_books, get_book, get_epub_chapters, get_epub_chapter_content, search_epub_content) with complete input schemas and reasonable descriptions. Naming is clear and verb-driven (search_, get_). However, several definition quality gaps prevent a higher score: (1) descriptions are terse (50-80 chars average), lacking context on WHEN to use each tool or HOW they relate; (2) parameter descriptions are minimal or absent for optional pagination parameters; (3) no output schema documentation is provided in the visible code, while JSON type hints exist in Go structs (searchBooksOutput, getEPUBChaptersOutput), there is no inline documentation of response fields, field types, or what an LLM should expect to receive; (4) no error handling guidance, errors return raw text without recovery hints (line: 'Text: err.Error()'); (5) no response field naming conventions enforced (e.g., search_books returns 'results' with 'Books' and 'TotalNum' fields, but these are not documented); (6) pagination is supported (limit, offset) but the response does not clearly document what 'TotalNum' means or how the LLM should interpret it for multi-page traversal. The server is functional for basic lookups but lacks the depth of documentation and error handling expected of production tools.
Retrieve detailed information about a specific book by its ID from the Calibre library
Get the text content of a specific chapter in an EPUB book from the Calibre library
Get the list of chapters in an EPUB book from the Calibre library by its ID
Search for books in the Calibre library by title, author, tags, or other metadata. Returns a list of matching books with basic information. Supports limit and offset for fast pagination through results.
Search for text within an EPUB book in the Calibre library
Missing output schema documentation. While Go struct types exist (searchBooksOutput, getEPUBChaptersOutput, getEPUBChapterContentOutput, searchEPUBContentOutput), the tool definitions in mcp.go do not expose field names, types, or descriptions to the LLM. An LLM cannot reason about response structure without explicit documentation.
Tool descriptions lack actionable context. Descriptions are 50 - 80 characters and do not explain WHEN to use each tool vs alternatives, what the LLM can expect in the response, or prerequisites (e.g., 'get_epub_chapters requires a valid book_id from search_books'). LLMs need 100 - 200 char descriptions with context and use-case hints.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Parameter descriptions are minimal or missing. Optional pagination parameters (limit, offset) have very brief descriptions ('Maximum number of results to return (optional)', 'Number of results to skip for pagination (optional)'). These do not specify ranges, defaults, or constraints (e.g., 'limit: 1 - 100, default 20'). Query parameters lack examples of valid search syntax.
No error recovery guidance. Error responses are raw text ('Text: err.Error()') with no hints for the LLM on what to do next. Example: if search_books finds no books, should the LLM retry with a different query, use get_book directly, or escalate to the user? No guidance is provided.
Pagination response not self-documenting. search_books and search_epub_content return 'TotalNum' in the response but do not document what this field means, how the LLM should interpret it, or whether there is a next_cursor or next_page indicator. This breaks pagination composition for multi-page traversal.
No result-limiting guidance or cap documentation. The tools do not document a maximum result size or implicit limit. If a user searches for a common term in a large library, how many results can the LLM expect? Without explicit documentation, the LLM risks context window exhaustion.