Skip to main content
Glama

openlibrary-mcp-server

by io.github.cyanheads

Get Cover URL

openlibrary_get_cover_url
Read-onlyIdempotent

Resolve a cover image URL for a book or author photo. Returns a direct HTTPS URL in the requested size (S/M/L). The Covers API always returns HTTP 200 — missing covers return a 1×1 placeholder GIF, not a 404 — so the identifier format is validated locally first: "id" must be numeric, "isbn" 10 or 13 digits, "olid" an edition OLID (OL…M) for target "book" and an author OLID (OL…A) for target "author". Identifiers with path separators or control characters, and author-by-ISBN lookups, are rejected before any request. URLs can be embedded in markdown as cover.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sizeNoImage size. S = small (~45px tall), M = medium (~150px tall), L = large (~400px tall).M
targetNo"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_typeYes"id" is the numeric cover_i / cover ID from search or work results. "isbn" and "olid" look up the cover from those identifiers.
identifierYesThe identifier value, validated against id_type before the URL is built. For "id": a numeric cover or photo ID from work/edition/author data. For "isbn": 10 or 13 digits, hyphens optional. For "olid": an edition OLID (OL…M) for target "book", an author OLID (OL…A) for target "author".

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoDirect 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.
noteNoReminder that the URL always returns HTTP 200; a placeholder GIF is served when no cover exists.
errorNoPresent when the call failed. Absent on success.

TDQS

A4.5/5.0
Behavior4/5

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

The annotations declare readOnlyHint and idempotentHint, covering safety and idempotency. The description adds significant behavioral context beyond that: it explains the Covers API always returns HTTP 200 with a placeholder GIF for missing covers, the local validation of identifier formats, and rejection of path separators or control characters. This reveals edge-case behavior that annotations alone do not provide, helping the agent set expectations.

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

Conciseness5/5

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

The description is dense but efficient. The first sentence states the purpose, followed by behavioral notes and validation rules, then usage guidance for embedding. Every sentence contributes information that is not redundant with the schema or annotations. The structure front-loads the core purpose before diving into details, making it easy for an agent to quickly grasp the tool's function without wasteful verbiage.

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

Completeness5/5

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

The tool has 4 parameters, 3 enums, and an output schema. The description covers all relevant aspects: validation rules, response behavior, embedding in markdown, and parameter interdependencies. It does not need to explain the return format because the output schema is provided. Given the complexity and the existing structured information, the description is complete and leaves no gaps for correct invocation.

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

Parameters4/5

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

The schema covers 100% of parameter descriptions, meeting the base requirement. The description adds value by elaborating on validation rules per id_type, such as what constitutes a valid numeric ID, ISBN, or OLID, and clarifies the target parameter's distinction between author and book. It also notes that author-by-ISBN lookups are rejected, which is not obvious from the schema. This enriches the agent's understanding beyond the bare schema descriptions.

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

Purpose5/5

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

The description opens with 'Resolve a cover image URL for a book or author photo,' clearly stating the verb and resource. It immediately conveys the tool's unique purpose of resolving cover URLs, distinguishing it from sibling tools like openlibrary_get_work or openlibrary_search_books, which retrieve metadata or perform searches. The specificity of 'cover image URL' and 'book or author photo' leaves no ambiguity.

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

Usage Guidelines4/5

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

While the description doesn't explicitly name alternatives or say 'use this when...', it clearly implies the intended use case: resolving cover URLs from identifiers. It provides detailed context such as local validation rules and the fact that invalid inputs are rejected before making a request. It stops short of explicitly contrasting with sibling tools, but the purpose is clear enough that an agent can infer when to use it.

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

All openlibrary-mcp-server toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Every tool targets a distinct resource-action pair: author lookup, author works, cover resolution, edition resolution by identifier, edition listing by work, subject browsing, work lookup, and three search types (authors, books, full-text). The only near-overlap is get_edition vs get_editions, but the descriptions clearly separate identifier-based resolution from listing editions of a work, and cross-references reinforce the distinction.

Naming Consistency5/5

All tools follow a consistent snake_case verb_noun pattern: get_* for direct retrieval and search_* for query-based lookups. The single pair get_edition/get_editions is a natural pluralization, not an inconsistency. Naming is predictable and intuitive throughout.

Tool Count5/5

Ten tools is an ideal size for a read-heavy library API. Each tool serves a distinct purpose (author, work, edition, subject, cover, three search modes) without redundancy or bloat. The surface feels deliberately scoped and not overwhelming.

Completeness5/5

The set covers the full read surface of Open Library: authors (get/search), works (get/search), editions (get by ID, list by work), subjects, covers, and full-text search. There are no obvious missing operations—all core entities and lookup paths are represented, and recoveries for missing data (e.g., author names) are built into descriptions.

Resources