openlibrary-mcp-server
Server Details
Search books and authors, fetch editions, browse subjects, and resolve cover images.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- cyanheads/openlibrary-mcp-server
- GitHub Stars
- 3
- Server Listing
- @cyanheads/openlibrary-mcp-server
Available Tools
10 toolsopenlibrary_get_authorGet AuthorARead-onlyIdempotentInspect
Fetch author detail by Open Library Author ID (OL…A). Returns bio, birth/death dates, photo IDs, and linked identifiers from Wikidata, VIAF, ISNI, Goodreads, and LibraryThing. Use openlibrary_search_authors to find an author ID first.
| Name | Required | Description | Default |
|---|---|---|---|
| author_id | Yes | Open Library Author ID. Format: OL…A (e.g., "OL24638A"). A leading "/authors/" prefix is stripped if provided. |
Output Schema
| Name | Required | Description |
|---|---|---|
| bio | No | Author biography. Absent when not provided. |
| name | No | Primary author name. |
| error | No | Present when the call failed. Absent on success. |
| notice | No | Set when the requested author ID was merged into a different canonical ID. |
| author_id | No | Canonical Open Library Author ID (OL…A). |
| photo_ids | No | Numeric photo IDs. Pass to openlibrary_get_cover_url with target "author" and id_type "id". |
| birth_date | No | Birth date string. Absent when not recorded. |
| death_date | No | Death date string. Absent when not recorded. |
| remote_ids | No | Remote identifiers for cross-referencing with other databases. |
| fuller_name | No | Full name including middle names. Absent when not recorded. |
| personal_name | No | Personal or given name. Absent when not recorded. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety and determinism profile. The description adds value by specifying the content of the response (bio, dates, photo IDs, identifiers) and the input preprocessing (stripping a leading '/authors/' prefix), which are behavioral traits not captured in annotations. It does not mention error handling or rate limits, but with annotations covering the safety profile, a 4 is appropriate.
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 two sentences with no filler. The main purpose and return content are front-loaded in the first sentence, and the usage guidance is a single clear sentence. Every word earns its place, making it appropriately 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?
For a single-parameter read-only tool with an output schema available and annotations covering safety, the description is complete. It states what the tool does, what it returns, and how to obtain the required input (via search_authors). No essential information is missing for an agent to call this tool 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?
The input schema already fully documents the single parameter author_id, including format (OL…A) and prefix stripping. The description repeats this information without adding new semantic detail, so it does not compensate beyond the schema. With schema coverage at 100%, the baseline of 3 is correct.
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 uses the specific verb 'Fetch' with a clear resource 'author detail' and scope 'by Open Library Author ID'. It lists what is returned (bio, dates, photo IDs, linked identifiers) which distinguishes it from siblings like get_author_works or get_work, and it explicitly points to search_authors as the precursor tool.
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 gives a clear workflow: use openlibrary_search_authors to find an author ID first. This provides contextual guidance. However, it does not explicitly state when not to use this tool versus siblings such as get_author_works, so it lacks exclusions, making it a strong but not perfect usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
openlibrary_get_author_worksGet Author WorksARead-onlyInspect
List works by an author. Returns titles, cover IDs, and work OLIDs for drilling into editions or details. Use openlibrary_get_author for author bio and details, or openlibrary_get_editions to explore specific printings.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max works to return. | |
| offset | No | Zero-based offset for pagination. | |
| author_id | Yes | Open Library Author ID (OL…A). A leading "/authors/" prefix is stripped if provided. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| total | No | Total works by this author. |
| works | No | Works by this author, up to limit. |
| notice | No | Set when the requested author ID was merged into a different canonical ID. |
| author_id | No | Open Library Author ID. |
| totalCount | No | Total works by this author across all pages. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds mention of return fields, but these are also covered by the existing output schema, so it adds limited new behavioral context. No contradiction exists, but the description doesn't go beyond what annotations + schema already establish.
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 with zero filler. The first sentence states the core purpose and the key return fields; the second gives the sibling routing. Front-loaded and efficient, 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?
The tool has a full output schema, complete parameter descriptions, and annotations covering safety. The description ties it together by clarifying purpose, return contents, and sibling relationships. Nothing an agent needs to decide whether to call this tool or interpret its results is missing.
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% – every parameter (author_id, limit, offset) has a clear description. The tool description adds no additional parameter-specific meaning beyond what the schema already provides, so the baseline of 3 applies.
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 opens with a specific verb and resource: 'List works by an author.' It also names the exact return fields (titles, cover IDs, work OLIDs) and explicitly differentiates from sibling tools (openlibrary_get_author, openlibrary_get_editions). This leaves no ambiguity about what the tool does or how it differs from its neighbors.
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 gives explicit routing guidance: 'Use openlibrary_get_author for author bio and details, or openlibrary_get_editions to explore specific printings.' This clearly tells the agent when NOT to use this tool and points to the correct alternative, which is exactly what usage guidelines should provide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
openlibrary_get_cover_urlGet Cover URLARead-onlyIdempotentInspect
Resolve a cover image URL for a book or author photo. Returns a direct HTTPS URL in the requested size (S/M/L). The Covers API always returns HTTP 200 — missing covers return a 1×1 placeholder GIF, not a 404 — so the identifier format is validated locally first: "id" must be numeric, "isbn" 10 or 13 digits, "olid" an edition OLID (OL…M) for target "book" and an author OLID (OL…A) for target "author". Identifiers with path separators or control characters, and author-by-ISBN lookups, are rejected before any request. URLs can be embedded in markdown as .
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Image size. S = small (~45px tall), M = medium (~150px tall), L = large (~400px tall). | M |
| target | No | "book" returns a book cover from covers.openlibrary.org/b/. "author" returns an author photo from covers.openlibrary.org/a/ — use with id_type "id" (photo_id) or "olid" (author OLID). | book |
| id_type | Yes | "id" is the numeric cover_i / cover ID from search or work results. "isbn" and "olid" look up the cover from those identifiers. | |
| identifier | Yes | The identifier value, validated against id_type before the URL is built. For "id": a numeric cover or photo ID from work/edition/author data. For "isbn": 10 or 13 digits, hyphens optional. For "olid": an edition OLID (OL…M) for target "book", an author OLID (OL…A) for target "author". |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | No | Direct HTTPS URL to the cover image. The Covers API returns HTTP 200 for all requests — a 1×1 placeholder GIF is returned when no cover exists for the identifier. |
| note | No | Reminder that the URL always returns HTTP 200; a placeholder GIF is served when no cover exists. |
| error | No | Present when the call failed. Absent on success. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint and idempotentHint, covering safety and idempotency. The description adds significant behavioral context beyond that: it explains the Covers API always returns HTTP 200 with a placeholder GIF for missing covers, the local validation of identifier formats, and rejection of path separators or control characters. This reveals edge-case behavior that annotations alone do not provide, helping the agent set expectations.
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 efficient. The first sentence states the purpose, followed by behavioral notes and validation rules, then usage guidance for embedding. Every sentence contributes information that is not redundant with the schema or annotations. The structure front-loads the core purpose before diving into details, making it easy for an agent to quickly grasp the tool's function without wasteful verbiage.
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?
The tool has 4 parameters, 3 enums, and an output schema. The description covers all relevant aspects: validation rules, response behavior, embedding in markdown, and parameter interdependencies. It does not need to explain the return format because the output schema is provided. Given the complexity and the existing structured information, the description is complete and leaves no gaps for correct invocation.
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 covers 100% of parameter descriptions, meeting the base requirement. The description adds value by elaborating on validation rules per id_type, such as what constitutes a valid numeric ID, ISBN, or OLID, and clarifies the target parameter's distinction between author and book. It also notes that author-by-ISBN lookups are rejected, which is not obvious from the schema. This enriches the agent's understanding beyond the bare 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 opens with 'Resolve a cover image URL for a book or author photo,' clearly stating the verb and resource. It immediately conveys the tool's unique purpose of resolving cover URLs, distinguishing it from sibling tools like openlibrary_get_work or openlibrary_search_books, which retrieve metadata or perform searches. The specificity of 'cover image URL' and 'book or author photo' leaves no ambiguity.
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?
While the description doesn't explicitly name alternatives or say 'use this when...', it clearly implies the intended use case: resolving cover URLs from identifiers. It provides detailed context such as local validation rules and the fact that invalid inputs are rejected before making a request. It stops short of explicitly contrasting with sibling tools, but the purpose is clear enough that an agent can infer when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
openlibrary_get_editionGet EditionARead-onlyIdempotentInspect
Resolve one or more editions by identifier: ISBN-10, ISBN-13, OCLC, LCCN, or Open Library Edition ID (OL…M). Every identifier in a call shares one id_type — pass id_type "isbn" for both ISBN-10 and ISBN-13. Up to 50 identifiers resolve in a single upstream request, so a bibliography or shelf export costs one call rather than one per book; a large batch is a large response, so ask for what you need. Returns full edition metadata including authors, publisher, language, all identifier types, and the parent work ID, with author names inline and no secondary lookup; when the edition record itself lists no authors, they are recovered from the parent work and marked as such. Partial success is the norm — identifiers that resolve come back in editions, the rest are listed in unresolved with a reason, and the call fails only when nothing resolved.
| Name | Required | Description | Default |
|---|---|---|---|
| id_type | Yes | Identifier type shared by every entry in identifiers. "isbn" handles both ISBN-10 and ISBN-13. "olid" is the native Open Library edition ID (OL…M). Mixing types within one call is not supported — issue one call per type. | |
| identifiers | Yes | Identifiers to resolve, 1–50, all of the type named by id_type. Resolved editions come back in request order. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| editions | No | Editions that resolved, in request order. Shorter than identifiers when any entry missed. |
| unresolved | No | Identifiers that produced no edition. Empty when every identifier resolved; never overlaps editions. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides substantial behavioral detail beyond the annotations (readOnlyHint, openWorldHint, idempotentHint). It discloses partial success behavior (resolved vs. unresolved lists), failure conditions (fails only when nothing resolved), author recovery from parent work with marking, inline author names with no secondary lookup, and the batch limit's impact on response size. These are valuable insights that help an agent anticipate edge cases and manage expectations, going well beyond the annotations' basic read-only/idempotent hints.
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, dense paragraph that front-loads the core purpose and then expands with constraints and response behavior. Every sentence adds value, covering batching, partial success, author recovery, and failure modes without redundancy. It is informative yet concise, striking an excellent balance between completeness and brevity for an agent-facing description.
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?
The tool is moderately complex (2 parameters, but with batch semantics and partial success), and the description covers all necessary aspects: identifier types, id_type constraints, batch limits, response ordering, partial success handling, author recovery, and failure conditions. The presence of an output schema further reduces the need to describe return values. The description is fully complete for an agent to correctly invoke and interpret the tool, leaving no significant 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?
The input schema already provides 100% description coverage for both parameters. The description adds extra nuance by clarifying that id_type 'isbn' covers both ISBN-10 and ISBN-13 and that identifiers must share a single type, plus noting that resolved editions come back in request order. These additions extend the schema's basic descriptions, especially the ordering behavior which is not in the schema. While the schema is thorough, the description's additional clarifications justify a score above the baseline of 3.
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: resolving one or more editions by specific identifier types (ISBN-10, ISBN-13, OCLC, LCCN, OLID). It uses a specific verb ('Resolve') and names the resource ('editions') plus the identifier scope. However, it does not explicitly differentiate itself from the sibling tool 'openlibrary_get_editions', which could cause ambiguity about which to use for fetching editions. The distinction is implied by the focus on identifier-based resolution, but not explicitly stated.
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 gives clear context on when this tool is efficient ('a bibliography or shelf export costs one call rather than one per book'), indicating batch lookups are a primary use case. It also states the constraint that all identifiers must share one id_type and warns about large responses. However, it does not mention when to prefer a sibling tool (e.g., openlibrary_get_editions) or when not to use this tool, though the absence of explicit exclusions is acceptable given the focused purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
openlibrary_get_editionsGet EditionsARead-onlyIdempotentInspect
List editions of a work — different publishers, languages, formats, and print runs. Returns ISBNs, publisher, language, page count, and edition OLIDs. Use after openlibrary_get_work or openlibrary_search_books to find a specific printing.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max editions to return. Prefer 10–20 for exploration. | |
| offset | No | Zero-based offset for pagination. | |
| work_id | Yes | Open Library Work ID (OL…W). A leading "/works/" prefix is stripped if provided. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| total | No | Total editions for this work. |
| work_id | No | Open Library Work ID. |
| editions | No | Editions of the work, up to limit. |
| totalCount | No | Total editions for this work across all pages. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds behavioral specifics about what is listed (publishers, languages, formats, print runs) and the exact return fields, which enriches the agent's expectation without contradicting annotations.
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 with no filler. The first sentence front-loads the core purpose and output fields, the second adds a concise usage pointer. Everything earns its place and is highly scannable.
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?
With full schema coverage, clear safety annotations, and an output schema present, the description covers what the tool does, when to use it, and what it returns. It omits only marginal details like explicit pagination behavior, but limit/offset schema descriptions cover that adequately.
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% coverage; limit, offset, and work_id all have descriptions including defaults and ranges. The description adds no parameter-specific information beyond the schema, so the baseline for full schema coverage applies.
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 uses a specific verb ('List') and resource ('editions of a work'), and enumerates the returned data (ISBNs, publisher, language, page count, edition OLIDs). It clearly distinguishes from siblings like openlibrary_get_edition (singular) and ties into the workflow with 'Use after openlibrary_get_work or openlibrary_search_books'.
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 gives when to use: 'Use after openlibrary_get_work or openlibrary_search_books to find a specific printing.' This places the tool in a sequence and implies it is not for getting a single edition or searching, providing clear context against sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
openlibrary_get_subjectGet SubjectARead-onlyInspect
Browse works by subject. Returns matching works with edition counts and cover IDs, plus the total work count for the subject. Case and spacing are normalized before lookup, so "Science Fiction" and "science_fiction" are the same request. Subject tags are user-contributed and the vocabulary varies — when a subject returns no works, try a different word form (singular/plural), a synonym, or a broader term.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max works to return. Subject pages typically show 12 at a time. | |
| offset | No | Zero-based offset for pagination. | |
| subject | Yes | Subject name. Normalized before lookup — lowercased with spaces converted to underscores (e.g., "Science Fiction" → "science_fiction") — so varying case or spacing does not change the result. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| works | No | Works under this subject, up to limit. |
| notice | No | Recovery guidance when work_count is 0 — echoes the subject and suggests alternatives. Absent when works are found. |
| totalCount | No | Total works tagged with this subject across all pages. |
| work_count | No | Total works tagged with this subject. |
| subject_key | No | Normalized subject key (lowercase, underscores). |
| subject_name | No | Canonical subject name as stored on Open Library. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the description correctly supplements these by explaining case/spacing normalization and that subjects are user-contributed with varying vocabulary. It also details the outputs (edition counts, cover IDs, total work count), adding context beyond the annotations without contradicting them.
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 three sentences with no waste. It front-loads the primary purpose, then lists key outputs, then explains normalization and provides fallback advice. Each sentence earns its place and the structure is logical and scannable.
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 retrieval tool with an output schema, the description is complete. It explains what is returned, how the input is normalized, and how to handle empty results. The openWorldHint is backed with concrete guidance. Nothing essential is missing for an agent to call this tool 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 description coverage is 100%, so parameters are fully documented in the schema. The description adds extra value by explaining the normalization behavior for the subject parameter and giving usage advice for the open-world nature of subjects, which goes beyond the schema's basic type/description. This compensates well for the high coverage 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 opens with 'Browse works by subject', stating a specific verb and resource. It then lists what is returned (works with edition counts, cover IDs, total work count), making the tool's function unambiguous and clearly distinct from sibling tools focused on authors, covers, editions, and search.
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 clearly indicates when to use the tool (to browse works by subject) and provides practical guidance on handling the open-world variable vocabulary by suggesting synonyms, singular/plural forms, and broader terms. It stops short of explicitly stating when not to use it or naming alternatives, but the context is strong enough for an agent to make the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
openlibrary_get_workGet WorkARead-onlyIdempotentInspect
Fetch a work by Open Library Work ID (OL…W). Returns title, description, subjects, cover IDs, and linked author IDs for follow-up lookups. Works represent the abstract book concept independent of any specific edition. Note: author names are not included — use openlibrary_get_author or openlibrary_search_books for names.
| Name | Required | Description | Default |
|---|---|---|---|
| work_id | Yes | Open Library Work ID. Format: OL…W (e.g., "OL45804W"). A leading "/works/" prefix is stripped if provided. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| title | No | Work title. |
| notice | No | Disclosure when the text output caps a long list — names the omitted count and points to the complete array in structuredContent. Absent when nothing was capped. |
| created | No | ISO 8601 creation timestamp. Absent when not available. |
| work_id | No | Canonical Open Library Work ID (OL…W). |
| subjects | No | Subject tags for this work. |
| cover_ids | No | Numeric cover IDs. Pass to openlibrary_get_cover_url with id_type "id". |
| author_ids | No | Open Library Author IDs (OL…A). Use openlibrary_get_author for names and bio. |
| description | No | Work description or blurb. Absent when not provided. |
| last_modified | No | ISO 8601 last-modified timestamp. Absent when not available. |
| subject_times | No | Time period subjects. |
| subject_people | No | People subjects. |
| subject_places | No | Geographic subjects. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnlyHint, idempotentHint, and openWorldHint, lowering the bar. The description adds value beyond annotations by disclosing the return payload and, importantly, the exclusion behavior that author names are omitted — a non-obvious trait an agent must know before calling. No contradiction: 'Fetch' is consistent with readOnlyHint=true.
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?
Three tight sentences with zero filler. The verb+resource and primary behavior are front-loaded, the abstract-work concept is stated next, and the exclusion with alternatives closes it out. Every sentence 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?
Output schema covers return values, the sole parameter is fully documented in the schema, and annotations carry the safety profile. The description completes the picture with the work-versus-edition distinction and the author-name exclusion. Nothing an agent needs to call this correctly is missing.
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% — work_id's format (OL…W), required status, and prefix-stripping ('/works/' is stripped) are fully documented in the schema. The description merely echoes the OL…W format without adding syntax or semantic details beyond the schema, so the baseline 3 is appropriate.
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?
States a specific verb+resource: 'Fetch a work by Open Library Work ID (OL…W)'. Clearly differentiates from siblings by explaining that works are the 'abstract book concept independent of any specific edition', pointing away from get_edition and get_edition(s). The returns list (title, description, subjects, cover IDs, author IDs) makes the tool's scope unambiguous.
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 an explicit exclusion with named alternatives: 'author names are not included — use openlibrary_get_author or openlibrary_search_books for names.' The work-vs-edition distinction also implicitly routes the agent toward get_edition when a specific physical edition is wanted, though it does not name that sibling explicitly. Clear context with one explicit exclusion, but not a full when-to-use enumeration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
openlibrary_search_authorsSearch AuthorsARead-onlyInspect
Search Open Library authors by name. Returns Open Library Author IDs, names, birth/death dates, top works, and subject associations. Use author IDs for openlibrary_get_author (bio, remote IDs) or openlibrary_get_author_works (list of works).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results to return. | |
| query | Yes | Author name search query. Partial names and alternate names work. | |
| offset | No | Zero-based offset for pagination. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| total | No | Total matching authors across all pages. |
| notice | No | Guidance when the page is empty (how to vary a name that matched nothing, or which offset to retry when offset ran past the end) or when the text output capped a per-author list. Absent when neither applies. |
| offset | No | Zero-based offset of the first returned result — echoes the requested offset, so an empty page still records the offset that produced it. |
| authors | No | Matching authors, up to limit. |
| totalCount | No | Total matching authors across all pages — the upstream match count, reported even when this page is empty because offset ran past the end. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds the return field list (IDs, names, dates, works, subjects) but not deeper behavior like rate limits, ordering, or result richness. With annotation coverage, this is adequate but not rich.
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, no filler. Purpose and result fields in the first sentence; usage guidance in the second. Efficient and front-loaded, though the second sentence could arguably be part of usage guidelines rather than purpose, it doesn't waste words.
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 an output schema exists and annotations cover safety, the description provides the key context: what fields appear in results and how to consume them with sibling tools. Pagination behaviors are in the schema. Nothing critical is missing for an agent to call it 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% for all three parameters; the description adds nothing beyond what the schema already states (e.g., 'Partial names and alternate names work' is duplicated from the query description). Baseline 3 is appropriate because 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?
States a specific verb and resource: 'Search Open Library authors by name.' Clearly distinguishes itself from sibling retrieval tools by naming the follow-up tools (openlibrary_get_author, openlibrary_get_author_works) that consume its output. Immediate clarity on what it does and how it fits.
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 explicit context on how to use the returned author IDs for subsequent tool calls, which tells the agent why this tool exists. Doesn't explicitly state when not to use it vs. search_books, but the mention of alternatives creates a clear usage path. Minor gap: no exclusions or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
openlibrary_search_booksSearch BooksARead-onlyInspect
Full-text book search across Open Library works. Supports field filters (title, author, subject, publisher, ISBN, language) and returns work-level records with edition counts, cover IDs, and reading availability. Use query for general search or combine specific field filters. Results are work-level — drill into editions via openlibrary_get_editions.
| Name | Required | Description | Default |
|---|---|---|---|
| isbn | No | Find works that have editions with this ISBN (10 or 13 digits, hyphens ignored). | |
| sort | No | Sort order. "relevance" uses Solr scoring. "new"/"old" sort by first publish year. "rating" by average community rating. "editions" by edition count. | relevance |
| limit | No | Max results to return. Higher values increase response size; prefer 10–20 for exploration. | |
| query | No | Full-text search query. Supports Solr field prefixes: title:, author:, subject:, publisher:, isbn:, language:. Omit to use the filter parameters instead. | |
| title | No | Filter by title. Matched against work title and alternative titles. | |
| author | No | Filter by author name. Partial names work. | |
| offset | No | Zero-based offset for pagination. | |
| subject | No | Filter by subject tag (e.g., "science fiction", "history"). | |
| language | No | Restrict results to one language. Takes a 3-letter MARC code (e.g., "eng", "fre", "ger", "chi") — the same vocabulary openlibrary_get_edition and openlibrary_get_editions return. A 2-letter ISO 639-1 code (e.g., "en", "fr") is accepted and translated to its MARC equivalent; an unrecognized 2-letter code is rejected rather than silently ignored. The equivalent in-query form is language:eng. | |
| publisher | No | Filter by publisher name. Partial names work (e.g., "Penguin"). | |
| include_availability | No | Include live reading availability from Internet Archive (borrow/read status). Adds ~200ms latency. Use when the user needs to know if they can read the book online. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| total | No | Total matching works across all pages. |
| works | No | Matching works, up to limit. |
| notice | No | Guidance when the page is empty (how to broaden a query that matched nothing, or which offset to retry when offset ran past the end) or when the text output capped a per-work list. Absent when neither applies. |
| offset | No | Zero-based offset of the first returned result. |
| queryEcho | No | The effective search criteria as the server interpreted them — query string plus any active field filters. Absent when only a bare query is used. |
| totalCount | No | Total matching works across all pages — the upstream match count, reported even when this page is empty because offset ran past the end. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered and the search description is consistent with it — no contradiction. The description adds useful return-context (work-level records, edition counts, cover IDs, reading availability) and the work-vs-edition distinction, though it does not disclose pagination depth, rate-limit behavior, or failure modes. Given the annotations carry the read-only disclosure, a 3 is appropriate.
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?
Three sentences with zero filler: purpose first, then capability enumeration, then usage routing to the editions sibling. Every sentence earns its place and the structure front-loads the most decision-relevant 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 an 11-parameter, fully-schema-documented read-only search tool with an output schema covering the return values, the description is complete: it states purpose, capability set, the query-versus-filter usage pattern, and the sibling to route to for edition detail. Nothing an agent needs to invoke it correctly is missing.
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 all 11 parameters including the language MARC-code behavior, sort semantics, and include_availability latency. The description adds modest value by noting that 'query' can be swapped for compiled field filters ('Use query for general search or combine specific field filters'), helping the agent choose between search strategies, but it otherwise repeats what the schema already states. Baseline 3 is correct.
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 opens with a specific verb plus resource ('Full-text book search across Open Library works'), then enumerates the supported filter fields (title, author, subject, publisher, ISBN, language) and the return shape (work-level records with edition counts, cover IDs, reading availability). It explicitly differentiates from siblings by stating results are work-level and routing edition-level work to openlibrary_get_editions, so an agent can tell it apart from get_edition/get_editions and the author/inside search tools without opening the schema.
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 gives actionable selection guidance: 'Use query for general search or combine specific field filters' tells the agent which parameter path to choose, and 'Results are work-level — drill into editions via openlibrary_get_editions' names an alternative tool and the condition that selects it. It does not explicitly state when to prefer openlibrary_search_authors or openlibrary_search_inside over this tool, leaving some sibling differentiation to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
openlibrary_search_insideSearch Inside BooksARead-onlyInspect
Search the full text of books scanned by the Internet Archive — the "which book contains this passage?" lookup that the metadata tools cannot answer. Quote a phrase for an exact-phrase match; bare terms match anywhere in the text. Each result is an Internet Archive item with the matching passages as snippets, plus a relevance score. The full-text index is an order of magnitude slower than the metadata endpoints (seconds, not milliseconds), so reach for it when the passage is the question, not as a general book search — use openlibrary_search_books for title, author, or subject. Results key on Internet Archive items rather than Open Library works: chain the returned ia_identifier to archive.org, or match it against the ia_identifiers on openlibrary_search_books results to reach the catalogue record.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max matching items to return. Each carries its own snippets, so higher values grow the response quickly — prefer 10–20. | |
| query | Yes | Text to find inside scanned books. Wrap in double quotes for an exact-phrase match (e.g., "the spice must flow"); unquoted terms match independently and return far broader results. | |
| offset | No | Zero-based offset for pagination. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| total | No | Total matching Internet Archive items across all pages. |
| notice | No | Guidance when the page is empty (how to broaden a query that matched nothing, or which offset to retry when offset ran past the end) or when the text output capped a per-item snippet list. Absent when neither applies. |
| offset | No | Zero-based offset of the first returned match. |
| matches | No | Matching items, up to limit, ordered by relevance. |
| totalCount | No | Total matching items across all pages — the upstream match count, reported even when this page is empty because offset ran past the end. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint; the description adds significant behavioral context beyond these: the index is an order of magnitude slower, results are Internet Archive items rather than Open Library works, and the returned ia_identifier can be chained or matched. This is rich, non-redundant 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 well-structured and front-loaded with the core purpose, followed by usage guidance and performance/result notes. It is efficient—about 100 words—and every sentence earns its place, though the final sentence on keying results could arguably be placed earlier. Still appropriately concise.
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 an output schema is present (so return format is handled elsewhere), the description covers all essential context: purpose, usage, performance, result semantics, and tool routing. No pragmatic detail an agent needs to select and call this tool correctly is missing.
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 descriptions for all three parameters, establishing a baseline of 3. The description adds extra value: explains quoting semantics for query, notes the response growth implication for limit and recommends 10-20, and clarifies offset's role. This exceeds the baseline without being verbose.
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?
States a specific verb ('Search') and resource ('full text of books scanned by the Internet Archive'), and explicitly distinguishes it from metadata tools with the 'which book contains this passage?' framing. The purpose is unambiguous and easily differentiated from siblings like openlibrary_search_books.
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 explicit when-to-use (passage lookup) and when-not-to-use (general book search) guidance, naming the alternative tool (openlibrary_search_books) and its intended use case (title, author, subject). Also clarifies quoting behavior for exact phrases, leaving no ambiguity about invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
10 tool updates
- Changed
openlibrary_get_author6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "author_id", + "name", + "photo_ids", + "remote_ids" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `not_found`: Author ID does not exist on Open Library. Other values are possible when a failure originates below the handler.", + "examples": [ + "not_found" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "author_id", - "name", - "photo_ids", - "remote_ids" -]
- Changed
openlibrary_get_author_works6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "total", + "author_id", + "works" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `not_found`: Author ID does not exist on Open Library. Other values are possible when a failure originates below the handler.", + "examples": [ + "not_found" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "total", - "author_id", - "works" -]
- Changed
openlibrary_get_cover_url6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "url", + "note" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `invalid_identifier`: The identifier contains path separators, \"..\", or control characters, or does not match the format its id_type expects. `invalid_target`: The id_type is not valid for the target — an author photo cannot be resolved by ISBN. Other values are possible when a failure originates below the handler.", + "examples": [ + "invalid_identifier", + "invalid_target" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "url", - "note" -]
- Changed
openlibrary_get_edition6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "editions", + "unresolved" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `not_found`: No identifier in the batch resolved to an edition. `invalid_identifier`: Every identifier in the batch is malformed for the specified id_type. Other values are possible when a failure originates below the handler.", + "examples": [ + "not_found", + "invalid_identifier" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "editions", - "unresolved" -]
- Changed
openlibrary_get_editions6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "total", + "work_id", + "editions" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `not_found`: Work ID does not exist on Open Library. Other values are possible when a failure originates below the handler.", + "examples": [ + "not_found" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "total", - "work_id", - "editions" -]
- Changed
openlibrary_get_subject6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "subject_name", + "subject_key", + "work_count", + "works" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode.", + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "subject_name", - "subject_key", - "work_count", - "works" -]
- Changed
openlibrary_get_work6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "work_id", + "title", + "subjects", + "subject_places", + "subject_times", + "subject_people", + "cover_ids", + "author_ids" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `not_found`: Work ID does not exist on Open Library. Other values are possible when a failure originates below the handler.", + "examples": [ + "not_found" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "work_id", - "title", - "subjects", - "subject_places", - "subject_times", - "subject_people", - "cover_ids", - "author_ids" -]
- Changed
openlibrary_search_authors6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "total", + "offset", + "authors" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode.", + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "total", - "offset", - "authors" -]
- Changed
openlibrary_search_books6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "total", + "offset", + "works" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `unknown_language_code`: A 2-letter language value has no MARC equivalent, so no filter could be applied. Other values are possible when a failure originates below the handler.", + "examples": [ + "unknown_language_code" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "total", - "offset", - "works" -]
- Changed
openlibrary_search_inside6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "total", + "offset", + "matches" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode.", + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "total", - "offset", - "matches" -]
2 tool updates
- Changed
openlibrary_get_author1 field changed- added
Output schema / properties / noticeAdded value: +{ + "description": "Set when the requested author ID was merged into a different canonical ID.", + "type": "string" +}
- Changed
openlibrary_get_author_works1 field changed- added
Output schema / properties / noticeAdded value: +{ + "description": "Set when the requested author ID was merged into a different canonical ID.", + "type": "string" +}
3 tool updates
- Changed
openlibrary_get_cover_url1 field changed- changed
Input schema / properties / identifier / descriptionPrevious value: -"The identifier value. For \"id\": numeric cover ID from work/edition data. For \"isbn\": 10 or 13 digits, hyphens stripped. For \"olid\": edition OLID (OL…M) or author OLID (OL…A) when target is \"author\"."New value: +"The identifier value, validated against id_type before the URL is built. For \"id\": a numeric cover or photo ID from work/edition/author data. For \"isbn\": 10 or 13 digits, hyphens optional. For \"olid\": an edition OLID (OL…M) for target \"book\", an author OLID (OL…A) for target \"author\"."
- Changed
openlibrary_get_edition23 fields changed- changed
Input schema / properties / id_type / descriptionPrevious value: -"Identifier type. \"isbn\" handles both ISBN-10 and ISBN-13. \"olid\" is the native Open Library edition ID (OL…M)."New value: +"Identifier type shared by every entry in identifiers. \"isbn\" handles both ISBN-10 and ISBN-13. \"olid\" is the native Open Library edition ID (OL…M). Mixing types within one call is not supported — issue one call per type." - removed
Input schema / properties / identifierRemoved value: -{ - "description": "The identifier value. For ISBN: 10 or 13 digits, hyphens stripped. For OCLC: numeric string. For LCCN: string as-is. For OLID: Open Library edition ID (e.g., OL7353617M).", - "type": "string" -} - added
Input schema / properties / identifiersAdded value: +{ + "description": "Identifiers to resolve, 1–50, all of the type named by id_type. Resolved editions come back in request order.", + "items": { + "description": "One identifier value. For ISBN: 10 or 13 digits, hyphens optional. For OCLC: numeric string. For LCCN: string as-is. For OLID: Open Library edition ID (e.g., OL7353617M).", + "type": "string" + }, + "maxItems": 50, + "minItems": 1, + "type": "array" +} - changed
Input schema / requiredPrevious value: -[ - "identifier", - "id_type" -]New value: +[ + "identifiers", + "id_type" +] - removed
Output schema / properties / authorsRemoved value: -{ - "description": "Authors credited for this edition. Empty only when neither the edition nor its parent work records an author.", - "items": { - "additionalProperties": false, - "description": "An author contributor for this edition.", - "properties": { - "author_id": { - "description": "Open Library Author ID (OL…A). Use openlibrary_get_author for bio and details.", - "type": "string" - }, - "name": { - "description": "Author display name.", - "type": "string" - }, - "source": { - "description": "\"edition\" = the attribution is recorded on this edition record. \"work\" = the edition records no authors of its own and this credit comes from the parent work, which covers every edition of the same text.", - "enum": [ - "edition", - "work" - ], - "type": "string" - } - }, - "required": [ - "name", - "source" - ], - "type": "object" - }, - "type": "array" -} - removed
Output schema / properties / cover_idsRemoved value: -{ - "description": "Numeric cover IDs for openlibrary_get_cover_url.", - "items": { - "type": "number" - }, - "type": "array" -} - removed
Output schema / properties / descriptionRemoved value: -{ - "description": "Edition description. Absent when not provided.", - "type": "string" -} - removed
Output schema / properties / ebook_urlRemoved value: -{ - "description": "Internet Archive URL for reading/borrowing. Present when an IA item exists.", - "type": "string" -} - removed
Output schema / properties / edition_idRemoved value: -{ - "description": "Open Library Edition ID (OL…M).", - "type": "string" -} - added
Output schema / properties / editionsAdded value: +{ + "description": "Editions that resolved, in request order. Shorter than identifiers when any entry missed.", + "items": { + "additionalProperties": false, + "description": "A resolved edition record.", + "properties": { + "authors": { + "description": "Authors credited for this edition. Empty only when neither the edition nor its parent work records an author.", + "items": { + "additionalProperties": false, + "description": "An author contributor for this edition.", + "properties": { + "author_id": { + "description": "Open Library Author ID (OL…A). Use openlibrary_get_author for bio and details.", + "type": "string" + }, + "name": { + "description": "Author display name.", + "type": "string" + }, + "source": { + "description": "\"edition\" = the attribution is recorded on this edition record. \"work\" = the edition records no authors of its own and this credit comes from the parent work, which covers every edition of the same text.", + "enum": [ + "edition", + "work" + ], + "type": "string" + } + }, + "required": [ + "name", + "source" + ], + "type": "object" + }, + "type": "array" + }, + "cover_ids": { + "description": "Numeric cover IDs for openlibrary_get_cover_url.", + "items": { + "type": "number" + }, + "type": "array" + }, + "description": { + "description": "Edition description. Absent when not provided.", + "type": "string" + }, + "ebook_url": { + "description": "Internet Archive URL for reading/borrowing. Present when an IA item exists.", + "type": "string" + }, + "edition_id": { + "description": "Open Library Edition ID (OL…M).", + "type": "string" + }, + "isbn_10": { + "description": "ISBN-10 identifiers.", + "items": { + "type": "string" + }, + "type": "array" + }, + "isbn_13": { + "description": "ISBN-13 identifiers.", + "items": { + "type": "string" + }, + "type": "array" + }, + "language": { + "description": "3-letter ISO language code (e.g., \"eng\"). Absent when not recorded.", + "type": "string" + }, + "lc_classifications": { + "description": "Library of Congress call numbers (e.g., \"TL685.7 .M366 2008\") — shelving classifications describing the subject, not identifiers. Not usable as a lookup value anywhere.", + "items": { + "type": "string" + }, + "type": "array" + }, + "lccn": { + "description": "Library of Congress Control Numbers (e.g., \"2008478952\") — lookupable identifiers; each one resolves this edition back through this tool with id_type \"lccn\".", + "items": { + "type": "string" + }, + "type": "array" + }, + "oclc": { + "description": "OCLC/WorldCat numbers.", + "items": { + "type": "string" + }, + "type": "array" + }, + "page_count": { + "description": "Page count. Absent when not recorded.", + "type": "number" + }, + "publish_date": { + "description": "Publication date string. Absent when not recorded.", + "type": "string" + }, + "publishers": { + "description": "Publisher names.", + "items": { + "type": "string" + }, + "type": "array" + }, + "title": { + "description": "Edition title.", + "type": "string" + }, + "work_id": { + "description": "Parent Work ID (OL…W). Use openlibrary_get_work for work-level metadata.", + "type": "string" + } + }, + "required": [ + "edition_id", + "title", + "authors", + "publishers", + "isbn_10", + "isbn_13", + "oclc", + "lccn", + "lc_classifications", + "cover_ids" + ], + "type": "object" + }, + "type": "array" +} - removed
Output schema / properties / isbn_10Removed value: -{ - "description": "ISBN-10 identifiers.", - "items": { - "type": "string" - }, - "type": "array" -} - removed
Output schema / properties / isbn_13Removed value: -{ - "description": "ISBN-13 identifiers.", - "items": { - "type": "string" - }, - "type": "array" -} - removed
Output schema / properties / languageRemoved value: -{ - "description": "3-letter ISO language code (e.g., \"eng\"). Absent when not recorded.", - "type": "string" -} - removed
Output schema / properties / lc_classificationsRemoved value: -{ - "description": "Library of Congress call numbers (e.g., \"TL685.7 .M366 2008\") — shelving classifications describing the subject, not identifiers. Not usable as a lookup value anywhere.", - "items": { - "type": "string" - }, - "type": "array" -} - removed
Output schema / properties / lccnRemoved value: -{ - "description": "Library of Congress Control Numbers (e.g., \"2008478952\") — lookupable identifiers; each one resolves this edition back through this tool with id_type \"lccn\".", - "items": { - "type": "string" - }, - "type": "array" -} - removed
Output schema / properties / oclcRemoved value: -{ - "description": "OCLC/WorldCat numbers.", - "items": { - "type": "string" - }, - "type": "array" -} - removed
Output schema / properties / page_countRemoved value: -{ - "description": "Page count. Absent when not recorded.", - "type": "number" -} - removed
Output schema / properties / publish_dateRemoved value: -{ - "description": "Publication date string. Absent when not recorded.", - "type": "string" -} - removed
Output schema / properties / publishersRemoved value: -{ - "description": "Publisher names.", - "items": { - "type": "string" - }, - "type": "array" -} - removed
Output schema / properties / titleRemoved value: -{ - "description": "Edition title.", - "type": "string" -} - added
Output schema / properties / unresolvedAdded value: +{ + "description": "Identifiers that produced no edition. Empty when every identifier resolved; never overlaps editions.", + "items": { + "additionalProperties": false, + "description": "An identifier that produced no edition.", + "properties": { + "identifier": { + "description": "The identifier as supplied, echoed so it can be matched to the request.", + "type": "string" + }, + "reason": { + "description": "\"invalid_identifier\" = the value cannot be this id_type and was never sent upstream. \"not_found\" = well-formed, but Open Library holds no edition under it.", + "enum": [ + "not_found", + "invalid_identifier" + ], + "type": "string" + } + }, + "required": [ + "identifier", + "reason" + ], + "type": "object" + }, + "type": "array" +} - removed
Output schema / properties / work_idRemoved value: -{ - "description": "Parent Work ID (OL…W). Use openlibrary_get_work for work-level metadata.", - "type": "string" -} - changed
Output schema / requiredPrevious value: -[ - "edition_id", - "title", - "authors", - "publishers", - "isbn_10", - "isbn_13", - "oclc", - "lccn", - "lc_classifications", - "cover_ids" -]New value: +[ + "editions", + "unresolved" +]
- Added
openlibrary_search_inside
3 tool updates
- Changed
openlibrary_get_subject1 field changed- changed
Input schema / properties / subject / descriptionPrevious value: -"Subject name. Spaces are converted to underscores internally (e.g., \"science fiction\" → \"science_fiction\"). Use lowercase for best results."New value: +"Subject name. Normalized before lookup — lowercased with spaces converted to underscores (e.g., \"Science Fiction\" → \"science_fiction\") — so varying case or spacing does not change the result."
- Changed
openlibrary_search_authors4 fields changed- changed
Output schema / properties / notice / descriptionPrevious value: -"Recovery guidance when no authors match — echoes the query and suggests alternatives. Absent when results are found."New value: +"Guidance when the page is empty (how to vary a name that matched nothing, or which offset to retry when offset ran past the end) or when the text output capped a per-author list. Absent when neither applies." - added
Output schema / properties / offsetAdded value: +{ + "description": "Zero-based offset of the first returned result — echoes the requested offset, so an empty page still records the offset that produced it.", + "type": "number" +} - changed
Output schema / properties / totalCount / descriptionPrevious value: -"Total matching authors across all pages. Absent when results are empty."New value: +"Total matching authors across all pages — the upstream match count, reported even when this page is empty because offset ran past the end." - changed
Output schema / requiredPrevious value: -[ - "total", - "authors" -]New value: +[ + "total", + "offset", + "authors" +]
- Changed
openlibrary_search_books3 fields changed- changed
Output schema / properties / notice / descriptionPrevious value: -"Recovery guidance when results are empty — echoes the search criteria and suggests how to broaden. Absent when results are found."New value: +"Guidance when the page is empty (how to broaden a query that matched nothing, or which offset to retry when offset ran past the end) or when the text output capped a per-work list. Absent when neither applies." - changed
Output schema / properties / totalCount / descriptionPrevious value: -"Total matching works across all pages. Absent when results are empty."New value: +"Total matching works across all pages — the upstream match count, reported even when this page is empty because offset ran past the end." - changed
Output schema / properties / works / items / properties / subjects / descriptionPrevious value: -"Up to 5 subject tags. Absent when no subjects are tagged."New value: +"Every subject tag the search index returned for this work. The text output caps the rendered list; this array is complete. Absent when no subjects are tagged. For the work record's own curated subject lists (places, times, people), use openlibrary_get_work."
2 tool updates
- Changed
openlibrary_get_edition6 fields changed- changed
Output schema / properties / authors / descriptionPrevious value: -"Authors of this edition."New value: +"Authors credited for this edition. Empty only when neither the edition nor its parent work records an author." - added
Output schema / properties / authors / items / properties / sourceAdded value: +{ + "description": "\"edition\" = the attribution is recorded on this edition record. \"work\" = the edition records no authors of its own and this credit comes from the parent work, which covers every edition of the same text.", + "enum": [ + "edition", + "work" + ], + "type": "string" +} - changed
Output schema / properties / authors / items / requiredPrevious value: -[ - "name" -]New value: +[ + "name", + "source" +] - added
Output schema / properties / lc_classificationsAdded value: +{ + "description": "Library of Congress call numbers (e.g., \"TL685.7 .M366 2008\") — shelving classifications describing the subject, not identifiers. Not usable as a lookup value anywhere.", + "items": { + "type": "string" + }, + "type": "array" +} - changed
Output schema / properties / lccn / descriptionPrevious value: -"Library of Congress Control Numbers."New value: +"Library of Congress Control Numbers (e.g., \"2008478952\") — lookupable identifiers; each one resolves this edition back through this tool with id_type \"lccn\"." - changed
Output schema / requiredPrevious value: -[ - "edition_id", - "title", - "authors", - "publishers", - "isbn_10", - "isbn_13", - "oclc", - "lccn", - "cover_ids" -]New value: +[ + "edition_id", + "title", + "authors", + "publishers", + "isbn_10", + "isbn_13", + "oclc", + "lccn", + "lc_classifications", + "cover_ids" +]
- Changed
openlibrary_search_books4 fields changed- changed
Input schema / properties / language / descriptionPrevious value: -"Two-letter ISO 639-1 language code (e.g., \"en\", \"fr\"). Influences but does not exclude results; use language:fr in query to hard-filter."New value: +"Restrict results to one language. Takes a 3-letter MARC code (e.g., \"eng\", \"fre\", \"ger\", \"chi\") — the same vocabulary openlibrary_get_edition and openlibrary_get_editions return. A 2-letter ISO 639-1 code (e.g., \"en\", \"fr\") is accepted and translated to its MARC equivalent; an unrecognized 2-letter code is rejected rather than silently ignored. The equivalent in-query form is language:eng." - added
Input schema / properties / language / patternAdded value: +"^[A-Za-z]{2,3}$" - changed
Output schema / properties / works / items / properties / ebook_access / descriptionPrevious value: -"\"public\" = freely readable. \"borrowable\" = borrow on Internet Archive. \"printdisabled\" = access for print-disabled users. \"no_ebook\" = no digital version."New value: +"\"public\" = freely readable. \"borrowable\" = borrow on Internet Archive. \"printdisabled\" = access for print-disabled users. \"no_ebook\" = no digital version. \"unclassified\" = a digital copy may exist but its access tier is not recorded." - changed
Output schema / properties / works / items / properties / ebook_access / enumPrevious value: -[ - "no_ebook", - "printdisabled", - "borrowable", - "public" -]New value: +[ + "no_ebook", + "unclassified", + "printdisabled", + "borrowable", + "public" +]
1 tool update
- Changed
openlibrary_get_work1 field changed- added
Output schema / properties / noticeAdded value: +{ + "description": "Disclosure when the text output caps a long list — names the omitted count and points to the complete array in structuredContent. Absent when nothing was capped.", + "type": "string" +}
5 tool updates
- Changed
openlibrary_get_author_works1 field changed- added
Output schema / properties / totalCountAdded value: +{ + "description": "Total works by this author across all pages.", + "type": "number" +}
- Changed
openlibrary_get_editions1 field changed- added
Output schema / properties / totalCountAdded value: +{ + "description": "Total editions for this work across all pages.", + "type": "number" +}
- Changed
openlibrary_get_subject1 field changed- added
Output schema / properties / totalCountAdded value: +{ + "description": "Total works tagged with this subject across all pages.", + "type": "number" +}
- Changed
openlibrary_search_authors1 field changed- added
Output schema / properties / totalCountAdded value: +{ + "description": "Total matching authors across all pages. Absent when results are empty.", + "type": "number" +}
- Changed
openlibrary_search_books1 field changed- added
Output schema / properties / totalCountAdded value: +{ + "description": "Total matching works across all pages. Absent when results are empty.", + "type": "number" +}
3 tool updates
- Changed
openlibrary_get_subject2 fields changed- removed
Output schema / properties / messageRemoved value: -{ - "description": "Recovery hint when work_count is 0 — echoes the subject and suggests alternatives. Absent when works are found.", - "type": "string" -} - added
Output schema / properties / noticeAdded value: +{ + "description": "Recovery guidance when work_count is 0 — echoes the subject and suggests alternatives. Absent when works are found.", + "type": "string" +}
- Changed
openlibrary_search_authors2 fields changed- removed
Output schema / properties / messageRemoved value: -{ - "description": "Recovery hint when results are empty. Absent when results are found.", - "type": "string" -} - added
Output schema / properties / noticeAdded value: +{ + "description": "Recovery guidance when no authors match — echoes the query and suggests alternatives. Absent when results are found.", + "type": "string" +}
- Changed
openlibrary_search_books3 fields changed- removed
Output schema / properties / messageRemoved value: -{ - "description": "Recovery hint when results are empty — echoes the search criteria and suggests how to broaden. Absent when results are found.", - "type": "string" -} - added
Output schema / properties / noticeAdded value: +{ + "description": "Recovery guidance when results are empty — echoes the search criteria and suggests how to broaden. Absent when results are found.", + "type": "string" +} - added
Output schema / properties / queryEchoAdded value: +{ + "description": "The effective search criteria as the server interpreted them — query string plus any active field filters. Absent when only a bare query is used.", + "type": "string" +}
9 tool updates
- First observed
openlibrary_get_author - First observed
openlibrary_get_author_works - First observed
openlibrary_get_cover_url - First observed
openlibrary_get_edition - First observed
openlibrary_get_editions - First observed
openlibrary_get_subject - First observed
openlibrary_get_work - First observed
openlibrary_search_authors - First observed
openlibrary_search_books
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
Related MCP Connectors
Search books and authors across Open Library, the Internet Archive open catalog.
Search MusicBrainz artists, releases, works, labels; resolve ISRC/ISWC/barcode; fetch cover art.
Books MCP — wraps Open Library API (free, no auth)
Scrape Open Library book editions, authors, subjects and identifiers. Pay per row.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceEnables searching for books by title, author, or keyword, retrieving edition details by ISBN, and accessing author profiles and canonical work records through the Open Library API.5MIT
- FlicenseNot gradedqualityAmaintenanceProvides a read-only API over a book catalogue, offering tools to search books, retrieve book details and series, and inspect provenance and source agreement data.-
- AlicenseNot gradedqualityCmaintenanceProvides access to BookBrainz open book metadata, enabling search, lookup, and browsing of works, editions, authors, publishers, and series via natural language or direct tool calls.15MIT
- AlicenseNot gradedqualityCmaintenanceEnables search and reading of Project Gutenberg books with tools for searching by title/author/subject and fetching word-range slices of book text.MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
Every tool targets a distinct resource-action pair: author lookup, author works, cover resolution, edition resolution by identifier, edition listing by work, subject browsing, work lookup, and three search types (authors, books, full-text). The only near-overlap is get_edition vs get_editions, but the descriptions clearly separate identifier-based resolution from listing editions of a work, and cross-references reinforce the distinction.
All tools follow a consistent snake_case verb_noun pattern: get_* for direct retrieval and search_* for query-based lookups. The single pair get_edition/get_editions is a natural pluralization, not an inconsistency. Naming is predictable and intuitive throughout.
Ten tools is an ideal size for a read-heavy library API. Each tool serves a distinct purpose (author, work, edition, subject, cover, three search modes) without redundancy or bloat. The surface feels deliberately scoped and not overwhelming.
The set covers the full read surface of Open Library: authors (get/search), works (get/search), editions (get by ID, list by work), subjects, covers, and full-text search. There are no obvious missing operations—all core entities and lookup paths are represented, and recoveries for missing data (e.g., author names) are built into descriptions.