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.4/5 across 9 of 9 tools scored.
All tools have clearly distinct purposes: get vs search, and each targets a specific entity (author, work, edition, subject, cover). Descriptions further clarify any potential overlap.
All tools follow the convention 'openlibrary_{verb}_{noun}' with 'get_' for lookups and 'search_' for queries, consistent throughout.
9 tools cover the core read operations of the Open Library domain without being excessive or insufficient.
Covers search and retrieval for authors, works, editions, subjects, and covers. Missing a direct edition search or subject list, 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds value by specifying the output fields and their purpose (drilling into editions/details), which goes beyond annotation disclosures.
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: first defines purpose and output, second provides sibling usage guidance. No redundant information, 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?
With an output schema present, return values need not be elaborated. The description covers the tool's role, connectivity to siblings, and leverages schema for param details, making it complete for this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear param descriptions (author_id prefix stripping, limit/offset bounds). The description does not add extra meaning beyond the schema, 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?
The description clearly states it lists works by an author and specifies the returned data (titles, cover IDs, work OLIDs). It also explicitly distinguishes from sibling tools openlibrary_get_author and openlibrary_get_editions, making the purpose 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?
The description provides clear context on when to use this tool versus siblings (e.g., for author bio use openlibrary_get_author, for editions use openlibrary_get_editions). It lacks explicit when-not scenarios but offers functional guidance.
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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, openWorldHint, and idempotentHint, which cover safety and idempotency. The description adds value by listing specific return fields (ISBNs, publisher, language, page count, edition OLIDs) and implying a read-only operation, consistent with annotations. 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?
The description is two sentences, front-loads the main action and return types, and contains no redundant information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, annotations cover behavioral aspects, and the input schema fully describes parameters, the description is complete for a list tool. It explains when to use it and what it returns, leaving no essential 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 description coverage is 100%, so baseline is 3. The description does not add significant per-parameter details beyond what the schema provides (e.g., work_id stripping, limit recommendation). The main contribution is contextual, not semantic enhancement of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'editions of a work', specifying the type of information returned (ISBNs, publisher, language, etc.). It distinguishes from siblings like openlibrary_get_edition (singular) and openlibrary_get_work by indicating it is a follow-up step.
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 states when to use the tool: 'Use after openlibrary_get_work or openlibrary_search_books to find a specific printing.' This provides clear context. While it does not list exclusions, the guidance is sufficient for selecting the tool among siblings.
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. |
| message | No | Recovery hint when work_count is 0 — echoes the subject and suggests alternatives. Absent when works are found. |
| 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?
Annotations already indicate readOnlyHint and openWorldHint. The description adds valuable behavioral details such as underscore conversion and tag inconsistency, which are beyond what annotations provide.
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, front-loaded with purpose, and every sentence adds value 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?
With an output schema present, the description adequately covers return values and behavioral aspects. Combined with annotations, it provides complete context for a browse 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% with detailed parameter descriptions. The description only repeats the lowercase advice for the subject parameter, adding minimal extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool browses works by subject and lists specific return fields (edition counts, cover IDs, total work count). It distinguishes from siblings like openlibrary_search_books, which performs search, and other get tools that target specific entities.
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 advises using lowercase first and warns about subject inconsistency. While it doesn't explicitly mention when not to use or alternatives, it provides clear contextual guidance.
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. |
| authors | Yes | Matching authors, up to limit. |
| message | No | Recovery hint when results are empty. Absent when results are found. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds context about the returned fields, which is more than the schema provides. No contradictions or missing behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences that front-load the purpose and return data, then provide usage guidance. No unnecessary words, every sentence adds value.
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?
Combined with schema descriptions and annotations, the description is complete: it covers purpose, output fields, usage flow, and requires no additional elaboration for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters with clear explanations (e.g., 'Partial names and alternate names work' for query). The tool description does not add further parameter semantics, 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?
The description clearly states it searches authors by name and lists the specific data returned (IDs, names, dates, top works, subject associations). It differentiates from sibling tools by mentioning how results can be used with 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?
The description implicitly tells when to use (searching for authors by name) and explicitly points to follow-up tools using returned author IDs. However, it lacks explicit guidance on when not to use this tool versus alternatives.
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. |
| offset | Yes | Zero-based offset of the first returned result. |
| message | No | Recovery hint when results are empty — echoes the search criteria and suggests how to broaden. Absent when results are found. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint and openWorldHint. The description goes beyond by specifying the search is full-text, supports field filters, returns work-level records with edition counts/cover IDs, and notes the latency cost of include_availability. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences. It front-loads the core purpose, briefly explains usage, and ends with a note about work-level results and a sibling tool. No unnecessary words or 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 need not detail return structure. It covers what results contain (edition counts, cover IDs, reading availability), mentions latency for a specific parameter, and points to the sibling tool for more detail. All relevant context is provided.
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 each parameter's meaning is already clear from the schema. The description adds a general overview but does not significantly enhance parameter understanding beyond what the schema provides. Baseline of 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 it is a full-text book search across Open Library works, supports specific field filters, and returns work-level records. It distinguishes from sibling tool openlibrary_get_editions by noting that results are work-level and editions can be drilled into separately.
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 when to use the query parameter for general search vs. specific field filters. It implicitly suggests using openlibrary_get_editions for edition-level data. However, it does not explicitly mention when not to use this tool or compare with other search tools like openlibrary_search_authors.
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!