Skip to main content
Glama
deenesjakoruzh
8enSmith

mcp-open-library

by 8enSmith
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

MCP Open Library

MCP Registry Socket Badge Trust Score Listed on Spark NPM

A Model Context Protocol (MCP) server for the Open Library API that enables AI assistants to search for book and author information.

Overview

This project implements an MCP server that provides tools for AI assistants to interact with the Open Library. It allows searching the catalogue by title, author, subject and other fields, searching for authors by name, retrieving detailed author information using their Open Library key, and getting URLs for book covers and author photos. The server returns JSON projections of the Open Library responses rather than the raw payloads.

Related MCP server: bookstore-mcp-server

Features

  • Book Search: Search across titles, authors, subjects, places, people, publishers and ISBNs, with sorting and paging (search_books).

  • Book Search by Title: Search for books using their title (get_book_by_title).

  • Author Search by Name: Search for authors using their name, with paging (get_authors_by_name).

  • Get Author Details: Retrieve detailed information for a specific author using their Open Library key (get_author_info).

  • Get Author Photo: Get the URL for an author's photo using their Open Library ID (OLID) (get_author_photo).

  • Get Book Cover: Get the URL for a book's cover image using various identifiers (ISBN, OCLC, LCCN, OLID, ID) (get_book_cover).

  • Get Book by ID: Retrieve detailed book information using various identifiers (ISBN, LCCN, OCLC, OLID) (get_book_by_id).

Search results are paged — every search tool returns at most limit results (default 10, maximum 50) alongside num_found, the total number of matches, which you page through with offset (maximum 1000). The two cover tools check that an image actually exists and say so when it does not, rather than handing back a URL that resolves to a blank placeholder.

Every tool is a read-only lookup and advertises itself as such with the readOnlyHint and openWorldHint annotations, which may allow a client to skip the confirmation prompt it shows for tools that could change something. These are hints: the MCP specification has clients treat annotations as untrusted unless the server is trusted, so the confirmation policy is the client's to decide. Failures — an unreachable API, a rejected argument — come back as a tool result flagged isError, so an assistant can read what went wrong and correct its next call rather than the request failing outright.

Installation

Quick Start

Nothing to install or build. Point an MCP client at the package with npx and it will be fetched on first run:

{
  "mcpServers": {
    "mcp-open-library": {
      "command": "npx",
      "args": ["-y", "mcp-open-library"]
    }
  }
}

In Claude Desktop that goes in claude_desktop_config.json; other clients use the same shape. Restart the client and the seven tools below become available.

MCP Registry

This server publishes to the official MCP Registry as io.github.8enSmith/mcp-open-library from v1.0.3 onwards. Clients that support the registry can install it by that name.

To inspect the published listing:

curl "https://registry.modelcontextprotocol.io/v0.1/servers?search=io.github.8enSmith/mcp-open-library"

Manual Installation

# Clone the repository
git clone https://github.com/8enSmith/mcp-open-library.git
cd mcp-open-library

# Install dependencies
npm install

# Build the project
npm run build

Usage

