Loading ToolBench
MCP server for BookStack wiki — search, read, create, and manage documentation via AI assistants
BookStack MCP demonstrates strong fundamentals: all 16 tools have clear verb-noun naming, complete parameter schemas with types and descriptions, and well-structured output. Tool descriptions are generally informative (100-250 chars), exceeding the 10-char minimum. However, output schemas lack explicit documentation in the visible code, responses are constructed but not formally declared for LLM planning. Error handling guidance is sparse: most tools offer no recovery hints or categorization. The server includes helpful tool annotations (readOnlyHint, destructiveHint) and implements pagination across list operations. Resource integration is well-designed. Main gaps: (1) Output schema documentation for downstream tool chaining, (2) Error messages lack actionable recovery guidance, (3) No confirmation flow for destructive operations despite supporting delete_page.
Create a new page in a book or chapter.
Delete a page. Note: BookStack API deletes the page immediately without soft-delete.
Search for users by name or email, returning id + slug (used by user-filter fields in search_content).
Get a book.
List books with optional filter/sort.
Get a chapter.
List chapters with optional filter/sort.
Output schemas not documented in tool descriptions. Tools construct responses (e.g., books return {data, meta}, pages return {content, content_next_offset, metadata}) but LLMs cannot see expected return structure. This breaks downstream tool chaining and forces agents to guess which fields are available.
Error handling provides no recovery guidance. Tools lack descriptions of failure modes (e.g., 'User not found; try find_users() with a partial name'). Agents receiving errors cannot determine next steps.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 79 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Get a page. Returns one format (default markdown); use offset/limit + content_next_offset to paginate large pages.
Get attachments on a page.
List pages with previews.
List recently created/updated content, optionally scoped to recent N days.
Get a shelf with its books and tags.
List shelves with books and tags.
Search BookStack content. Supports advanced syntax like {type:page} or {book_id:5}. {created_by:X}/{updated_by:X}/{owned_by:X} take a user slug or 'me' — use find_users to resolve names to slugs.
Search BookStack pages, optionally within a book. Same user-ID caveat as search_content.
Update an existing page.
delete_page lacks confirmation or dry-run flow despite being destructive (permanent, no soft-delete per tool description). Agents may accidentally delete pages; a confirmation request pattern would prevent catastrophic errors.
Parameter descriptions for 'filter' objects are vague ('Optional filter object'). LLMs cannot infer valid filter keys, operators, or syntax. Should enumerate expected filter structure or reference BookStack API documentation inline.
search_content tool description mentions advanced syntax ('{type:page}', '{book_id:5}') but parameter schema defines 'type' as an enum. This mismatch creates ambiguity: can LLMs pass 'type' as parameter or must they embed it in 'query' string? Documentation should clarify query syntax vs. parameter usage.