Loading ToolBench
Pure Rust multi-format eBook engine with MCP server support for EPUB 2/3, MOBI, AZW3, KFX, FB2, LIT, CBZ, PDF, ODT, DOCX, RTF, TXT, MD formats featuring Readium CFI/LCP, SpeechSynthesis TTS sync, CJK vertical/RTL reflow, EPUB3 optimizer, AI RAG BM25 chunking, zero-copy search, Zstd caching, and native MCP server
This server has significant definition quality gaps. While 7 tools are registered with names and basic descriptions, most lack proper schema documentation, parameter descriptions, and output specifications. Tool names follow verb_noun pattern adequately (book_load, book_parse, book_search, book_convert, book_rag_chunks, book_locations, sample_epub_generate), but tool descriptions, while present, are too brief (15-120 chars for most) and lack context about when to use each tool instead of similar ones. Most critically, input parameter descriptions are minimal or absent, 'Filesystem path to eBook file' appears verbatim for 5 tools without distinguishing them or explaining format expectations. No output schemas are documented anywhere in the source. The server provides read-only and write operations (book_convert, sample_epub_generate) but descriptions do not explicitly warn about state-changing behavior or when retries are safe. Error handling is not visible in the tool definitions themselves.
Convert eBook between formats: EPUB, KFX, or JSON (RAG chunks)
Load and parse an eBook file from filesystem path supporting EPUB 2/3, MOBI, AZW3, KFX, FB2, LIT, CBZ, PDF, ODT, DOCX, RTF, TXT, MD formats
Generate and retrieve location markers for an eBook for use with Readium CFI
Parse eBook file and extract structural metadata including title, authors, table of contents, and spine items
Extract and export eBook content as RAG (Retrieval-Augmented Generation) chunks with BM25 semantic chunking
Search for text within an eBook, returning results with spine index, CFI location, and text snippets
Generate a built-in sample EPUB 3 file with reference content for testing
Missing output schema documentation. No tool defines what fields or structure it returns, forcing LLMs to guess at response shape and preventing correct downstream tool chaining. Example: book_search returns 'results with spine index, CFI location, and text snippets' but no structured schema is visible.
Insufficient parameter descriptions. Five tools (book_load, book_parse, book_search, book_locations, sample_epub_generate) reuse or simplify the description 'Filesystem path to eBook file' without explaining supported formats, path requirements, or distinguishing use cases. Parameter 'query' in book_search and 'max_tokens' in book_rag_chunks have minimal guidance on expected range or format.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 39 | 2026-07-28+ | v2 |
Tool descriptions too brief (15-120 chars) and lack context. Rule baseline: 10 - 1024 chars, but average A+ tools are 50 - 200 chars. Descriptions like 'Load and parse an eBook file from filesystem path supporting EPUB 2/3, MOBI, AZW3, KFX, FB2, LIT, CBZ, PDF, ODT, DOCX, RTF, TXT, MD formats' (113 chars) mention formats but not when this tool is preferred over book_parse, or what the output looks like.
State-changing operations (book_convert, sample_epub_generate) lack explicit warnings. Descriptions do not state that these calls write files or that retries are idempotent. Agents cannot distinguish safe-to-retry vs destructive operations.
Input schema incompleteness. Visible schemas show basic type and description, but no examples of supported formats, valid ranges for numeric parameters (max_tokens defaults to 512 but has no documented max), or constraints on path formats or encoding.
book_convert allows multiple output formats (.epub, .kfx, .json) but no enum constraint is documented. LLMs may pass invalid extensions or formats not actually supported.
No error handling guidance visible in tool definitions. If a path is invalid, an unsupported format is passed, or a conversion fails, what should the agent do? Can it retry? Should it ask the user? No recovery patterns are documented.