Running the Server

  1. Ensure you are running node v22.21.1 (it'll probably work on a newer version of node but this is what Im using for this test). If you have nvm installed run nvm use.

  2. In the mcp-open-library root directory run npm run build

  3. Next run npm run inspector. Once built, click the URL with the MCP_PROXY_AUTH_TOKEN query string parameter to open the Inspector.

  4. In the Inspector, choose 'STDIO' transport

  5. Make sure the command is set to 'build/index.js'

  6. Click the 'Connect' button in the Inspector - you'll now connect to the server

  7. Click 'Tools' in the top right menu bar

  8. Try running a tool e.g. click get_book_by_title

  9. Search for a book e.g. In the title box enter 'The Hobbit' and then click 'Run Tool'. Server will then return book details.

Using with an MCP Client

This server implements the Model Context Protocol, which means it can be used by any MCP-compatible AI assistant or client e.g. Claude Desktop. The server exposes the following tools:

  • search_books: Search the catalogue by any combination of query, title, author, subject, place, person, publisher and ISBN

  • get_book_by_title: Search for book information by title

  • get_authors_by_name: Search for author information by name

  • get_author_info: Get detailed information for a specific author using their Open Library Author Key

  • get_author_photo: Get the URL for an author's photo using their Open Library Author ID (OLID)

  • get_book_cover: Get the URL for a book's cover image using a specific identifier (ISBN, OCLC, LCCN, OLID, or ID)

  • get_book_by_id: Get detailed book information using a specific identifier (ISBN, LCCN, OCLC, or OLID)

Example search_books input:

{
  "author": "Ursula K. Le Guin",
  "subject": "fantasy",
  "sort": "old",
  "limit": 2
}

Example search_books output:

{
  "num_found": 51,
  "offset": 0,
  "limit": 2,
  "results": [
    {
      "title": "A Wizard of Earthsea",
      "authors": ["Ursula K. Le Guin"],
      "first_publish_year": 1968,
      "open_library_work_key": "/works/OL59798W",
      "edition_count": 87,
      "author_keys": ["OL31353A"],
      "best_edition": {
        "edition_key": "OL5613890M"
      },
      "cover_url": "https://covers.openlibrary.org/b/id/13617691-M.jpg",
      "ratings_average": 3.95,
      "ebook_access": "borrowable"
    }
  ]
}

best_edition is one specific edition of the work — the one Open Library ranks best for your query — carrying that edition's own identifiers. Search results otherwise identify a work (open_library_work_key), which no tool accepts, so this is the route from a search hit to a concrete book.

Its edition_key is an OLID you can pass straight to get_book_by_id for the full edition record, including its complete ISBN arrays:

{ "idType": "olid", "idValue": "OL5613890M" }

The isbn_13 / isbn_10 fields are omitted where Open Library holds no ISBN for that edition — as in the example above, and roughly a third of results — while edition_key is essentially always present. Where an edition lists several ISBNs of one kind, the first is reported; get_book_by_id returns them all.

The search_books tool accepts the following parameters:

  • At least one of q, title, author, subject, place, person, publisher or isbn — the request is rejected without one, since an unfiltered search matches the entire catalogue. q takes a free-form Solr query such as subject:cyberpunk AND first_publish_year:[1980 TO 1990]

  • language: Optional 3-letter MARC language code (e.g. eng, fre)

  • sort: Optional ordering — new, old, random, key, rating, readinglog, want_to_read, currently_reading, already_read or title. Omit for relevance

  • limit: Optional, 1–50, defaults to 10

  • offset: Optional, 0–1000, defaults to 0

Example get_book_by_title input:

{
  "title": "The Hobbit",
  "limit": 1
}

Example get_book_by_title output:

{
  "num_found": 224,
  "offset": 0,
  "limit": 1,
  "results": [
    {
      "title": "The Hobbit",
      "authors": ["J.R.R. Tolkien"],
      "first_publish_year": 1937,
      "open_library_work_key": "/works/OL27482W",
      "edition_count": 481,
      "author_keys": ["OL26320A"],
      "best_edition": {
        "edition_key": "OL51709286M",
        "isbn_13": "9780395520215",
        "isbn_10": "0395520215"
      },
      "cover_url": "https://covers.openlibrary.org/b/id/14627509-M.jpg",
      "ratings_average": 4.29,
      "ebook_access": "borrowable"
    }
  ]
}

Example get_authors_by_name input:

{
  "name": "J. R. R. Tolkien",
  "limit": 2
}

Example get_authors_by_name output:

Each result's key can be passed to get_author_info for that author's full record. alternate_names is abridged here.

{
  "num_found": 2,
  "offset": 0,
  "limit": 2,
  "results": [
    {
      "key": "OL26320A",
      "name": "J.R.R. Tolkien",
      "alternate_names": ["John Ronald Reuel Tolkien", "Tolkien"],
      "birth_date": "3 January 1892",
      "top_work": "The Hobbit",
      "work_count": 355
    },
    {
      "key": "OL332676A",
      "name": "J. R. R. Tolkien Centenary Conference (1992 Keble College, Oxford)",
      "top_work": "Proceedings of the J.R.R. Tolkien Centenary Conference, 1992",
      "work_count": 2
    }
  ]
}

Example get_author_info input:

{
  "author_key": "OL26320A"
}

Example get_author_info output:

{
  "name": "J. R. R. Tolkien",
  "personal_name": "John Ronald Reuel Tolkien",
  "birth_date": "3 January 1892",
  "death_date": "2 September 1973",
  "bio": "John Ronald Reuel Tolkien (1892-1973) was a major scholar of the English language, specializing in Old and Middle English. He served as the Rawlinson and Bosworth Professor of Anglo-Saxon and later the Merton Professor of English Language and Literature at Oxford University.",
  "alternate_names": ["John Ronald Reuel Tolkien"],
  "photos": [6791763],
  "key": "/authors/OL26320A",
  "remote_ids": {
    "viaf": "95218067",
    "wikidata": "Q892"
  },
  "revision": 43,
  "last_modified": {
    "type": "/type/datetime",
    "value": "2023-02-12T05:50:22.881"
  }
}

Example get_author_photo input:

{
  "olid": "OL26320A"
}

Example get_author_photo output:

https://covers.openlibrary.org/a/olid/OL26320A-L.jpg

When Open Library has no photo for that author, the tool says so instead of returning a URL:

No author photo available for OLID OL99999999A.

Example get_book_cover input:

{
  "key": "ISBN",
  "value": "9780547928227",
  "size": "L"
}

Example get_book_cover output:

https://covers.openlibrary.org/b/isbn/9780547928227-L.jpg

As with author photos, a book with no cover produces a message rather than a URL:

No cover image available for OLID OL00000000M.

The get_book_cover tool accepts the following parameters:

  • key: The type of identifier (one of: ISBN, OCLC, LCCN, OLID, or ID)

  • value: The value of the identifier

  • size: Optional cover size (S for small, M for medium, L for large, defaults to L)

Example get_book_by_id input:

{
  "idType": "isbn",
  "idValue": "9780547928227"
}

Example get_book_by_id output:

{
  "title": "The Hobbit",
  "authors": [
    "J. R. R. Tolkien"
  ],
  "publishers": [
    "Houghton Mifflin Harcourt"
  ],
  "publish_date": "October 21, 2012",
  "number_of_pages": 300,
  "isbn_13": [
    "9780547928227"
  ],
  "isbn_10": [
    "054792822X"
  ],
  "oclc": [
    "794607877"
  ],
  "olid": [
    "OL25380781M"
  ],
  "open_library_edition_key": "/books/OL25380781M",
  "open_library_work_key": "/works/OL45883W",
  "cover_url": "https://covers.openlibrary.org/b/id/8231496-M.jpg",
  "info_url": "https://openlibrary.org/books/OL25380781M/The_Hobbit",
  "preview_url": "https://archive.org/details/hobbit00tolkien"
}

The get_book_by_id tool accepts the following parameters:

  • idType: The type of identifier (one of: isbn, lccn, oclc, olid)

  • idValue: The value of the identifier

An example of this tool being used in Claude Desktop can be see here:

Docker

You can test this MCP server using Docker. To do this first run:

docker build -t mcp-open-library .
docker run -p 8080:8080 mcp-open-library

You can then test the server running within Docker via the inspector e.g.

npm run inspector http://localhost:8080

Development

Project Structure

  • src/index.ts - The MCP server: builds the HTTP clients and drives both request handlers from the tool registry

  • src/index.test.ts - Tests for the server wiring, including a snapshot of the published tool schemas

  • src/tools/<tool-name>/ - One directory per tool, each containing index.ts (the handler, its Zod argument schema and its ToolDefinition), index.test.ts, and — for tools with a non-trivial API response — a types.ts describing that response shape

  • src/tools/registry.ts - The TOOLS array, the single list of what the server exposes

  • src/tools/types.ts - The ToolDefinition and ToolHandler contracts

  • src/utils/ - Shared plumbing: http.ts (the API and covers Axios clients), errors.ts (argument parsing and error results), results.ts, schema.ts (Zod → JSON Schema), search.ts (the shared search projection and paging schemas), covers.ts

  • scripts/ - Release automation (sync-server-json.mjs, promote-changelog.mjs, assert-release-consistency.mjs) and its tests

A tool's input contract is declared once, as a Zod schema. The JSON Schema that MCP clients see is generated from it by toInputSchema, so the two cannot drift. Field descriptions come from .describe() on the Zod schema. Note that .refine() constraints are dropped in translation — a cross-field rule has to be stated in the tool's description too, or clients will never learn about it.

Adding a tool means creating the directory and adding one entry to TOOLS in src/tools/registry.ts. src/index.test.ts derives its expectations from that array, so the only test change is an updated schema snapshot (npx vitest run -u).

Available Scripts

  • npm run build - Build the TypeScript code

  • npm run watch - Watch for changes and rebuild

  • npm test - Run the test suite in watch mode

  • npm run test:precommit - Run the test suite once and exit

  • npm run lint / npm run lint:fix - Lint src and scripts with ESLint

  • npm run format - Format code with Prettier

  • npm run inspector - Run the MCP Inspector against the server

Running Tests

npm test starts Vitest in watch mode:

npm test

For a single pass — what the pre-commit hook and CI run — use:

npm run test:precommit

To run one file or one test case:

npx vitest run src/tools/get-book-by-id/index.test.ts
npx vitest run -t "should return book details when given a valid OLID"

Releasing

Releases are automated. Pushing a v* tag triggers publish-mcp.yml, which runs the checks, publishes the package to npm, registers the new version with the MCP Registry, and then creates a GitHub Release using that version's CHANGELOG.md section as the notes. Both npm and the registry authenticate over GitHub OIDC, so there are no publishing secrets to manage.

package.json's version is the single source of truth. npm version derives everything else from it via a version lifecycle hook, so a release is one command:

npm version patch   # or minor / major
git push --follow-tags

That single command bumps package.json, rewrites server.json to match, promotes the changelog's ## [Unreleased] heading to the new version and today's date, and commits the lot under one tag.

Two things to know before you run it:

  • Write your changelog entries first. They go under a ## [Unreleased] heading in CHANGELOG.md as you merge work. npm version fails if that heading is missing, rather than releasing something undocumented. If it does fail, undo the partial bump with git restore --source=HEAD --staged --worktree package.json package-lock.json server.json.

  • The working tree must be clean, and the pre-commit hook (lint + full test suite) runs inside npm version.

CI re-asserts that the tag, package.json, server.json and CHANGELOG.md all agree before anything is published — see scripts/assert-release-consistency.mjs. The same check runs on pull requests that touch those files.

npm version is not a retry

Once it prints the new tag, the commit and tag exist and the release is done locally — the next step is git push --follow-tags, not running npm version again. A second run attempts the next version, and will fail on the missing ## [Unreleased] heading (which the first run consumed). That failure is safe by design, but it leaves package.json, package-lock.json and server.json bumped and uncommitted. Undo with:

git restore --source=HEAD --staged --worktree package.json package-lock.json server.json

If the publish workflow fails

Re-running the job from the Actions tab only helps for a transient failure. GitHub runs the workflow as it existed at the tagged commit, so a bug in the workflow itself or in server.json cannot be fixed by a re-run — the fix has to be in the commit the tag points at.

Nothing is published until the workflow reaches its npm step, so if it failed before then, the version is still free and you can move the tag:

# fix the problem on main and commit it first
VERSION="$(node -p "require('./package.json').version")"

git push origin ":v${VERSION}"            # delete the remote tag e.g. git push origin :v1.0.3
git tag -d "v${VERSION}"                  # delete it locally
git tag -a "v${VERSION}" -m "${VERSION}"  # re-tag at the fixed commit
git push origin "v${VERSION}"

The fix commit must leave package.json on that same version, or the consistency check will reject the tag. If npm did already publish, do not reuse the version — that release is immutable. Bump to the next patch instead; the guarded npm step means a re-run skips what already succeeded.

Contributing

Contributions are welcome! Please feel free to submit a pull request.

Acknowledgments

Available Tools

7 tools
get_author_infoGet author detailsA
Read-only

Get detailed information for a specific author using their Open Library Author Key (e.g. OL23919A).

ParametersJSON Schema
NameRequiredDescriptionDefault
author_keyYesThe Open Library key for the author (e.g., OL23919A).

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds little beyond that—just the example key format which is already in schema. No mention of error handling, return structure, or edge cases. With annotations providing the safety profile, a score of 3 is appropriate as it adds minimal behavioral context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, clear and direct, no fluff. Front-loaded with the action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple: one parameter, safe read operation, no output schema. The description provides sufficient context for basic use, but could specify what 'detailed information' includes or mention error behavior. However, given the simplicity, it's fairly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers the parameter fully with description and pattern. Description repeats the example but adds no new semantic information. With 100% schema description coverage, baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the resource 'detailed information for a specific author' using the Open Library key. It distinguishes from siblings like get_book_by_id and get_authors_by_name by focusing on the author key lookup.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when a known author key is available, but it does not explicitly mention when to use this vs. alternatives like get_authors_by_name. It provides context (the key) but no exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_author_photoGet author photo URLA
Read-only

Get the URL for an author's photo using their Open Library Author ID (OLID e.g. OL23919A). Reports when no photo exists rather than returning a URL to a blank placeholder.

ParametersJSON Schema
NameRequiredDescriptionDefault
olidYesThe Open Library Author ID (OLID) for the author (e.g. OL23919A).

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true and openWorldHint=true, indicating safe read and possible missing data. The description adds that it reports when no photo exists, which aligns with openWorldHint and provides meaningful behavioral context beyond the annotations. This handles the missing photo case explicitly, which is valuable for agents.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loaded with the core function ('Get the URL'), and each sentence provides essential detail (ID format and missing-photo behavior). No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (single param, no output schema), the description is highly complete. It covers the purpose, the ID, and the edge case of missing photosabbia. While it doesn't mention return format, the lack of output schema means it's not required, and annotations cover safety aspects.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema coverage is 100% and the schema already describes the olid parameter. The description's example (OL23919A) reinforces the format and makes it clearer for agents, adding value beyond the schema. This is effectively a baseline 3 with a bonus for the example, and given the high coverage, it's sufficient.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it gets the URL for an author's photo, specifying the resource (author's photo) and the required identifier (OLID), and even includes an example. It distinguishes itself from siblings like get_author_info and get_book_cover by focusing specifically on photo URLs and handling missing photos.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use this tool (when needing an author's photo URL) and provides guidance on the ID format, but it does not explicitly state when not to use it or mention alternatives. Since there are sibling tools like get_author_info that might also provide photo info, explicit exclusions would help, but the context is clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_authors_by_nameFind authors by nameA
Read-only

Search for author information on Open Library. Returns at most limit authors (default 10) together with num_found, the total number of matches; page through them with offset. Each result's key can be passed to get_author_info for that author's full record.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesThe name of the author to search for.
limitNoMaximum number of results to return (1-50, default 10).
offsetNoNumber of results to skip, for paging through the total reported as num_found (0-1000, default 0).

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and openWorldHint, and the description adds useful behavioral details: result cap, default limit, total match count via num_found, and pagination behavior. It does not mention rate limits or auth, but for a read-only search tool the disclosed behavior is sufficient and 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences contain all essential information: search scope, result cap, default, total count, pagination, and integration with a sibling tool. Every phrase earns its place with no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with three parameters and no output schema. The description fully compensates for the lack of an output schema by explaining the return shape, count field, pagination parameters, and next-step usage with get_author_info. It is complete for an agent to select and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema by explaining how limit and offset interact with pagination, defining num_found, and showing how the returned key connects to get_author_info. This adds value rather than just restating schema fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action: 'Search for author information on Open Library.' It clearly identifies the resource (authors) and distinguishes itself from sibling tools like get_author_info and search_books by describing a list-returning search behavior with pagination.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear usage context: it returns a list up to a limit, supports pagination via offset, and explicitly tells the agent to pass a result's key to get_author_info for the full record. It does not explicitly state when not to use this tool versus alternatives, but the follow-up instruction provides practical guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_book_by_idGet book by identifierA
Read-only

Get detailed information about a book using its identifier (ISBN, LCCN, OCLC, OLID).

ParametersJSON Schema
NameRequiredDescriptionDefault
idTypeYesThe type of identifier used (isbn, lccn, oclc, olid). Case-insensitive.
idValueYesThe value of the identifier.

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already disclose readOnlyHint=true and openWorldHint=true, covering the core safety profile. The description adds only the vague promise of 'detailed information' and does not disclose response structure, error behavior, or identifier-format nuances, though it does not contradict 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with a clear verb and resource. It contains no wasted words and efficiently conveys the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter lookup with full schema coverage and relevant annotations, the description is adequate. It does not detail the return shape, but this is a minor gap given the tool's simplicity and the absence of an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with both parameters fully documented including the idType enum and case-insensitivity. The description merely restates the identifier types that are already present in the enum, adding no new semantic detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get'), identifies the resource ('detailed information about a book'), and specifies the lookup method ('using its identifier'). This clearly differentiates it from sibling tools like get_book_by_title or search_books.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly implies the tool should be used when an identifier (ISBN, LCCN, OCLC, or OLID) is available. It does not explicitly name alternatives or exclusions, but the identifier-based context is sufficient to guide selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_book_by_titleFind books by titleA
Read-only

