calibreweb-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.2
Disambiguation4/5
Tools are largely distinct: search_books handles query-based search, list_books handles predefined views, list_shelves and get_shelf_books deal with shelves, get_stats provides counts, and get_cover retrieves covers. There is some overlap between search_books and list_books as both return book entries, but the descriptions clearly distinguish their use cases.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern (e.g., search_books, list_books, get_cover). No mixing of styles, making the naming predictable and easy to reason about.
Tool Count5/5
With 6 tools, the server is well-scoped for a Calibre-Web interface. It provides essential operations without being too sparse or overly numerous, striking a good balance.
Completeness3/5
The tool surface covers searching, listing, shelves, stats, and cover retrieval, but lacks direct retrieval of a single book by ID and any write operations (add, edit, delete). This limits the completeness for full library management, though reading operations are reasonably covered.
Average 4.2/5 across 6 of 6 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- Last stable release on August 18, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond the readOnlyHint annotation by disclosing that isPublic is only reliable on English-locale instances due to a localization quirk. This is a useful behavioral trait. The annotation already indicates the tool is read-only, so the description focuses on data quality—a good complement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loads the core purpose. The second sentence adds a usage hint and a behavioral note without unnecessary verbosity. It is structured well for an AI agent, though a bullet point or clearer separation could slightly improve scanability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description mentions the returned id and the isPublic field, but does not describe the full structure of shelf objects (e.g., name, title). The pagination detail is only in the schema. For a simple list tool with one optional parameter, the description covers the key behavioral uniqueness but lacks full return value documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter (offset), including its own description. The tool description does not add any additional meaning or context about the offset parameter beyond what the schema provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: it lists public and private shelves visible to the configured user. It also hints at downstream usage (get_shelf_books) and a locale-specific behavior, but does not explicitly distinguish this tool from sibling list tools like list_books, which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies using the returned id with get_shelf_books, but it does not provide explicit guidance on when to use this tool versus siblings (e.g., list_books, search_books) or when not to use it. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is clear. The description adds explicit behavioral context by listing exactly what counts are returned (books, authors, categories, series). No hidden behaviors need disclosure for a simple stateless read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 15 words, front-loaded with the purpose. Every word is necessary, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema. The description explains what is returned but does not specify the structure (e.g., object fields). For a stats tool, the content is clear enough, but an explicit structure would be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage (trivially), the description does not need to add parameter meaning. The baseline of 4 is appropriate as per guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Returns' and clearly identifies the resource: total number of books, authors, categories (tags), and series. It distinguishes itself from sibling tools like search_books and list_books by providing aggregate counts rather than individual items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 does not state any prerequisites, exclusions, or context for use. The agent must infer from the tool name and siblings that this is for overall statistics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond the readOnlyHint annotation by revealing that the returned data includes per-format download URLs and a cover URL, and that the books are in the shelf's own order. It also notes that the cover image itself should be fetched via get_cover, preventing the agent from expecting the tool to return the image directly. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that are front-loaded with the primary action and contain only essential information. Every sentence earns its place by clarifying purpose, prerequisites, or output content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description explains the key elements of the returned data (download URLs, cover URL) and the ordering. It is sufficient for a simple list tool with two parameters. A minor improvement would be to hint at additional fields like titles or authors, but the current level is still adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters have clear descriptions). The description reinforces the source of shelf_id ('from list_shelves') but does not add new semantic details for offset beyond what the schema already provides. The description adequately complements the schema without repeating it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('lists the books on a shelf'), specifies the ordering ('in the shelf’s own order'), and provides context on how to obtain the shelf_id ('Shelf ids come from list_shelves'). It also distinguishes the output content from the sibling get_cover tool, making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent that shelf_ids must be obtained from list_shelves, establishing a clear prerequisite. It implies appropriate usage for retrieving books on a specific shelf with download URLs, though it does not explicitly exclude use cases best served by siblings like search_books or list_books.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description reveals that the tool returns an image, that images over 1 MB are refused due to context window protection, and that the coverUrl is an alternative. This adds useful behavioral constraints without contradicting the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the core purpose, and each sentence provides essential information with no redundant text. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the parameter is fully covered and the tool is simple, the description is vague about the exact output format (e.g., raw image bytes, MIME type) and error behavior for missing covers or invalid IDs. Without an output schema, more detail on the return value would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a descriptive parameter comment. The description adds value by stating that book IDs originate from other tools and that null IDs indicate no cover, which is not present in the schema. This extra context enhances understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetches the cover of a book and returns it as an image,' using a specific verb and resource. It is distinct from sibling tools (search, list, stats) which perform different operations. The mention of where book IDs come from further clarifies the tool's role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: book IDs come from other tools, and for images over 1 MB, it advises using the coverUrl from the book entry instead. This effectively tells the agent when to use the tool and when to avoid it, though it does not name an alternative tool explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses several behavioral traits: page size is server-side, pagination uses nextOffset, and the discover view is random and not paginated. These details are not inferable from the schema or annotations, adding significant value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no excess. The first sentence front-loads the main purpose and enumerates views, the second explains pagination, and the third clarifies a special case (discover). Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description provides enough context for a list operation: views, pagination mechanism, and a special exception. It could be improved by mentioning the expected structure of returned book data, but for a domain-specific tool it is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema has 100% coverage with descriptions, the description enriches parameter meaning by explaining what each view represents (e.g., 'recently added, default'), restricting the letter parameter to the 'all' view, and clarifying that discover is unpaginated. This goes beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Lists books from one of the Calibre-Web views', specifying the resource (books) and action (list) with concrete examples (new, hot, rated, etc.). This differentiates it from siblings like search_books (search) and list_shelves (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the different views and pagination behavior but does not provide explicit guidance on when to use this tool versus alternatives such as search_books. It lacks when-not or comparative context, leaving the agent to infer usage based on view names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral traits beyond the readOnly annotation: it explains that Calibre-Web returns all matches in a single response, that broad queries are truncated client-side, and that totalFound indicates the real count. It also mentions that entries include download URLs and a cover URL, and directs to get_cover for the cover image. This gives the agent a full picture of the tool's behavior and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: the first states purpose, the second explains truncation behavior, the third describes response content and links to a sibling tool. No wasted words, and the most critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with two parameters and a readOnly annotation, the description covers purpose, searchable fields, truncation behavior, totalFound, and response content. It does not mention sorting or order, which could be relevant for pagination. However, given the absence of an output schema and the complexity of the tool, the description is nearly complete and provides sufficient context for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions, so baseline is 3. The description adds value by specifying which fields the query parameter applies to (title, author, series, publisher, tags), which is not in the schema's 'Search term' description. For the limit parameter, the description adds no additional meaning beyond the schema's min/max/default. Overall, the description provides meaningful context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb+resource: 'Searches the library by title, author, series, publisher and tags.' This specifies exactly what the tool does and which fields it searches, distinguishing it from siblings like list_books (which likely lists all books) and get_cover (which fetches a single cover image).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching by various fields, and the context of truncation and totalFound helps set expectations. However, it does not explicitly state when to use this tool versus alternatives like list_books or get_shelf_books, nor does it provide exclusion criteria (e.g., 'Use this for ad-hoc queries; use list_books for browsing all books'). The guidance is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![calibreweb-mcp MCP server](https://glama.ai/mcp/servers/ni-c/calibreweb-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ni-c/calibreweb-mcp)

Score Badge

Copy to your README.md:

[![calibreweb-mcp MCP server](https://glama.ai/mcp/servers/ni-c/calibreweb-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ni-c/calibreweb-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ni-c/calibreweb-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server