art-institute-chicago-mcp-server

Search artists

artic_search_artists

Read-onlyIdempotent

Find artists, cultures, and organizations in the Art Institute of Chicago collection by name, or fetch them by id. Each result carries life dates, agent type, alternate names, how many of the museum's artworks credit them, and up to three of their works, the museum's highlighted works first. Pass an id to artic_search_artworks as artist_id to browse all of their works.

Input Schema

TableJSON Schema

Name	Required	Description
`ids`	No	Agent ids to fetch (up to 25), such as an artwork's artist_id, as an array or a comma-separated string. Pass query or ids, not both; the other filters and page apply to query only.
`page`	No	Query mode: page to return (1-based); page times limit may not exceed 1,000.
`limit`	No	Query mode: agents per page (1-25).
`query`	No	Name to find, matched against names and alternate names; every word must match. Pass query or ids, not both.
`born_to`	No	Query mode: latest birth year, negative for BCE.
`born_from`	No	Query mode: earliest birth year, negative for BCE.
`artists_only`	No	Query mode: only agents the museum records as artists. Set false to include donors, funds, and organizations.

Output Schema

TableJSON Schema

Name	Required	Description
`cap`	No	The limit applied to this page, or the number of ids requested.
`page`	No	Page returned (1-based); always 1 when ids were passed.
`error`	No	Present when the call failed. Absent on success.
`shown`	No	Agents returned on this page.
`notice`	No	Guidance when nothing matched, ids were missing, more pages exist, the reachable window is exhausted, or artwork counts could not be loaded.
`artists`	No	Matching agents: in relevance order for a name search, in request order for ids.
`has_more`	No	True when more matches exist beyond this page.
`next_page`	No	Page to request next; absent when nothing remains or the next page would pass the first 1,000 matches.
`truncated`	No	True when more matches exist beyond this page.
`totalCount`	No	Matches for the query and filters before paging, or agents found for ids.
`missing_ids`	No	Requested ids with no agent, in request order; present when ids were passed.
`license_text`	No	License statement from the API for this data, verbatim.
`artists_only_applied`	No	Whether results were limited to artists; always false when ids were passed, since every requested agent is returned.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 2, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds genuinely useful behavior not in annotations: what each result contains (life dates, agent type, alternate names, artwork credit counts, up to three works with museum-highlighted works ordered first) and the cross-tool id handoff. It stops short of noting pagination/limits behavior, which lives only in the schema.

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?

Three sentences, front-loaded with purpose and mode distinction, then result shape, then the follow-up tool. Dense and mostly waste-free, though the result-shape sentence is long enough that it slightly competes with the guidance content.

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?

An output schema exists, so return values need not be fully specified, yet the description still frames what comes back and how to chain into artic_search_artworks. Combined with 100% schema coverage and clear annotations, nothing an agent needs to invoke this correctly is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so baseline is 3; the description only restates that query matches names and that ids fetch agents, both already documented in the schema. It adds no syntax or constraint detail beyond structured fields.

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?

States a specific verb (find/fetch) and resource (artists, cultures, organizations in the AIC collection), and explicitly distinguishes search-by-name from fetch-by-id. An agent can differentiate it from artic_search_artworks and artic_lookup_vocabulary without opening a schema.

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?

Explicitly names the downstream tool and the parameter mapping ('Pass an id to artic_search_artworks as artist_id to browse all of their works'), giving a concrete when-to-use-it-next rule. It also reflects the query-vs-ids exclusivity that routes the agent to the right mode.

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

All art-institute-chicago-mcp-server tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.