Search for a book by its title on Open Library. Returns at most limit results (default 10) together with num_found, the total number of matches; page through them with offset. Each result carries best_edition — one edition of the work, with its isbn_13/isbn_10 where Open Library has them, and its edition_key, which can be passed to get_book_by_id as { idType: "olid" } for that edition's full record.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of results to return (1-50, default 10).
titleYesThe title of the book to search for.
offsetNoNumber of results to skip, for paging through the total reported as num_found (0-1000, default 0).

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only and open-world behavior, so the description adds value by explaining pagination mechanics (limit, offset, num_found) and result structure (best_edition with ISBNs and edition_key). This goes beyond the schema to give a clear mental model of the tool's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with the core purpose, and each subsequent sentence adds meaningful operational detail. No redundant or promotional language.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description does a good job of explaining the return structure (num_found, best_edition, ISBNs, edition_key) and how it relates to another tool. It is complete enough for an agent to understand what to expect, though it omits details about other fields or search sorting (likely not essential).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description enhances parameter understanding by explaining how limit, offset, and num_found work together for pagination, and by describing the semantics of edition_key. This adds value beyond the schema's field-level descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Search for a book by its title') on a specific resource (Open Library). It clearly distinguishes from siblings by focusing on title-based search, and the cross-reference to get_book_by_id further clarifies its role.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear usage context: search by title with pagination controls. It also provides a concrete alternative path by noting that edition_key can be passed to get_book_by_id for full records, which helps agents choose between tools. However, it does not explicitly contrast with search_books or state when not to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_book_coverGet book cover URLA
Read-only

