DPLA Catalog

dpla-catalog-mcp

An MCP server for the Digital Public Library of America: one search across descriptions of more than 50 million digitised items held by hundreds of US libraries, archives, historical societies and museums. For family history that means county atlases and plat books, city directories, county histories, yearbooks, local newspapers and photographs, many of them held by a small institution you would not think to search.

DPLA holds none of these items. It gathers the descriptions that holding institutions publish, through state and regional "hubs", and every record points back at the item on the holding institution's own site. That page is where the evidence is and what a citation names. The server is built around that fact: each hit carries is_shown_at (the item at its holder), the holding institution, and the rights statement for the digital copy; get_item assembles the parts of a citation of the holder's record; and get_item_images lists the page images from the holder's own IIIF manifest when it publishes one.

It works the way a careful genealogist does. A DPLA record is a finding aid to a finding aid: written by the institution, harvested by a hub, and enriched by DPLA. DPLA searches that metadata only, never the text inside a book or on a page. The tools say so, in the descriptions a model reads.

Nothing here writes anywhere, and nothing here keeps a family tree. It sits well beside nara-catalog-mcp (federal records, with OCR and page images), snac-archives-mcp (which archive holds the papers) and familysearch-mcp (indexed records and images).

This is an independent project. It is not affiliated with, endorsed by, or supported by the Digital Public Library of America or any contributing institution.

Tools

The server publishes six tools, all read-only and annotated so for the client. One makes no network call at all.

Finding items

Reading an item

The server itself

Setup

You need Python 3.11 or later, uv, and a DPLA API key.

The key is free and arrives at once, but it is issued to an email address, so request it yourself:

curl -X POST https://api.dp.la/v2/api_key/you@example.org

DPLA emails a 32-character key to that address. Asking again re-sends the same key. DPLA records only the email address, and counts each call made with the key.

Without cloning. uvx fetches the server from PyPI and runs it in one step:

DPLA_API_KEY=your-key uvx dpla-catalog-mcp

From a clone, which is what you want if you will change it:

git clone https://github.com/ianderso/dpla-catalog-mcp
cd dpla-catalog-mcp
uv sync
cp .env.example .env       # then put your key in .env
uv run dpla-catalog-mcp    # stdio server, usually launched by the client

Either way the server speaks MCP over stdio, so you will normally let an MCP client start it rather than run it by hand.

Claude Desktop

{
  "mcpServers": {
    "dpla": {
      "command": "uvx",
      "args": ["dpla-catalog-mcp"],
      "env": { "DPLA_API_KEY": "your-key" }
    }
  }
}

A desktop app does not always inherit your shell's PATH. If the server fails to start because uvx cannot be found, give the full path that which uvx prints as the command.

Claude Code

claude mcp add dpla --env DPLA_API_KEY="$DPLA_API_KEY" -- uvx dpla-catalog-mcp

Or keep the key in a .env file and have the launcher read it, so it is in neither the client's configuration nor your shell history:

"dpla": { "type": "stdio", "command": "sh", "args": ["-c",
  "set -a; . \"$HOME/research/.env\"; set +a; exec uvx dpla-catalog-mcp@latest"] }

Configuration

A .env file in the directory the server starts in supplies anything the environment does not; only that directory is read. An unusable value is reported on the first tool call, naming the variable.

Being a good guest

DPLA sets no quota, but every call is counted against the key. The server sends one request at a time, at least DPLA_MIN_INTERVAL apart; two identical calls in flight share one request; searches and facets are cached on disk for 7 days and records and manifests for 30 (DPLA re-harvests monthly). A 429 or a 5xx gets one retry, honouring Retry-After up to 30 seconds, and is then reported as rate_limited or upstream_error, which is never the same as "nothing found". Requests to institutions' sites are spaced a second apart per site and never retried.

How to read what comes back