Summary: You can use this BookStack MCP server to search, browse, export, and monitor wiki content through a read-only tool schema.
Search content and pages, including BookStack advanced search syntax.
List and read books, pages, chapters, shelves, and attachments with filtering and pagination.
Export pages, books, and chapters as HTML, Markdown, plaintext, PDF, or ZIP.
Retrieve recent changes and inspect server capabilities.
The provided schema is read-only; the README notes optional write tools can be enabled separately.
Provides comprehensive tools for managing BookStack content including searching across books, pages, and chapters, creating and updating pages, retrieving detailed information about books and chapters, and exporting pages in various formats (HTML, PDF, Markdown, Plain text).
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@BookStack MCP Server search for pages about API documentation"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Connect an AI assistant to your BookStack wiki through the Model Context Protocol. Search documentation, answer questions with source links, summarize books, and optionally maintain pages and other content.
Read-only by default. The server exposes 21 read tools and, when enabled, 22 write tools. BookStack permissions still apply to every API request. Use a dedicated account with access to only the content the assistant should see.
In BookStack, open your profile's API Tokens section and create a token for a dedicated user. Its role needs Access System API and permission to view the relevant books/pages. Copy both the Token ID and Token Secret; they are separate values.
Also grant Export Content to read WYSIWYG pages as Markdown: BookStack stores no Markdown source for those pages, so the server uses its export endpoint as a fallback. User lookup and recycle-bin tools require additional administrative permissions; ordinary reading does not.
Your setup | Start here |
Claude Desktop | Install the |
Claude Code | |
Codex or Gemini CLI | |
Cursor | |
Any local MCP client | Use the stdio configuration below |
LibreChat / shared Docker service | |
Remote connector with Microsoft sign-in |
For npm-based installations, use a supported Node.js LTS release (Node 24 recommended; CI also uses Node 22). The published package declares node >=18; that minimum is not a recommendation to run an unsupported Node release. Docker includes its own Node runtime.
Add this entry to your client's MCP configuration, replacing the example values:
{
"mcpServers": {
"bookstack": {
"command": "npx",
"args": ["-y", "bookstack-mcp@5.7.1"],
"env": {
"BOOKSTACK_BASE_URL": "https://wiki.example.com",
"BOOKSTACK_TOKEN_ID": "your-token-id",
"BOOKSTACK_TOKEN_SECRET": "your-token-secret"
}
}
}
}This configuration contains credentials: keep it private and outside version control. It pins the reviewed release 5.7.1; update the exact version deliberately when upgrading. The repository's native plugin/extension launchers also pin a matching npm version.
Restart the client, check that BookStack tools appear, and ask: “List the books I can access, then find our onboarding guide and link to it.” This verifies MCP connectivity and BookStack access. Starting npx without the required settings fails; starting it in a terminal with settings waits for MCP input rather than opening a web interface.
Related MCP server: BookStack MCP Server
The client guide covers Claude Desktop, Claude Code, Codex, Cursor, Gemini CLI, and LibreChat, including per-user HTTP credential headers. The configuration reference documents all server settings and the different npm and Docker defaults.
For development from a checkout, see CONTRIBUTING.md. The server does not automatically read .env; use the client's env settings, export variables, or explicitly pass Node's --env-file option.
Task | Tools and behavior |
Find information |
|
Read the wiki | List/detail tools for books, chapters, pages, shelves, attachments, and comments; |
Export |
|
Maintain content | Optional create/update/delete tools, gallery image uploads, and recycle-bin operations |
See the complete tool reference and recipes for all 43 tool names, pagination, tags, image policies, and version requirements. MCP tools/list on your connected server is authoritative for argument schemas and enabled tools.
To enable writes in non-OAuth mode, set BOOKSTACK_ENABLE_WRITE=true and use a BookStack token with the corresponding permissions. In OAuth mode, writes instead require the configured Entra role and a separate write-token pair. Entra users normally share those BookStack service accounts; sign-in does not automatically give each user their own BookStack identity or private content boundary.
For HTML/WYSIWYG pages, read get_page with format: "raw" and update using html. The rendered html view can remove editor attributes and resolve includes.
For Markdown pages, read format: "markdown" and update using markdown. Saving html clears the stored Markdown source.
Tags replace the entire tag list. Omit tags to preserve it, or send [] to clear it. Read the current list before changing individual tags.
Read all content chunks before replacing a large page. Worked examples show the workflow.
Clients with resource support can browse bookstack://book/{id} for book metadata and bookstack://page/{id} for Markdown and page metadata. Both templates provide ID completion through BookStack search.
Four MCP prompts guide read workflows: answer_from_wiki, find_pages, summarize_book, and recent_changes. Prompt arguments are documented alongside the tools. Client support for resources and prompts varies.
Use HTTPS, keep TLS verification enabled, and protect HTTP services with OAuth or a trusted internal network. HTTP without OAuth has no built-in caller authentication. Set an explicit allowed-host list when exposing a container; a host allowlist is not authentication.
HTTP image downloads require an allowed hostname, and local file uploads are disabled by default. Request bodies, request duration, and session counts are bounded. See deployment boundaries and the security policy, including private vulnerability reporting.
The privacy policy explains data flows, credentials, OAuth/Redis state, and logging. Your AI client and deployment operator may have additional policies. Use is governed by the terms and MIT license.
Browse the documentation index for installation, deployment, configuration, tool recipes, troubleshooting, contributions, releases, and HOL Guard. For a connection problem, start with the troubleshooting guide.
Design background: Why my BookStack MCP server starts read-only describes permission boundaries, shared-token rate limiting, and response-size decisions.
Export an entire book in various formats
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Book ID | |
| format | Yes | Export format |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Export') but doesn't mention whether this requires authentication, affects system state, has rate limits, or what the output looks like (e.g., file download vs. text return). This leaves significant gaps for a tool that likely generates files.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficient. It doesn't explain the export behavior (e.g., file generation, download mechanism, or content structure), which is critical given the complexity of exporting an entire book in multiple formats.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters (id and format with enum values). The description adds no additional parameter semantics beyond what's in the schema, such as explaining what 'zip' format includes or how book IDs are obtained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Export') and resource ('an entire book'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like export_chapter or export_page, which export smaller components rather than the entire book.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like export_chapter for partial exports or get_book for metadata retrieval. It mentions 'various formats' but doesn't specify which formats are best for different use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export a chapter in various formats
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Chapter ID | |
| format | Yes | Export format |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'various formats' but doesn't disclose behavioral traits like whether this is a read-only operation, if it requires authentication, rate limits, or what happens during export (e.g., file creation, download). The description is minimal and lacks critical context for a mutation-like tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action. However, it could be more informative without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that likely performs an export operation. It doesn't explain return values, error conditions, or behavioral aspects like side effects. For a tool with 2 parameters and potential complexity, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter documentation (id as Chapter ID, format as Export format with enum). The description adds no additional meaning beyond the schema, such as explaining format implications or id constraints. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Export a chapter in various formats' clearly states the action (export) and resource (chapter), but it's vague about scope and doesn't differentiate from siblings like export_book or export_page. It doesn't specify what 'export' entails (e.g., file generation, download link).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like export_book or export_page. It doesn't mention prerequisites (e.g., needing chapter access) or exclusions (e.g., not for attachments). Usage is implied by the name but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export a page in various formats (PDF/ZIP provide direct BookStack download URLs)
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Page ID | |
| format | Yes | Export format |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that PDF/ZIP formats 'provide direct BookStack download URLs', which adds useful context about output behavior. However, it lacks details on permissions, rate limits, side effects, or what happens with other formats. For a tool with no annotations, this is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It front-loads the core action ('Export a page in various formats') and adds a clarifying note about specific formats. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters with full schema coverage and no output schema, the description is adequate but has gaps. It covers the basic purpose and hints at format-specific behavior, but lacks details on permissions, error cases, or output structure. For a tool with no annotations and no output schema, it's minimally complete but could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters (id and format with enum). The description adds marginal value by noting 'PDF/ZIP provide direct BookStack download URLs', which hints at format-specific behavior but doesn't explain parameter semantics beyond the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Export' and resource 'a page', specifying it works with 'various formats'. It distinguishes from siblings like 'export_book' and 'export_chapter' by focusing on pages, but doesn't explicitly contrast with them. The purpose is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'export_book' or 'export_chapter' is provided. The description mentions 'PDF/ZIP provide direct BookStack download URLs', which hints at behavioral differences, but doesn't give explicit usage context or prerequisites. It's left to the agent to infer based on tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific attachment including download links
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Attachment ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions retrieving 'download links' but doesn't specify authentication needs, rate limits, error handling, or whether the operation is read-only (implied by 'Get' but not explicit). This leaves gaps for a tool that likely involves data access.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get details of a specific attachment') and adds a useful detail ('including download links') without any wasted words. It is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'details' include beyond download links, potential return formats, or error cases. For a tool with one parameter but no structured output info, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'id' documented as 'Attachment ID' with a numeric type and minimum value. The description adds no additional meaning beyond this, such as format examples or context about valid IDs, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('details of a specific attachment'), specifying it includes download links. It distinguishes from 'get_attachments' (plural) by focusing on a single attachment, but doesn't explicitly contrast with other sibling tools like export functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_attachments' for multiple attachments or export tools for downloading content. The description implies usage for retrieving details of a specific attachment but offers no context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List attachments (files and links) with filtering and sorting
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | Pagination offset | |
| count | No | Number of results to return | |
| sort | No | Sort field | |
| filter | No | Filter criteria |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks behavioral details. It doesn't disclose whether this is a read-only operation, potential rate limits, authentication requirements, or what happens with large result sets beyond the schema's pagination hints. The mention of 'filtering and sorting' is minimal and doesn't explain implementation constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It front-loads the core purpose ('List attachments') and succinctly adds key features ('files and links' and 'with filtering and sorting'). Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain return values, error conditions, or behavioral nuances like how filtering works (the 'filter' object has no schema). The context signals indicate complexity (nested objects, 100% schema coverage), but the description fails to compensate for missing structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema itself. The description adds marginal value by implying 'filtering and sorting' map to the 'filter' and 'sort' parameters, but doesn't provide additional semantics like filterable fields, sort options, or usage examples beyond what the schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('attachments'), specifying they include 'files and links'. It distinguishes from sibling 'get_attachment' (singular) by implying a collection operation. However, it doesn't explicitly differentiate from other list-like siblings like 'get_books' or 'get_chapters' beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'with filtering and sorting', which implies usage for refined queries, but provides no explicit guidance on when to use this tool versus alternatives like 'search_content' or 'get_recent_changes'. No prerequisites, exclusions, or comparative context are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific book
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Book ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Get detailed information' but doesn't disclose behavioral traits like whether this is a read-only operation, if it requires authentication, what format the information returns in, or any rate limits. This leaves significant gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized for a simple lookup tool and front-loads the core purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'detailed information' includes, how errors are handled, or any behavioral context. For a tool with siblings and potential complexity, this minimal description leaves too much undefined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the single 'id' parameter. The description adds no additional meaning beyond implying it's for a 'specific book', which the schema already covers with its 'Book ID' description. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'detailed information about a specific book', which is specific and actionable. However, it doesn't distinguish this tool from similar siblings like 'get_books' (plural) or 'get_chapter', leaving some ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_books', 'get_chapters', and 'search_content', there's no indication whether this is for single-book lookup, what context warrants its use, or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available books with advanced filtering and sorting
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | Pagination offset | |
| count | No | Number of results to return | |
| sort | No | Sort field (e.g., 'name', '-created_at', 'updated_at') | |
| filter | No | Filter criteria |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral disclosure. It mentions 'advanced filtering and sorting' but doesn't describe pagination behavior (implied by offset/count parameters), rate limits, authentication requirements, error conditions, or what 'available books' means (e.g., published vs. all).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence with zero wasted words. Front-loaded with core purpose ('List available books') followed by key capabilities. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no annotations and no output schema, the description is insufficient. It doesn't explain what constitutes 'available books', how results are structured, error handling, or practical usage patterns. The mention of 'advanced filtering' is vague without examples of filter criteria.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds marginal value by mentioning 'advanced filtering and sorting' which aligns with the 'filter' and 'sort' parameters, but doesn't provide additional semantic context beyond what's in the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('books') with additional context about capabilities ('advanced filtering and sorting'). It distinguishes from siblings like 'get_book' (singular) and 'search_content' (broader search), but doesn't explicitly differentiate from 'get_shelves' or other list-like tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'search_content' or 'get_shelves'. The description mentions 'advanced filtering and sorting' but doesn't specify when this is preferable to simpler list operations or broader searches available among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about available BookStack MCP capabilities and current configuration
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves information, implying it's a read-only operation, but doesn't clarify aspects like authentication requirements, rate limits, error handling, or what specific 'capabilities' and 'configuration' details are returned. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence: 'Get information about available BookStack MCP capabilities and current configuration.' It is front-loaded with the core purpose, has no redundant words, and efficiently conveys the essential information without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is minimally complete—it states what the tool does. However, without annotations or an output schema, it lacks details on behavioral traits (e.g., what 'capabilities' include) and return values. For a tool with zero parameters, this is adequate but leaves room for improvement in clarifying the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to explain parameters, as there are none. It appropriately focuses on the tool's purpose without unnecessary parameter details, earning a high score for this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get information about available BookStack MCP capabilities and current configuration.' It specifies the verb ('Get') and resource ('BookStack MCP capabilities and current configuration'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_books' or 'get_shelves', which focus on content retrieval rather than system capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for usage, or comparisons to sibling tools like 'get_books' or 'search_content'. Without such information, an agent might struggle to decide when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific chapter
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Chapter ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Get details' but doesn't specify what details are returned, if it's a read-only operation, error conditions, or performance traits. This is inadequate for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded and appropriately sized for a simple tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'details' include, return format, or error handling. For a tool that likely returns structured data, this leaves significant gaps in understanding its behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'id' documented as 'Chapter ID'. The description adds no additional meaning beyond this, such as format examples or constraints. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('details of a specific chapter'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_chapters' (plural) or 'get_page'—it's clear but lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a chapter ID) or compare to siblings like 'get_chapters' for listing chapters or 'get_page' for page details, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List chapters, optionally filtered by book
| Name | Required | Description | Default |
|---|---|---|---|
| book_id | No | Filter by book ID | |
| offset | No | Pagination offset | |
| count | No | Number of results to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose whether this is a read-only operation, pagination behavior (implied by offset/count but not explained), rate limits, authentication needs, or what the return format looks like (since no output schema exists).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and includes the key optional filtering feature. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with 3 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what 'chapters' means in this context, how results are ordered, what fields are returned, or error conditions. The agent must rely entirely on the schema for parameter details and guess at behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds minimal value by mentioning 'optionally filtered by book', which aligns with the book_id parameter but doesn't provide additional context beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'chapters', with optional filtering by book. It distinguishes from sibling tools like get_chapter (singular) and get_books, but doesn't explicitly differentiate from get_pages or search_content which might overlap in functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions optional filtering by book, but provides no guidance on when to use this tool versus alternatives like get_chapter (for a specific chapter), get_pages (for pages within chapters), or search_content (for more complex queries). No prerequisites, exclusions, or context for selection are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full content of a specific page
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Page ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool retrieves content but lacks details on permissions required, error handling (e.g., for invalid IDs), rate limits, or output format (e.g., text, HTML, metadata). This is inadequate for a tool that presumably interacts with a content system, leaving key operational traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get full content of a specific page') with zero wasted words. It avoids redundancy and is appropriately sized for a simple retrieval tool, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is incomplete. It fails to address behavioral aspects like authentication needs, error cases, or output structure, which are critical for reliable invocation. While concise, it doesn't provide enough context for an agent to use the tool effectively beyond basic parameter passing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'id' parameter documented as 'Page ID' with a numeric type and minimum value. The description adds no additional parameter semantics beyond implying the ID identifies a 'specific page'. Since the schema fully covers the parameter, the baseline score of 3 applies, as the description doesn't enhance understanding of the parameter's use or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get full content') and resource ('of a specific page'), making the purpose immediately understandable. It distinguishes from siblings like 'get_pages' (plural) and 'search_pages' by specifying retrieval of a single page's full content. However, it doesn't explicitly differentiate from 'export_page' which might serve a similar purpose, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid page ID), exclusions (e.g., not for partial content), or comparisons to siblings like 'get_pages' for lists or 'export_page' for formatted exports. This leaves the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List pages with content previews, word counts, and contextual information
| Name | Required | Description | Default |
|---|---|---|---|
| book_id | No | Filter by book ID | |
| chapter_id | No | Filter by chapter ID | |
| offset | No | Pagination offset | |
| count | No | Number of results to return | |
| sort | No | Sort field | |
| filter | No | Additional filter criteria |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool returns 'content previews, word counts, and contextual information,' which hints at read-only behavior, but doesn't clarify pagination details (implied by offset/count parameters), rate limits, authentication needs, or error handling. For a list operation with multiple parameters, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. It avoids redundancy and wastes no words, though it could be slightly more structured by separating purpose from output details. Overall, it's appropriately concise for a list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, no annotations, no output schema), the description is minimally adequate. It states what the tool does but lacks details on usage context, behavioral traits, and output format. Without annotations or output schema, more guidance on return values and operational constraints would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema fully documents all 6 parameters. The description adds no specific parameter semantics beyond implying that results include 'content previews, word counts, and contextual information,' which relates to output rather than input. This meets the baseline for high schema coverage but doesn't enhance understanding of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List pages with content previews, word counts, and contextual information.' It specifies the verb 'List' and resource 'pages,' and mentions the returned data attributes. However, it doesn't explicitly differentiate from sibling tools like 'get_page' (singular) or 'search_pages,' which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_page' (singular), 'search_pages,' and 'get_chapters,' there's no indication of whether this is for bulk listing, filtered queries, or general browsing. This lack of context makes it hard for an agent to choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recently updated content with contextual previews and change descriptions
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Filter by content type | all |
| limit | No | Number of recent items to return | |
| days | No | Number of days back to look for changes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks behavioral details. It doesn't disclose permissions needed, rate limits, pagination behavior, or what 'contextual previews' and 'change descriptions' entail. The description is vague about operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is incomplete. It doesn't explain return values, error conditions, or behavioral constraints, leaving significant gaps for an AI agent to understand how to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters. The description adds no parameter-specific information beyond implying filtering by content type and recency, which is already covered by the schema. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('recently updated content') with additional features ('contextual previews and change descriptions'). It distinguishes from most siblings by focusing on recent changes rather than specific content retrieval or exports, though it doesn't explicitly differentiate from search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like search_content or get_pages. The description implies it's for recent changes but doesn't specify scenarios, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific book shelf including all books
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Shelf ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions retrieving details and books, but fails to specify if this is a read-only operation, requires authentication, has rate limits, or what the return format looks like (e.g., JSON structure, error handling). This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse quickly, which is ideal for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'details' include beyond books, how the data is structured, or any behavioral aspects like permissions or errors. For a tool that retrieves data with one parameter, more context is needed to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'id' parameter clearly documented as 'Shelf ID' with a numeric type and minimum value. The description adds no additional semantic context beyond implying it's for a 'specific' shelf, which aligns with the schema but doesn't provide extra value like format examples or usage tips.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'details of a specific book shelf including all books', making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'get_shelves' (plural) or 'get_book', which might retrieve similar book-related data, leaving room for ambiguity in sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. For example, it doesn't clarify if this should be used instead of 'get_shelves' for a single shelf or how it relates to 'get_book' for individual book details, leaving the agent to infer usage from context without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available book shelves (collections) with filtering and sorting
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | Pagination offset | |
| count | No | Number of results to return | |
| sort | No | Sort field | |
| filter | No | Filter criteria |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'filtering and sorting' but doesn't elaborate on how these work, what the response format looks like, whether there are rate limits, or if authentication is required. This is inadequate for a tool with 4 parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, clearly stating the tool's purpose and key features without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, no output schema, and no annotations), the description is incomplete. It lacks details on behavioral traits, response format, usage context relative to siblings, and doesn't compensate for the absence of annotations or output schema. This is a significant gap for a tool that likely returns structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all parameters (offset, count, sort, filter) with descriptions. The description adds marginal value by implying filtering and sorting capabilities, but doesn't provide additional syntax, format details, or examples beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('List') and resource ('available book shelves (collections)'), and mentions capabilities ('filtering and sorting'). However, it doesn't explicitly distinguish this tool from its sibling 'get_shelf' (singular) or other list-like tools like 'get_books' or 'get_chapters', which would be needed for a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_shelf' (for single shelf retrieval), 'search_content', or 'search_pages' (which might overlap in functionality), nor does it specify prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search across BookStack content with contextual previews and location info
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query. Use BookStack advanced search syntax like {type:page} or {book_id:5} | |
| type | No | Filter by content type | |
| count | No | Number of results to return (max 500) | |
| offset | No | Number of results to skip for pagination |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions 'contextual previews and location info' as output characteristics, it doesn't address important behavioral aspects like authentication requirements, rate limits, error conditions, pagination behavior beyond the offset parameter, or what happens with empty results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core functionality without unnecessary words. It's appropriately sized and front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 4 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the search results look like (beyond mentioning 'previews and location info'), doesn't address search limitations or performance characteristics, and doesn't help differentiate from sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description doesn't add any parameter-specific information beyond what's already in the schema descriptions, so it doesn't enhance parameter understanding beyond the structured documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as searching across BookStack content with contextual previews and location info, which is a specific verb+resource combination. However, it doesn't explicitly differentiate from its sibling 'search_pages' tool, which appears to be a more specific search variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'search_pages' or other get_* tools. There's no mention of prerequisites, limitations, or comparative use cases that would help an agent choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search specifically for pages with optional book filtering
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query for pages | |
| book_id | No | Filter results to pages within a specific book | |
| count | No | Number of results to return | |
| offset | No | Pagination offset |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic action ('search') without mentioning permissions, rate limits, pagination behavior (implied by 'offset' but not explained), or what happens on errors. For a search tool with 4 parameters and no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and includes a key constraint ('optional book filtering'), making it easy to parse quickly. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no output schema, no annotations), the description is incomplete. It lacks details on return values, error handling, and behavioral traits. While the schema covers parameters well, the overall context for safe and effective use is insufficient, especially for a search operation that might involve pagination and filtering.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema by implying that 'book_id' is for filtering, but it doesn't provide additional context like search syntax or result ordering. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search specifically for pages with optional book filtering'. It specifies the verb ('search'), resource ('pages'), and scope ('with optional book filtering'), making the intent unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'search_content' or 'get_pages', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance: it mentions 'optional book filtering' but doesn't explain when to use this tool versus alternatives like 'search_content' or 'get_pages'. There's no context about prerequisites, exclusions, or specific scenarios where this tool is preferred, leaving the agent with insufficient direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v2.1.1export_bookexport_chapterexport_pageget_attachmentget_attachmentsget_bookget_booksget_capabilitiesget_chapterget_chaptersget_pageget_pagesget_recent_changesget_shelfget_shelvessearch_contentsearch_pagesScored across 17 tools
Most tools have clearly distinct purposes targeting specific resources like books, chapters, pages, attachments, and shelves, with clear action distinctions (get vs. list vs. export). However, search_content and search_pages have some overlap in purpose, as both handle search operations, which could cause minor confusion for an agent.
Tool names follow a highly consistent verb_noun pattern throughout, such as get_book, export_page, and search_content. All tools use snake_case with clear, descriptive verbs, making the set predictable and easy to navigate.
With 17 tools, the count is slightly high but reasonable for a content management system like BookStack, covering resources like books, chapters, pages, shelves, and attachments. It feels comprehensive without being overwhelming, though it borders on the heavier side.
The tool surface provides complete CRUD-like coverage for the BookStack domain, including retrieval (get/list), export, search, and management of attachments and recent changes. There are no obvious gaps, and agents can perform full lifecycle operations on all core resources.
Connect to your MediaWiki using simple credentials and manage content without OAuth. Search, read,…
Knowledge base MCP for AI agents on iknow.dev. Search, read, and maintain via OAuth.
Make your knowledge agent-ready. One MCP endpoint, 5 connectors, 3 search modes.
Access and search Branch's official API documentation directly within any AI agent or client.