Get the URL for a book's cover image using a key (ISBN, OCLC, LCCN, OLID, ID) and value. Reports when no cover exists rather than returning a URL to a blank placeholder.

ParametersJSON Schema
NameRequiredDescriptionDefault
keyYesThe type of identifier used (ISBN, OCLC, LCCN, OLID, ID). ID is Open Library's internal cover ID.
sizeNoThe desired size of the cover (S, M, or L). Defaults to L.L
valueYesThe value of the identifier.

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds behavior beyond the readOnlyHint and openWorldHint annotations by stating it 'reports when no cover exists rather than returning a URL to a blank placeholder.' This is a valuable edge-case disclosure not captured elsewhere, though it doesn't cover other potential behaviors like rate limits or authentication.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loads the action and input types, and contains no redundant phrases. Every word contributes to understanding the tool's function and behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (3 parameters, no output schema, read-only annotations), the description adequately covers the purpose, identifier types, and a key edge-case (no cover). It could mention the size parameter or URL format, but those are already in the schema, so it feels complete enough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides 100% coverage with detailed descriptions for all three parameters, including enums and defaults. The description only repeats the key types (already in schema) and adds no additional semantic meaning beyond what is structured, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves a cover image URL using a specified key type and value. It specifies the exact identifier types (ISBN, OCLC, etc.), and the verb 'Get' with resource 'URL for a book's cover image' distinguishes it from sibling tools like get_book_by_id or search_books.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context on when to use the tool by listing the required identifier types, but it does not explicitly contrast it with alternatives or state when not to use it. The purpose is clear enough that an agent would infer usage for cover retrieval, but explicit exclusions are missing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_booksSearch booksA
Read-only

