MCP server for comprehensive book library management, providing tools for searching, reading, analyzing, and discovering content across a collection of books with semantic search, analytics, and quality auditing capabilities
This server has 25 tools with mixed quality. Most tools have descriptions, but they vary significantly in clarity and LLM-optimization. Parameter schemas are present but inconsistently detailed. The audit_chapter_quality tool has an excellent description (156 chars, very specific about what it audits). However, many tools like `approve`, `reject`, `rollback` lack detailed parameter documentation for nuanced behavior (e.g., what happens on retry, what actor means). Several tools like `batch_approve` and `batch_reject` have good descriptions but their preview-vs-execute pattern is underdocumented. Output schemas are not explicitly documented in the source, we can infer some structure from descriptions but cannot verify response field definitions. Error handling and recovery guidance are largely absent. The tool names follow verb_noun convention well (approve, reject, search, list), but several operations expose agent actors (approval tracking) which is good for audit but raises questions about identity validation. Overall, this is a functional but unpolished toolkit lacking the rigor needed for confident production use.
Audit chapter quality across the library or for a specific book Analyzes chapter data and flags issues: - Over-fragmentation: too many tiny chapters (front matter, appendices split out) - Under-fragmentation: too few massive chapters (chapter detection failures) - Title quality: generic names, PDF artifacts, non-chapter content - EPUB TOC mismatch: DB chapter count vs original EPUB table of contents
Find chapters covering similar topics across different books Identifies potential duplicate or overlapping coverage by comparing chapter embeddings across the library. Useful for: - Finding alternative explanations of the same concept - Identifying redundant content - Cross-referencing perspectives from different authors
Find related content across all books based on a chapter or text snippet Discovers conceptually similar content from OTHER books, enabling cross-referencing and finding alternative explanations.
Get detailed information about a specific book
Get the content of a specific chapter. For large chapters that have been split into sections, this returns an index listing all sections. Use get_section() to read individual sections.
Get comprehensive library statistics and analytics Provides deep insights into your library including: - Word counts by topic - Author distribution - Book size distribution - Embedding coverage - Reading progress summary
Output schemas not documented. Tools return data (e.g., list_books, hybrid_search) but the response field structure is not explicit in source. LLMs cannot plan downstream tool chains without knowing what fields to extract.
Insufficient parameter documentation for state-changing tools. approve, reject, and rollback accept 'actor' but do not explain: is this required? What are valid values? What if omitted? The description 'Who is approving' is vague, does it validate against a list of known actors, or accept free-form strings?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 10 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 50 | - | v1 |
Get the complete table of contents for a book
Get comprehensive coverage of a topic across all books Returns every chapter that covers the topic, ranked by relevance/depth. Useful for understanding how well a topic is covered in your library.
List all books in the library with their metadata
Missing error handling and recovery guidance. Tools like batch_approve, batch_reject, process, and reingest do not document what errors can occur, whether they are retryable, or what the LLM should do next. A 'dry_run failed' error gives no guidance.
Irreversible operations lack confirmation/dry-run pattern. rollback modifies the library state irreversibly, but there is no confirm_before_execute or dry_run mechanism documented. Agents could accidentally rollback approved books.
Autonomy mode tools (set_autonomy, escape_hatch) lack detail on mode semantics and constraints. What does 'confident' mode authorize that 'supervised' does not? Can escape_hatch always be called, or are there restrictions? How do these modes interact with batch operations?
health and stuck tools return bare lists without pagination. If the library has 10,000 stuck pipelines, health and stuck will return all of them, blowing the context window. No limit or page parameters are documented.
Search tools (hybrid_search, semantic_search) do not document ranking or confidence scores in results. If hybrid_search returns 10 chapters, how does the agent know which are most relevant? No 'confidence', 'score', or 'relevance' field is mentioned.
Batch operation preview-vs-execute pattern is underdocumented. batch_approve and batch_reject have execute: boolean, but what does a preview response look like? Does it include a list of affected books? Costs? The LLM cannot reason about preview results without knowing the schema.
No documented permission/scope model. Tools like rollback, escape_hatch, and set_autonomy are high-stakes operations but no description states what agent/user must have what permissions to call them. No scope declarations (read:library, write:library, admin:autonomy).
Generic tool names reduce clarity. health, stuck, status, and audit are used but do not clearly distinguish what they return. status operates on pipelines, but this is not obvious from the name, it could be system status, book status, or library status.