The full upstream README, mirrored here for reference. Install config, tool schemas, adoption signals, and an original overview live on the MCP Open Library listing page.
A Model Context Protocol (MCP) server for the Open Library API that enables AI assistants to search for book and author information.
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.
search_books).get_book_by_title).get_authors_by_name).get_author_info).get_author_photo).get_book_cover).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.
Nothing to install or build. Point an MCP client at the package with npx and it
will be fetched on first run:
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.
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:
nvm installed run nvm use.mcp-open-library root directory run npm run buildnpm run inspector. Once built, click the URL with the MCP_PROXY_AUTH_TOKEN query string parameter to open the Inspector.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 ISBNget_book_by_title: Search for book information by titleget_authors_by_name: Search for author information by nameget_author_info: Get detailed information for a specific author using their Open Library Author Keyget_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:
Example search_books output:
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:
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:
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 relevancelimit: Optional, 1–50, defaults to 10offset: Optional, 0–1000, defaults to 0Example get_book_by_title input:
Example get_book_by_title output:
Example get_authors_by_name input:
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.
Example get_author_info input:
Example get_author_info output:
Example get_author_photo input:
Example get_author_photo output:
When Open Library has no photo for that author, the tool says so instead of returning a URL:
Example get_book_cover input:
Example get_book_cover output:
As with author photos, a book with no cover produces a message rather than a URL:
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 identifiersize: Optional cover size (S for small, M for medium, L for large, defaults to L)Example get_book_by_id input:
Example get_book_by_id output:
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 identifierAn example of this tool being used in Claude Desktop can be see here:
You can test this MCP server using Docker. To do this first run:
You can then test the server running within Docker via the inspector e.g.
src/index.ts - The MCP server: builds the HTTP clients and drives both request handlers
from the tool registrysrc/index.test.ts - Tests for the server wiring, including a snapshot of the published
tool schemassrc/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 shapesrc/tools/registry.ts - The TOOLS array, the single list of what the server exposessrc/tools/types.ts - The ToolDefinition and ToolHandler contractssrc/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.tsscripts/ - Release automation (sync-server-json.mjs, promote-changelog.mjs,
assert-release-consistency.mjs) and its testsA 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).
npm run build - Build the TypeScript codenpm run watch - Watch for changes and rebuildnpm test - Run the test suite in watch modenpm run test:precommit - Run the test suite once and exitnpm run lint / npm run lint:fix - Lint src and scripts with ESLintnpm run format - Format code with Prettiernpm run inspector - Run the MCP Inspector against the servernpm test starts Vitest in watch mode:
For a single pass — what the pre-commit hook and CI run — use:
To run one file or one test case:
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:
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:
## [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.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 retryOnce 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:
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:
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.
Contributions are welcome! Please feel free to submit a pull request.