Skip to main content
Glama
mildlydiverting

whitney-museum-mcp-server

List an artist's exhibitions

whitney_artist_exhibitions
Read-onlyIdempotent

Find exhibitions by a specific artist at the Whitney Museum. Provide an artist ID to retrieve paginated exhibition details and counts.

Instructions

List Whitney exhibitions featuring one artist.

Args:

  • id (string): artist ID

  • page (number, default 1), limit (number, 1-30, default 10)

  • response_format ('markdown' | 'json', default 'markdown')

Returns: { total, count, page, has_more, next_page?, results[] }.

Exhibition fields are passed through generically (HTML stripped, long prose truncated), because the Museum documents these fields as subject to change. Coverage is fuller for recent decades than for the Museum's early history.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesArtist ID — a TMS ID like '962', or an internal reference prefixed with 'T'
pageNo1-based page number; the API returns 30 records per page
limitNoMaximum records to return from the fetched page (1-30). Keep this low unless you need the detail — Whitney records are verbose.
response_formatNoOutput format: 'markdown' for reading, 'json' for machine processingmarkdown

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNoAdvisory note about trimming or pagination
pageYesPage that was fetched
countYesRecords returned in this response
totalYesTotal matching records across all pages
sourceYesAttribution for the data, as the Whitney's terms ask for
resultsYesThe records
has_moreYesWhether further pages exist
next_pageNoPage number to request next

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the read-only/idempotent annotations, it discloses the exact return envelope, generic pass-through of exhibition fields, HTML stripping, prose truncation, and uneven historical coverage. This is substantial behavioral context that the annotations do not provide.

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?

Purpose is front-loaded, followed by a compact Args/Returns structure. The caveat sentence about generic fields and patchy coverage is dense but valuable; no words are wasted.

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 a rich schema, annotations, and the return envelope in the description, an agent has everything needed to call the tool correctly. The coverage caveat also sets expectations about data completeness, which is important for agent decision-making.

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?

Input schema coverage is 100% and the schema already documents id formats, page semantics, limit bounds, and response_format. The description's Args list adds no new meaning, so it gets the baseline score rather than higher.

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 line names the exact operation ('List Whitney exhibitions featuring one artist') with a specific verb, resource, and scope. The 'artist ID' argument makes clear this is artist-centric, distinguishing it from the search/get exhibition siblings.

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 makes the intended use clear: pass an artist ID to get that artist's exhibitions, with pagination and format options. It doesn't explicitly call out alternatives or exclusion cases, but the artist-relationship is stated upfront so there is little ambiguity.

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