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
- 1
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 9 of 9 tools scored.
Each tool targets a distinct resource (author, author works, cover URL, edition, editions, subject, work, search authors, search books) with clear boundaries. Cross-references in descriptions further reduce ambiguity.
All tools follow a consistent 'openlibrary_<verb>_<resource>' pattern with snake_case. Verbs are uniformly 'get' for fetches and 'search' for queries, making the pattern predictable.
9 tools is well-scoped for a book metadata API. It covers the essential entities and search without being overwhelming or insufficient.
The set provides comprehensive read-only access to authors, works, editions, subjects, and search. Minor gaps include lack of direct work-by-ID search (though get_work covers it) and no batch operations, but core workflows are supported.
Available Tools
9 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 | Yes | Primary author name. |
| author_id | Yes | Canonical Open Library Author ID (OL…A). |
| photo_ids | Yes | 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 | Yes | 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent behavior. The description adds the specific data fields returned, providing useful context beyond the 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 fluff. The first explains the function and return fields, the second provides usage guidance. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotations (readOnlyHint, idempotentHint, openWorldHint) and full schema coverage plus an output schema, the description is sufficient. It mentions key return fields and does not need to detail structure.
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 single parameter 'author_id' is fully documented in the schema with format and prefix stripping details. The description does not add extra semantic value beyond that.
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 fetches author details by a specific Open Library Author ID and lists the types of data returned (bio, dates, photos, identifiers). It distinguishes itself from siblings like openlibrary_search_authors and openlibrary_get_author_works.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent to use openlibrary_search_authors first to find an author ID, which clearly defines when this tool should be used (only with a known author ID).
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 |
|---|---|---|
| total | Yes | Total works by this author. |
| works | Yes | Works by this author, up to limit. |
| author_id | Yes | Open Library Author ID. |
| totalCount | No | Total works by this author across all pages. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds that the tool returns titles, cover IDs, and work OLIDs, plus hints at further drilling. No contradictions, and it provides useful context beyond the 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 concise sentences that front-load the main purpose and immediately provide sibling guidance. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and clear sibling descriptions, the description covers all essential information: what it does, what it returns, and when to use alternatives. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The description does not add additional meaning beyond what the schema already provides, so it meets the baseline expectation.
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 'List works by an author' with a specific verb and resource. It explicitly distinguishes from siblings by naming openlibrary_get_author and openlibrary_get_editions as alternatives for different purposes.
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 guidance: 'Use openlibrary_get_author for author bio and details, or openlibrary_get_editions to explore specific printings.' This tells the agent not to use this tool for those tasks.
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. 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. 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". |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | 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 | Yes | Reminder that the URL always returns HTTP 200; a placeholder GIF is served when no cover exists. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds key behavioral details beyond annotations: always returns HTTP 200 with placeholder for missing covers, URLs embeddable in markdown. Annotations already declare read-only and idempotent, so description enriches understanding.
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 concise sentences with no fluff. Purpose, behavior, and practical use are front-loaded and clear.
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 exists for return values. Description covers all necessary behavioral aspects (placeholder behavior, embeddability) and parameter nuances. Complete for a cover URL retrieval tool.
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?
100% schema coverage provides baseline 3. Description adds significant meaning: explains size pixel heights, target URLs, id_type usage examples, identifier format details. Greatly aids parameter selection.
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?
Describes a specific action: resolving a cover image URL for a book or author photo. Clearly distinguishes from sibling tools that fetch metadata, not images.
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?
Implied usage for obtaining cover images, but lacks explicit when-not-to-use or comparison with sibling tools. However, context signals show siblings are data retrieval tools, making usage clear enough.
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
Fetch a single edition by identifier: ISBN-10, ISBN-13, OCLC, LCCN, or Open Library Edition ID (OL…M). Returns full edition metadata including authors, publisher, language, all identifier types, and the parent work ID. Use for ISBN lookups — pass id_type "isbn" for both ISBN-10 and ISBN-13.
| Name | Required | Description | Default |
|---|---|---|---|
| id_type | Yes | Identifier type. "isbn" handles both ISBN-10 and ISBN-13. "olid" is the native Open Library edition ID (OL…M). | |
| identifier | Yes | 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). |
Output Schema
| Name | Required | Description |
|---|---|---|
| lccn | Yes | Library of Congress Control Numbers. |
| oclc | Yes | OCLC/WorldCat numbers. |
| title | Yes | Edition title. |
| authors | Yes | Authors of this edition. |
| isbn_10 | Yes | ISBN-10 identifiers. |
| isbn_13 | Yes | ISBN-13 identifiers. |
| work_id | No | Parent Work ID (OL…W). Use openlibrary_get_work for work-level metadata. |
| language | No | 3-letter ISO language code (e.g., "eng"). Absent when not recorded. |
| cover_ids | Yes | Numeric cover IDs for openlibrary_get_cover_url. |
| ebook_url | No | Internet Archive URL for reading/borrowing. Present when an IA item exists. |
| edition_id | Yes | Open Library Edition ID (OL…M). |
| page_count | No | Page count. Absent when not recorded. |
| publishers | Yes | Publisher names. |
| description | No | Edition description. Absent when not provided. |
| publish_date | No | Publication date string. Absent when not recorded. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, and idempotent. The description adds value by detailing returned fields (authors, publisher, language, identifiers, parent work ID) and identifier handling (hyphens stripped, formats). No contradictions.
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 short sentences: first gives purpose and returns, second provides usage guidance. No wordiness, clear front-loading.
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 simple tool with 2 required params, full schema descriptions, annotations, and an output schema (existing), the description covers purpose, identifier types, return fields, and a usage hint. Fully adequate.
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%, and both parameters have detailed descriptions in the schema. The description adds minimal new meaning, mainly reiterating the ISBN usage hint. 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?
The description clearly states the tool fetches a single edition by multiple identifier types, listing ISBN-10, ISBN-13, OCLC, LCCN, and OLID. It distinguishes from sibling 'openlibrary_get_editions' by specifying 'single edition' and detailing returned metadata.
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 explicitly recommends using this tool for ISBN lookups and explains how to pass the id_type parameter. However, it does not compare with siblings like 'openlibrary_get_editions' for multiple editions, limiting exclusion guidance.
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 |
|---|---|---|
| total | Yes | Total editions for this work. |
| work_id | Yes | Open Library Work ID. |
| editions | Yes | Editions of the work, up to limit. |
| totalCount | No | Total editions for this work across all pages. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds value by listing the returned fields (ISBNs, publisher, language, page count, edition OLIDs) and confirming the listing action, which is consistent with the annotations. No contradiction.
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 wasted words. First sentence front-loads purpose and return data; second sentence provides usage workflow. Highly efficient.
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 listing tool with an output schema, the description covers the core action, return structure, and usage context. Pagination details are in the schema. Slightly more detail on the nature of the list (e.g., potentially large) could improve completeness, but overall it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for all parameters. The description adds marginal value by implying work_id comes from previous tools, but otherwise does not enhance parameter understanding beyond the schema's own documentation. 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?
The description clearly states the verb 'List' and resource 'editions of a work', and specifies return fields (ISBNs, publisher, etc.). It distinguishes from the sibling 'openlibrary_get_edition' (singular) by focusing on multiple editions, and from other sibling tools via the 'work' context.
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 explicitly advises 'Use after openlibrary_get_work or openlibrary_search_books to find a specific printing', providing clear workflow context. However, it does not explicitly exclude alternatives (e.g., using get_edition for a single edition), so it stops short of a full 5.
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. Subjects are user-contributed and may be inconsistent ("science fiction", "Science fiction", "SF" are separate tags). Try lowercase forms first.
| 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. Spaces are converted to underscores internally (e.g., "science fiction" → "science_fiction"). Use lowercase for best results. |
Output Schema
| Name | Required | Description |
|---|---|---|
| works | Yes | 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 | Yes | Total works tagged with this subject. |
| subject_key | Yes | Normalized subject key (lowercase, underscores). |
| subject_name | Yes | Canonical subject name as stored on Open Library. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), the description discloses behavioral traits such as user-contributed subject inconsistency and space-to-underscore conversion. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no unnecessary words. It front-loads the main purpose and adds essential usage hints without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (indicated in context), the description does not need to detail return values. It covers query construction, inconsistency warning, and pagination defaults, making it complete for a read-only browsing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by explaining space-to-underscore conversion for 'subject' and typical display count for 'limit'. This supplements the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Browse works by subject') and specifies what is returned (matching works with edition counts and cover IDs, plus total work count). It distinguishes from sibling tools focused on authors, editions, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on subject inconsistency and suggests trying lowercase forms first. It does not explicitly list when not to use or name alternatives, but the sibling list and context imply its scope.
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 |
|---|---|---|
| title | Yes | Work title. |
| created | No | ISO 8601 creation timestamp. Absent when not available. |
| work_id | Yes | Canonical Open Library Work ID (OL…W). |
| subjects | Yes | Subject tags for this work. |
| cover_ids | Yes | Numeric cover IDs. Pass to openlibrary_get_cover_url with id_type "id". |
| author_ids | Yes | 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 | Yes | Time period subjects. |
| subject_people | Yes | People subjects. |
| subject_places | Yes | Geographic subjects. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds significant value beyond annotations by specifying exact return fields (title, description, subjects, cover IDs, linked author IDs) and noting that author names are omitted. No contradiction with readOnlyHint and idempotentHint.
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 well-structured sentences. First sentence front-loads purpose and return fields; second provides clarification and cross-references. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description is complete: it covers purpose, identifier, return fields, limitations, and sibling tools. No gaps given the tool's simplicity and thorough annotations.
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?
Input schema has 100% coverage with detailed description of work_id format and prefix stripping. The description does not add further parameter semantics beyond what the schema provides, so 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?
Description clearly states 'Fetch a work by Open Library Work ID' with a specific resource (work) and identifier format (OL…W). It distinguishes from siblings by mentioning what it does not include (author names) and directing to other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (to fetch work details) and when not (if author names needed, use other tools). Also clarifies that works are abstract concepts, providing context for appropriate use.
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 |
|---|---|---|
| total | Yes | Total matching authors across all pages. |
| notice | No | Recovery guidance when no authors match — echoes the query and suggests alternatives. Absent when results are found. |
| authors | Yes | Matching authors, up to limit. |
| totalCount | No | Total matching authors across all pages. Absent when results are empty. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint; description adds context on return values but does not contradict 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, no filler, essential information front-loaded.
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 output schema present, the description adequately covers purpose, usage, and behavioral context for a search tool.
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 has 100% parameter description coverage, so description adds little beyond listing return fields. Appropriate baseline scoring.
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?
Clearly states it searches authors by name and lists return fields (IDs, names, dates, works, subjects). Distinguishes from sibling tools openlibrary_get_author and openlibrary_get_author_works.
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 provides when to use this tool and directs to siblings for specific follow-ups (bio, works list).
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 | 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. | |
| 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 |
|---|---|---|
| total | Yes | Total matching works across all pages. |
| works | Yes | Matching works, up to limit. |
| notice | No | Recovery guidance when results are empty — echoes the search criteria and suggests how to broaden. Absent when results are found. |
| offset | Yes | 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. Absent when results are empty. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and openWorld. Description adds useful behavioral details: include_availability adds ~200ms latency, and language filter is soft unless using query prefix. No contradictions.
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 concise sentences, front-loaded with core purpose, then usage guidance, then sibling pointer. No wasted 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?
Covers all key aspects given complexity (11 params, 0 required, output schema exists). Mentions work-level results and direction to editions for deeper data. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so baseline is 3. Description adds value by explaining the purpose of query vs field filters, summarizing filter types, and noting the latency trade-off of include_availability.
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?
Clearly states 'Full-text book search across Open Library works' and lists supported filters and return fields. Contrasts with sibling tools like openlibrary_get_editions that drill into editions.
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 advises when to use query versus field filters and points to openlibrary_get_editions for edition-level detail. Provides clear context for when to use the tool vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!