Search Open Library across titles, authors, subjects, places, people, publishers and ISBNs. Provide at least one search criterion: q, title, author, subject, place, person, publisher, isbn; combining several narrows the search. Returns at most limit results (default 10) together with num_found, the total number of matches; page through them with offset. Each result carries best_edition — one edition of the work, with its isbn_13/isbn_10 where Open Library has them, and its edition_key, which can be passed to get_book_by_id as { idType: "olid" } for that edition's full record.

ParametersJSON Schema
NameRequiredDescriptionDefault
qNoFree-form query searched across all fields. Supports Solr syntax, e.g. `subject:cyberpunk AND first_publish_year:[1980 TO 1990]`.
isbnNoSearch by ISBN-10 or ISBN-13.
sortNoResult ordering. Omit for relevance. `new`/`old` order by first publication date, `rating` by average rating.
limitNoMaximum number of results to return (1-50, default 10).
placeNoSearch by a place the book is about.
titleNoSearch by book title.
authorNoSearch by author name.
offsetNoNumber of results to skip, for paging through the total reported as num_found (0-1000, default 0).
personNoSearch by a person the book is about.
subjectNoSearch by subject.
languageNoRestrict results to a language, as a 3-letter MARC code (e.g. eng, fre, spa).
publisherNoSearch by publisher.

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses detailed runtime behavior: result limit (default 10), num_found field, paging with offset, and the structure of each result (best_edition with ISBNs and edition_key). It also explains how to use edition_key with get_book_by_id. Since annotations already mark it as readOnly and openWorld, the description adds substantial value by explaining pagination and result format, going 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences long, front-loaded with the purpose, then usage constraints, then result details. There is no fluff or repetition of schema information. Every sentence contributes meaningful information: what it searches, how to combine criteria, and what results look like including chaining. Efficient and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a complex tool with 12 parameters and no output schema. The description fully covers the essential aspects: search criteria, result limit, pagination, result structure (best_edition), and how to access full records via edition_key. It leaves no major gaps for an agent to invoke the tool correctly and interpret results. The coverage is comprehensive given the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers 100% of the 12 parameters with descriptions, so the baseline is 3. The description adds semantic context by listing searchable criteria, explicitly stating the requirement of at least one criterion, and explaining how combining them narrows results. It also clarifies the meaning of limit and offset in the context of num_found and paging, which is not fully captured in the schema. This adds value beyond the schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States exactly what it does: 'Search Open Library across titles, authors, subjects, places, people, publishers and ISBNs.' The verb 'search' plus the specific resource ('Open Library') and the enumerated fields make the purpose unambiguous, and it clearly distinguishes from sibling tools like get_book_by_id (which retrieves specific records) by focusing on search across multiple criteria.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear usage context: 'Provide at least one search criterion' and 'combining several narrows the search.' It also explains paging with offset and chaining to get_book_by_id via edition_key. However, it does not explicitly mention when not to use this tool or contrast it with alternatives like get_book_by_title, though the chaining hint implies an alternative path. The guidance is strong but not fully explicit about exclusions.

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.

  1. 7 tool updatesv1.2.1
    • Changedget_author_info2 fields changed
      • addedInput schema / properties / author_key / minLength
        Added value: +1
      • addedInput schema / properties / author_key / pattern
        Added value: +"^OL\\d+A$"
    • Changedget_author_photo2 fields changed
      • addedInput schema / properties / olid / minLength
        Added value: +1
      • addedInput schema / properties / olid / pattern
        Added value: +"^OL\\d+A$"
    • Changedget_authors_by_name3 fields changed
      • addedInput schema / properties / limit
        Added value: +{
+  "default": 10,
+  "description": "Maximum number of results to return (1-50, default 10).",
+  "maximum": 50,
+  "minimum": 1,
+  "type": "integer"
+}
      • addedInput schema / properties / name / minLength
        Added value: +1
      • addedInput schema / properties / offset
        Added value: +{
+  "default": 0,
+  "description": "Number of results to skip, for paging through the total reported as num_found (0-1000, default 0).",
+  "maximum": 1000,
+  "minimum": 0,
+  "type": "integer"
+}
    • Changedget_book_by_id2 fields changed
      • changedInput schema / properties / idType / description
        Previous value: -"The type of identifier used (ISBN, LCCN, OCLC, OLID)."New value: +"The type of identifier used (isbn, lccn, oclc, olid). Case-insensitive."
      • addedInput schema / properties / idValue / minLength
        Added value: +1
    • Changedget_book_by_title3 fields changed
      • addedInput schema / properties / limit
        Added value: +{
+  "default": 10,
+  "description": "Maximum number of results to return (1-50, default 10).",
+  "maximum": 50,
+  "minimum": 1,
+  "type": "integer"
+}
      • addedInput schema / properties / offset
        Added value: +{
+  "default": 0,
+  "description": "Number of results to skip, for paging through the total reported as num_found (0-1000, default 0).",
+  "maximum": 1000,
+  "minimum": 0,
+  "type": "integer"
+}
      • addedInput schema / properties / title / minLength
        Added value: +1
    • Changedget_book_cover4 fields changed
      • changedInput schema / properties / key / description
        Previous value: -"The type of identifier used (ISBN, OCLC, LCCN, OLID, ID)."New value: +"The type of identifier used (ISBN, OCLC, LCCN, OLID, ID). ID is Open Library's internal cover ID."
      • addedInput schema / properties / size / default
        Added value: +"L"
      • changedInput schema / properties / size / description
        Previous value: -"The desired size of the cover (S, M, or L)."New value: +"The desired size of the cover (S, M, or L). Defaults to L."
      • addedInput schema / properties / value / minLength
        Added value: +1
    • Addedsearch_books
  2. 6 tool updatesv1.0.0
    • First observedget_author_info
    • First observedget_author_photo
    • First observedget_authors_by_name
    • First observedget_book_by_id
    • First observedget_book_by_title
    • First observedget_book_cover
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0
Disambiguation4/5

