Skip to main content
Glama

Look up book/audiobook metadata and cover art candidates

audiobook_lookup_book_metadata
Read-onlyIdempotent

Look up book and audiobook metadata—authors, narrators, publisher, ISBN, length, ratings—and cover images from free public APIs to fill missing details for cataloging or production.

Instructions

Look up book/audiobook metadata (authors, narrators, publisher, publish date, description, ratings, ISBN, length) and candidate cover images across free, unauthenticated APIs: Google Books, Open Library, Audible's public catalog search, and Apple's iTunes Search. No scraping, login, or CAPTCHA surface is touched -- these are the same plain JSON endpoints each service's own search box calls.

Ported from the book-metadata-fetch skill; carries over its guardrails: personal research/cataloging use, not a bulk data feed -- this tool self-throttles slightly between calls, but don't loop it over long lists of titles. It has NO Amazon/Audible-retail-page fallback (that requires a browser tool this server doesn't have) -- if Tier 1 here comes up short, that's the tool's real ceiling; a calling agent with its own browser tool may attempt one manual, on-demand page visit per the source skill's Tier 2 procedure, subject to the same guardrails (never bypass a CAPTCHA/sign-in wall).

Series volumes are the main failure mode: search APIs rank by relevance, not series order, so an unfiltered query for "Defiance of the Fall" can return book 12. Include the volume number in title when known (e.g. "Defiance of the Fall 6").

Args: params (LookupBookMetadataInput): see field descriptions. Notably reconcile=True (default) merges all sources into one record; include_covers=True (default) probes each candidate cover's real pixel dimensions (never trust a CDN URL's size token).

Returns: str: JSON. With reconcile=True: { "record": { "title": str, "authors": [str,...], "narrators": [str,...], "description": str, "publisher": str, "published_date": str, "categories": [str,...], "average_rating": float, "ratings_count": int, "length": str, "isbn": str, "source_url": str, "_provenance": {field: source_name}, # which source supplied each field "_conflicts": [str, ...], # fields sources disagreed on -- READ THESE # before trusting publisher/published_date; # audiobook vs. print edition is the common case "_missing": [str, ...] # fields nothing supplied }, "errors": {source_name: error_message}, "covers": [ # present if include_covers=True {"source": str, "url": str, "width": int|null, "height": int|null, "bytes": int} | {"source": str, "url": str, "error": str} ] } With reconcile=False: {"raw": {source_name: [...]}, "errors": {...}, "covers": [...]}.

Error Handling: - Per-source failures land in "errors" rather than failing the whole call -- e.g. Google Books commonly 429s on its shared anonymous quota; the other three sources still return. - Only fails outright ({"error": ...}) if input validation fails.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint/idempotentHint/openWorldHint, and the description layers substantial extra behavior on top: no scraping/login/CAPTCHA surface, self-throttling between calls, per-source failures landing in 'errors' (Google 429 example), only failing outright on input validation, and cover probing that reports true decoded pixel dimensions. Nothing contradicts 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.

Conciseness4/5

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

The description is long but coherently sectioned (purpose, guardrails, failure mode, args, returns, errors) and front-loaded with the core purpose. Every section adds operational value, though the 'Args' bullet partially restates what the schema's $defs already describe, and the return-format block could arguably live in the output schema.

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?

For a tool with four external sources, six parameters, two reconcile modes, and cover probing, the description is remarkably complete: it covers source enumeration, quota behavior, error semantics, the full JSON return shape for both reconcile modes, and the known failure mode (series volumes). An agent has everything needed to call it 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?

With schema description coverage reported at 0%, the description carries the parameter-documentation burden and largely delivers: it explains reconcile=True merges sources, include_covers=True probes real pixel dimensions, and emphasizes including the volume number in title to defeat relevance-ranked series mismatches. It does not explicitly walk through author/source/google_api_key, though those are documented in the schema's own $defs, so the compensation is strong but not complete.

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 first sentence names a specific verb ('look up'), a specific resource (book/audiobook metadata and candidate cover images), and enumerates the four source APIs. This clearly distinguishes it from siblings like audiobook_fetch_cover_image (which fetches a concrete cover into a file rather than returning candidates) and the conversion/status/boundary tools.

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

Usage Guidelines5/5

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

The description gives explicit when/when-not guidance: personal research/cataloging use, 'not a bulk data feed', 'don't loop it over long lists of titles', and names the alternative path (a calling agent with its own browser tool may do one manual Tier 2 page visit). It also states the tool's real ceiling when Tier 1 comes up short, so an agent can decide whether to fall back.

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