Loading ToolBench
Model Context Protocol (MCP) server for Apple Books
The server has 8 well-named tools with reasonable descriptions and clear risk classifications. Naming follows verb_noun conventions (list_, get_, describe_, search_, create_, rename_, delete_, add_). However, critical gaps exist: (1) Input schemas are partially visible but incomplete, only the limit/collection_id/title parameters shown; (2) parameter descriptions lack detail on valid value ranges and formats; (3) output schemas are not documented, we see TextContent returns but no structured field documentation; (4) error handling is present but lacks recovery guidance for LLMs; (5) no tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk patterns. The descriptions are good (100-150 chars) and explain the purpose and when to use each tool, but they do not document return structure or downstream tool chaining. Overall, definitions are better than average for community servers but fall short of production readiness due to missing schema documentation and lack of tool annotations.
Add a book to a collection (user-created collections and "Want to Read"). Idempotent. Requires write access and Books to be quit.
Create a new collection in the user's Apple Books library. Requires write access and Books to be quit; a backup is taken automatically.
Delete a user-created collection (built-in collections are refused). The books inside are NOT deleted — only the collection. Requires write access and Books to be quit.
Describe a specific collection in detail — title, details text, and the books contained in it.
List the books in a collection as lean rows: ``[id] title by author``. Descriptions are intentionally omitted — collections with many books would otherwise emit tens of thousands of chars of marketing blurb. Use ``describe_book(id)`` for details on any specific book.
List all collections in my Apple Books library. Output is one row per collection: ``[id] title``. Use ``describe_collection(id)`` for details or ``get_collection_books(id)`` to list its books.
Output schemas are not documented. Tools return TextContent but no structured field documentation tells LLMs what to expect or what data is available for downstream tool calls. For example, list_all_collections returns formatted rows but does not document the structure or what IDs/fields are returned.
Tool annotations are missing. All 8 tools have explicit Risk classifications (READ_ONLY, WRITE, DESTRUCTIVE) but these are not expressed as MCP tool annotations (readOnlyHint, destructiveHint, idempotentHint). This prevents MCP clients from making safety-aware decisions about tool execution.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 11 | - | v1 |
Rename a user-created collection (built-in collections are refused). Requires write access and Books to be quit.
Search for collections by title (substring match). Output is one row per match: ``[id] title``.
Parameter descriptions lack constraint details. For example, 'limit' in list_all_collections has no minimum/maximum bounds, 'title' in search_collections_by_title does not specify case-sensitivity or substring matching behavior, and 'collection_id'/'book_id' types are inconsistent (string vs integer across tools).
Error handling is present but lacks recovery guidance for LLMs. For example, 'No collection found with id {collection_id}' does not suggest that the LLM call list_all_collections or search_collections_by_title to discover valid IDs. Write tools block while Books is open but the error message does not guide the LLM on whether to retry or ask the user to quit.
Type inconsistency for collection_id and book_id parameters: some tools accept collection_id as string (get_collection_books, describe_collection, search_collections_by_title → returns string IDs), but rename_collection and delete_collection expect integer IDs. This forces LLMs to reason about type coercion or maintain separate ID representations.
Idempotency is documented for add_book_to_collection but not for other write tools. create_collection, rename_collection, and delete_collection do not state whether they are idempotent or what happens if called twice with the same arguments. This affects LLM retry logic.