Skip to main content
Glama
mildlydiverting

whitney-museum-mcp-server

Search Whitney exhibitions

whitney_search_exhibitions
Read-onlyIdempotent

Search Whitney Museum exhibitions from 1931 onward by title, date, or custom filters, and retrieve records in markdown or JSON for research and display.

Instructions

Search exhibitions mounted by the Whitney, going back to 1931. Records are fuller for recent decades and sparse for the Museum's early history.

Args:

  • title (string, optional): substring match

  • filters (object, optional): raw Ransack predicates for fields this tool does not expose

  • sort (string, optional): e.g. 'start_time desc', 'random'

  • starts_on_or_after / starts_on_or_before (string, optional): ISO dates (YYYY-MM-DD) filtering on start_time

  • 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 — the Museum documents its field set as subject to change, so this tool keeps whatever scalar fields the API returns, strips HTML, shortens timestamps to dates and drops internal IDs. Known fields include title, start_time, end_time, date_override, url, primary_text, press_highlights and popularity. Run one search with limit=1 to confirm before writing a 'filters' query.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo1-based page number; the API returns 30 records per page
sortNoRansack sort string, e.g. 'start_time desc', 'title asc', or 'random'
limitNoMaximum records to return from the fetched page (1-30). Keep this low unless you need the detail — Whitney records are verbose.
titleNoWords appearing in the title
filtersNoRaw Ransack predicates, e.g. { "title_cont": "moon", "classification_eq": "Paintings" }. Matchers: _eq, _not_eq, _cont, _not_cont, _cont_all_split, _true, _false, _gt, _gteq, _lt, _lteq.
response_formatNoOutput format: 'markdown' for reading, 'json' for machine processingmarkdown
starts_on_or_afterNoISO date (YYYY-MM-DD); keep records starting on or after this date
starts_on_or_beforeNoISO date (YYYY-MM-DD); keep records starting on or before this date

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.6/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds substantial behavioral disclosure beyond that: the tool strips HTML, shortens timestamps to dates, drops internal IDs, passes through fields generically because the museum's field set is subject to change, and warns about sparse early records. This fully covers the behavioral profile.

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 organized into clear sections — overview, args, returns, field behavior, and a practical preflight instruction. Every paragraph earns its place; nothing is filler. It is appropriately detailed for an 8-parameter tool and remains scannable.

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 an output schema present and annotations covering safety, the description still completes the picture: it documents return shape, pagination page and limit, filter preflight, data-quality caveats, and field volatility. An agent has enough context to call the tool correctly and interpret results.

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?

Even though schema coverage is 100%, the description adds key semantics: title is a substring match, filters are raw Ransack predicates for fields not exposed by the tool, date filters are ISO format, limit controls verbose record fetch size, and response_format distinguishes reading vs machine processing. It also explains that exhibition fields are passed through generically, which clarifies why no fixed field parameters exist.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches exhibitions mounted by the Whitney, going back to 1931, which is a specific verb+resource combination. It does not explicitly name or differentiate from sibling tools like whitney_search_artworks or whitney_artist_exhibitions, so it stops short of full sibling distinction.

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 strong contextual guidance: records are fuller for recent decades and sparse for early history, and it instructs users to run a limit=1 search before writing raw filters queries. It does not explicitly state when to use this tool over alternatives or when not to use it, but the context is clear.

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