Skip to main content
Glama

Search Images

search_images
Read-onlyIdempotent

Search 200,000+ historical illustrations, emblems, engravings, diagrams, AND 24,000+ artworks (paintings, prints, sculptures). Filter by type, subject, figure, symbol, year. Results interleave two collections: illustrations extracted from book pages (each with a page number and book link) and standalone museum artworks (type: "artwork"). The first few results also return as inline images YOU can see. Hosts that support MCP Apps render an in-chat image gallery for this tool automatically; on other clients images may sit inside the collapsed tool-result view, so never tell the user images are "rendered above" unless the gallery appeared — describe what you see and give each image's url link instead. Every image_url is public and stable — an HTML page that references them directly works in any online browser. If images.length is 0, read the note field — an empty result under a book_id filter means that book has no EXTRACTED images yet, not that the physical book has no plates. A broad query can match tens of thousands (read total): narrow with type/subject/symbol/iconclass or page with offset instead of raising limit. On museum-artwork results, a title_is_descriptive flag means the title is an AI description of the picture rather than a title the work was published under — cite such a record by its source_record_title, never by the descriptive one (#4288).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeNoImage type (woodcut, engraving, emblem, diagram). Best-effort: the medium metadata on museum artworks is unnormalized, so treat results as ranked rather than strictly filtered.
limitNoMax results (default 20, max 50)
queryNoText search (e.g., "ouroboros", "tree of life")
figureNo
offsetNoSkip this many book-illustration results — page through a large result set instead of raising limit. The response echoes offset and returns next_offset while more remain. Offsets > 0 return the gallery lane only (the museum-artwork lane has no pagination and is included only on the first page).
symbolNo
book_idNoOnly return images extracted from this book's pages. Excludes the museum-artwork collection (artworks do not belong to books).
subjectNo
year_toNoSee year_from — same reliability caution applies.
iconclassNoFilter by Iconclass notation, prefix-matched ("49" matches 49G22, 49E39, …). Coverage is SPARSE: only ~2,500 of 206K images carry a notation, so an empty result means the classifier has not run on matching images, NOT that the subject is absent from the corpus — retry with a text query before concluding anything. Book-illustration lane only (artworks are excluded when this filter is set). Matching results return their notations in an iconclass array.
year_fromNoCAUTION: reliable only for book illustrations (source_type "book_illustration"). On museum-artwork records the year field is dirty — some 17th-century works carry ingest years like 2014, and null years bypass the range check entirely — so never draw a chronological conclusion from a year-filtered artwork result (#4288 tracks the cleanup).
include_thumbnail_base64NoEmbed each result's image as a thumbnail_data_uri (data:image/jpeg;base64,…, ~1000px) directly in the JSON. ONLY useful when your harness consumes tool results programmatically (API/SDK agents that can save the bytes without retyping them) — as a chat assistant you CANNOT copy hundreds of KB of base64 into a file, so do not request this for that purpose. To build a self-contained page from chat instead: fetch the public image_url values with your execution sandbox (if egress is blocked, ask the user to allowlist images.sourcelibrary.org in their network settings), or reference the CDN URLs directly — they are public and stable, so the page works in any online browser. First 6 results only; inline image blocks are suppressed in this mode to keep the payload bounded.

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already mark this read-only and idempotent, and the description adds substantial behavioral detail beyond that: the two interleaved result lanes, the gallery/render differences across hosts, public and stable image URLs, offset echo and next_offset pagination, the title_is_descriptive flag, sparse iconclass coverage, and the dirty year field on museum-artwork records. This is far more transparency than typical.

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 long but every sentence carries a distinct operational fact; there is no filler or restatement of the title. It front-loads the corpus scope and then layers filters, result behavior, and edge-case warnings in a logical order.

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?

With no output schema, the description adequately documents return values and states: images.length, total, note, offset/next_offset, iconclass array, thumbnail_data_uri, inline gallery behavior, and the title_is_descriptive/source_record_title distinction. It also covers the critical empty-result and dirty-data edge cases, making it complete for a complex 12-parameter tool.

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?

Schema coverage is 75%, and the description significantly enriches the parameters: it warns that type is best-effort, that year_from/year_to are unreliable for artworks, that iconclass is prefix-matched and sparse, that book_id excludes artworks, and that include_thumbnail_base64 has a specific mode and caveat. It also covers otherwise-undescribed parameters by mentioning filtering by figure, symbol, and subject.

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 a specific verb and resource scope — 'Search 200,000+ historical illustrations... AND 24,000+ artworks' — and enumerates the exact media types covered. This distinguishes it clearly from the sibling text/book/translation search tools without needing to open the schema.

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 rich conditional guidance: when to page with offset instead of raising limit, when not to request base64 thumbnails, how to interpret an empty result under book_id, and to retry iconclass filters with a text query. It does not name sibling tools explicitly, but the search scope itself makes the target use case clear and the exclusion guidance is behaviorally specific.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation4/5

Tools are organized around distinct actions—discover, read, cite, search, contribute—and the descriptions cross-reference each other heavily. The only mild ambiguities are the get_quote/get_quotes pair and the multiple passage-search variants, which overlap in result type but are scoped differently.

Naming Consistency5/5

All tools use snake_case verb_noun names with predictable prefixes: get_* for retrieval, list_* for catalog enumeration, search_* for discovery, and plain verb_noun for contribution actions. Pluralization and compound nouns like get_book_text are minor variations that do not break the pattern.

Tool Count5/5

Fifteen tools is at the upper end of the ideal range, but every tool maps to a distinct step in the library workflow: discovery, reading, citation, search, editions, images, and community contributions. None feels redundant or decorative.

Completeness5/5

The surface covers the full research lifecycle: discovering books, reading them, locating canonical references, citing exact pages, searching by keyword/meaning/within a book, comparing editions, finding images, and contributing findings back. The pipeline from get_book to get_book_text to get_quote provides clear forward paths with no dead ends.