Most tools are clearly separated by resource and action, but get_book_by_title overlaps heavily with search_books since it returns the same result structure and is essentially a subset of the general search. The book/author detail and cover/photo tools are unambiguous.

Naming Consistency4/5

Naming mostly follows a consistent get_<resource>_by_<qualifier> pattern, e.g. get_book_by_id, get_book_by_title, get_author_photo. search_books breaks the get_ convention but remains readable and predictable alongside the others.

Tool Count5/5

Seven tools is well-scoped for a read-only Open Library server. Each tool addresses a distinct lookup need without the collection feeling bloated or thin.

Completeness4/5

The surface covers general book search, book lookup by ID/title, author search, author details, author photos, and book covers. Minor gaps exist, such as no direct endpoint for works or edition lists beyond indirection through edition_key, but core reading workflows are covered.

Maintenance

ActivityMaintained
ResponsivenessWithin a week

Resources

Related MCP Connectors

Related MCP Servers

  • MCP Server Demo

    Drakoxw
    F
    license
    B
    quality
    D
    maintenance
    A Model Context Protocol server implementation that can be run directly or through Docker, enabling AI assistants to interact with external systems through the MCP standard.
    2
    -

  • bookstore-mcp-server

    aga87
    A
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that exposes tools for querying a bookstore inventory, allowing AI agents to search and retrieve book information via the Model Context Protocol.
    225
    1
    MIT

  • @cyanheads/openlibrary-mcp

    cyanheads
    A
    license
    Not graded
    quality
    A
    maintenance
    An MCP server that enables searching books and authors, fetching editions, browsing subjects, and resolving cover images from Open Library.
    323
    3
    Apache 2.0

  • mcp-google-books

    pipeworx-io
    A
    license
    Not graded
    quality
    C
    maintenance
    MCP server for Google Books API, enabling volume details, ISBN lookup, and bookshelf access via natural language queries.
    15
    MIT

Appeared in Searches

Latest Blog Posts

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/8enSmith/mcp-open-library'

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