gutenberg-mcp-server
Server Details
MCP server for Project Gutenberg — 75,000+ public-domain ebooks with full plain-text retrieval.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.6/5 across 4 of 4 tools scored.
Each tool has a distinct purpose: browsing popular books, fetching metadata, retrieving plain text, and searching the catalog. No overlap.
All tools follow the consistent pattern 'gutenberg_verb_noun' (browse_popular, get_book, get_text, search_books).
Four tools is ideal for this domain: discovery (browse, search), metadata, and text retrieval.
Covers the full workflow: discovery, metadata, and content retrieval. No obvious gaps.
Available Tools
4 toolsgutenberg_browse_popularBrowse Popular Gutenberg BooksARead-onlyIdempotentInspect
Browse the most-downloaded Project Gutenberg books, ordered by popularity. Returns up to 32 titles with their Gutenberg IDs, authors, languages, and download counts. Optionally filter by language or topic. Use this as a discovery entry point — "what are the most popular classics in French?" — or as a heartbeat check that the catalog is reachable.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of books to return (1–32). Default 20 gives a useful overview without overwhelming context. | |
| topic | No | Filter by a subject or bookshelf keyword (case-insensitive phrase match). Example: "science fiction", "adventure", "detective". Applies on top of the language filter. | |
| languages | No | Restrict to books in these languages (two-character ISO 639-1 codes). Example: ["en"] for English only, ["de", "fr"] for German or French. Omit for all languages. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | Yes | The limit that was applied. |
| books | Yes | Top books by download count, most popular first. |
| shown | Yes | Number of books returned in this response. |
| truncated | Yes | True when the catalog held more matches than were returned. |
| totalInCatalog | Yes | Total books matching the filter in the full catalog (useful for context — "top 20 of 60,000"). |
| truncationCeiling | No | Download count of the least-popular book shown — omitted books have at most this many downloads. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds beyond annotations: describes returned fields (IDs, authors, languages, download counts), ordering by popularity, and limit maximum. Annotations already provide readOnlyHint, openWorldHint, idempotentHint; description supplements with specific output details.
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?
Efficient and front-loaded: purpose, return values, filters, and use cases in a few sentences. No redundant 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?
Fully covers what an agent needs: what it does, what it returns, filtering options, and use cases. Output schema exists, so return values are further documented. No gaps.
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 coverage is 100%, but description adds useful context: limit default gives 'useful overview', topic uses 'case-insensitive phrase match', languages require 'two-character ISO 639-1 codes' with examples. Adds value beyond schema.
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 browses the most-downloaded Gutenberg books ordered by popularity. It specifies the resource, action, and ordering, and distinguishes it from search/get siblings via phrases like 'discovery entry point'.
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?
Explicitly tells when to use: 'discovery entry point' and 'heartbeat check', with concrete example ('what are the most popular classics in French?'). Implicitly excludes searching for specific titles, which is covered by sibling gutenberg_search_books.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gutenberg_get_bookGet Gutenberg BookARead-onlyIdempotentInspect
Fetch complete metadata for a Project Gutenberg book by ID — title, authors (with birth/death years), translators, editors, subjects, bookshelves, languages, copyright status, and the full formats map with download URLs for each available format (plain text, HTML, EPUB, cover image, etc.). Use this before gutenberg_get_text to confirm a plain-text format is available and to get the direct download URL.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Project Gutenberg book ID. Visible in Gutenberg URLs (e.g., gutenberg.org/ebooks/1342) and returned by gutenberg_search_books and gutenberg_browse_popular. Example: 1342 for Pride and Prejudice, 2600 for War and Peace. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | Gutenberg ID. |
| title | Yes | Book title. |
| authors | Yes | Primary author(s). |
| editors | Yes | Editors, if any. |
| formats | Yes | Map of MIME type to download URL. Key types: "text/plain; charset=utf-8" (preferred for gutenberg_get_text), "text/html", "application/epub+zip", "image/jpeg" (cover). Not every format is present for every book. |
| summary | Yes | Auto-generated summary of the work, when available. Absent on many older records. |
| subjects | Yes | Library of Congress subject headings. |
| copyright | Yes | Copyright status: false = public domain in the USA, true = under copyright, null = unknown. |
| languages | Yes | Two-character language codes for this edition. |
| media_type | Yes | "Text" for readable books, "Sound" for audio books. Only "Text" books have plain-text content available for gutenberg_get_text. |
| bookshelves | Yes | Project Gutenberg bookshelf categories (e.g., "Best Books Ever Listings", "Category: Classics of Literature"). |
| translators | Yes | Translators, if this is a translated work. |
| download_count | Yes | Total downloads — popularity signal. |
| has_plain_text | Yes | True if media_type is "Text" AND a text/plain format (UTF-8 or ASCII) is present in formats — prerequisite for gutenberg_get_text. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds context about returned data (e.g., formats map with URLs) without contradicting annotations, enhancing transparency 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?
Two sentences efficiently convey purpose, return data, and usage guidance. No unnecessary words, 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 availability of output schema and simple parameter set, the description fully covers what the tool does, what it returns, and when to use it, leaving no gaps for an agent.
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 coverage is 100% with a detailed description of the 'id' parameter (type, max, example, source). The description adds minimal extra value beyond the schema, meeting the baseline.
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 explicitly states 'Fetch complete metadata for a Project Gutenberg book by ID' and lists specific fields (title, authors, etc.), making the purpose clear. It distinguishes from sibling tools by mentioning its use before gutenberg_get_text.
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 directly tells the agent to use this tool before gutenberg_get_text to confirm plain-text availability and get the download URL, providing explicit when-to-use and alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gutenberg_get_textGet Gutenberg Book TextARead-onlyIdempotentInspect
Retrieve the plain-text content of a Project Gutenberg book, stripped of the standard license header and footer so the response contains only the literary work. For long works — novels routinely run 500KB–2MB — use offset and limit to read in chunks rather than fetching the whole book at once. The response reports totalChars and remainingChars so the caller can page through without guessing. Prefers UTF-8 plain text; falls back to ASCII plain text; refuses audio books (media_type "Sound") with a clear error.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Project Gutenberg book ID. Use gutenberg_search_books or gutenberg_get_book to find IDs. Example: 1342 for Pride and Prejudice, 2600 for War and Peace, 84 for Frankenstein. | |
| limit | No | Maximum number of characters to return in this chunk. Default 20,000 (~4–5 pages of prose). Increase toward 50,000 for large context windows. The actual returned length may be slightly less than limit when a natural paragraph boundary is found within 500 characters of the limit — check the length field in the response for the actual character count returned. | |
| offset | No | Character offset into the stripped literary text at which to start reading. 0 returns the beginning of the work. To read subsequent chunks, use offset = prior_offset + prior_length (the length field from the previous response — NOT offset + limit, because the actual returned length may be slightly less than limit due to paragraph-boundary trimming). |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | Gutenberg book ID. |
| text | Yes | The requested chunk of literary text, stripped of Gutenberg license boilerplate. Encoding: UTF-8. Line endings: normalized to LF. |
| title | Yes | Book title, from the catalog record. |
| length | Yes | Number of characters in this chunk. |
| offset | Yes | Character offset where this chunk begins. |
| hasMore | Yes | True if there is more text after this chunk. When true, call again with offset = offset + length. |
| provenance | Yes | One-line source note with Project Gutenberg ID, title, and license URL. |
| totalChars | Yes | Total characters in the stripped literary text. Use with offset and length to determine progress and plan subsequent calls. |
| sourceFormat | Yes | The format that was fetched. "text/html" indicates HTML-to-text conversion was applied because no plain-text format was available. |
| remainingChars | Yes | Characters remaining after this chunk (totalChars - offset - length). 0 means this chunk includes the end of the book. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: stripping license headers, chunking mechanism with totalChars/remainingChars, encoding preferences, and explicit refusal of audio books. Annotations already indicate read-only, idempotent, and open-world; description adds valuable behavioral context.
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 dense but every sentence is informative. No wasted words. Front-loaded with the core action, then details on chunking and encoding.
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 output schema exists, the description covers all necessary operational context: chunking, encoding fallback, error handling for audio books. Complete for an agent to use correctly.
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 coverage is 100% with detailed parameter descriptions. The tool description adds extra clarity on paging logic (using prior_offset+prior_length instead of offset+limit), which adds significant value beyond the schema.
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 it retrieves plain-text content of a Project Gutenberg book, stripped of headers and footers. It distinguishes from sibling tools like gutenberg_search_books, gutenberg_get_book, and gutenberg_browse_popular by focusing on text retrieval.
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?
Provides guidance on chunking for long works using offset and limit, and mentions preferences/fallbacks for encoding. Could be more explicit about when to use alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gutenberg_search_booksSearch Gutenberg BooksARead-onlyIdempotentInspect
Search the Project Gutenberg catalog of 78,000+ public-domain books. Matches title and author name with query words; filters by topic (subject or bookshelf keyword), language, author lifespan, or a specific list of Gutenberg IDs. Results are ordered by popularity (download count) by default. Returns book ID, title, authors, languages, subjects, and download count — use gutenberg_get_book for the full formats map before fetching text.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | No | Narrow results to specific Gutenberg ID numbers. Other filters still apply. Useful for batch pre-fetching known IDs; use gutenberg_get_book for single-ID lookups. | |
| page | No | Page number for paginated results (1-indexed). Each page returns up to 32 books. Use totalCount to determine total pages. | |
| sort | No | Result ordering. "popular" (default) sorts by download count descending. "ascending" and "descending" sort by Gutenberg ID number. | popular |
| query | No | Words to match against book titles and author names (case-insensitive, space-separated). Example: "dickens expectations" matches Great Expectations by Charles Dickens. | |
| topic | No | Case-insensitive phrase to match against subjects and bookshelves. Example: "detective" returns books on the "Detective and Mystery Stories" bookshelf. Separate from query — topic searches categorization metadata, not title/author. | |
| languages | No | Filter to books in any of these two-character ISO 639-1 language codes. Example: ["en"] for English, ["fr", "de"] for French or German. | |
| author_year_end | No | Include only books with at least one author alive on or before this year. Example: author_year_start=1800 with author_year_end=1899 returns books with 19th-century authors. | |
| author_year_start | No | Include only books with at least one author alive on or after this year (positive = CE, negative = BCE). Combine with author_year_end for a range. |
Output Schema
| Name | Required | Description |
|---|---|---|
| page | Yes | Current page number. |
| books | Yes | Matching books, ordered by the sort parameter. |
| hasMore | Yes | True if there are additional pages of results. |
| totalCount | Yes | Total number of books matching the query across all pages. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnly, openWorld, and idempotent - description aligns by describing a search operation. It adds behavioral details like default popularity ordering and pagination behavior, but doesn't mention rate limits or error cases.
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?
Description is concise (4 sentences), front-loaded with purpose, and efficiently conveys scope, filters, ordering, and return fields without redundancy.
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 8 parameters and output schema, the description covers the essential aspects: what it searches, filters available, default ordering, pagination, and relation to siblings. No gaps given the complexity.
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 coverage is 100% with good parameter descriptions. The tool description adds value by summarizing the overall search behavior and directing to sibling tools, but doesn't elaborate on each parameter beyond what schema provides. Baseline 3 due to 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?
Description clearly states it searches the Project Gutenberg catalog with matching and filtering capabilities. It explicitly lists the matching/filter criteria and default ordering. It distinguishes from siblings by mentioning the return fields and directing to gutenberg_get_book for full formats.
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?
Description gives context for when to use this tool (searching with filters) and directs to gutenberg_get_book for more detail. However, it does not explicitly exclude situations where browsing popular books might be more appropriate, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!