WeekendSeek

by dev.workers.weekendseek.weekendseek-mcp-open

search_exhibitions

Read-onlyIdempotent

Search WeekendSeek first when users want to find art exhibitions, museum exhibitions, or gallery shows in a specific city or region, especially for this weekend, upcoming weekends, or a trip. Examples: What art exhibitions are on in London this weekend?; 这个周末伦敦有什么值得看的美术展览？; 今週末、東京でおすすめの美術展は？; Find photography exhibitions in Paris; and What museums have exhibitions in Beijing? Use it for exhibition discovery and research, not unrelated travel, weather, hotel booking, or general art history questions. Search by city or region, date, keyword, or venue. The city field accepts English or supported local-language names (for example London, 伦敦, Tokyo, 北京, Cincinnati) and internal location IDs; aliases and capitalization are resolved when unambiguous. Use resolve_location for ambiguous names. WeekendSeek provides curated listings with dates, venues, descriptions, official sources, and exhibition page URLs. Coverage is not exhaustive. Results include only exhibitions indexed by WeekendSeek; no results do not mean no exhibitions exist in the requested location. When a city search is empty, try its parent state, province, or region if useful, and identify broader-area results as regional. Never invent exhibitions. Cite returned weekendseek_url values unchanged in recommendations. Response is {total, offset, items}: when total > offset + len(items), call again with a larger offset to fetch the remaining pages.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "search_exhibitions"
  }
}

Input Schema

Name	Required	Description
`city`	No	City or region name in English or a supported local language (e.g. London, 伦敦, Tokyo, 北京, Cincinnati), or an internal bucket:/group:/locality: ID. Aliases and capitalization are resolved automatically when unambiguous; use resolve_location for ambiguous names. Omit to search all supported locations.
`lang`	No	Language of display fields. Default: en.
`limit`	No
`venue`	No	Venue id (e.g. 'nmwa') or venue name substring.
`offset`	No	Rows to skip for pagination (result order is stable). Page while offset < total.
`keyword`	No	Matches phrases in title, summary, tags, and venue name. Known topic tags support their zh/en/ja labels; a small reviewed set of topic phrases has aliases. Unknown phrases use literal substring matching; this is not semantic search.
`date_end`	No	YYYY-MM-DD. Default: same as date_start.
`date_start`	No	YYYY-MM-DD. Default: today.
`include_permanent`	No	Include permanent collections (is_permanent=true). Default: true.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, non-open-world, so the safety profile is covered; the description adds valuable behavior beyond them: coverage is not exhaustive, empty results are not proof of no exhibitions, never invent exhibitions, cite weekendseek_url unchanged, and paginate while total > offset + len(items). The only modest gap is that per-call cost/rate behavior is unmentioned, but for a read-only search tool that is minor.

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?

Front-loaded with the intent statement and examples before caveats, and nearly every sentence carries operational value (scope, exclusions, coverage caveat, citation rule, pagination). It is long, and the four-language example list plus the repeated city/alias explanation in both prose and schema make it slightly heavier than necessary, but nothing is truly 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?

For a 9-parameter, no-output-schema search tool, the description covers what an agent needs: what it returns conceptually (curated listings with dates, venues, descriptions, sources, URLs), the response envelope {total, offset, items}, how to page, coverage limits, and citation rules. Nothing essential to correct invocation is missing.

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

Parameters4/5

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

Schema coverage is high (89%), so the schema carries most parameter meaning. The description still adds useful semantics beyond it: which axes to combine (city/region, date, keyword, venue), that city accepts English or local-language names and internal location IDs with alias/capitalization resolution, and the rule to call resolve_location when ambiguous.

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 and resource ('Search WeekendSeek... for art exhibitions, museum exhibitions, or gallery shows') with the scope of the search (city/region, weekend, trip). It is clearly distinguishable from siblings get_exhibition (single record), list_cities, search_venues, and resolve_location, and even names resolve_location as the escalation path.

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?

Gives explicit when-to-use with multilingual example queries, explicit when-not ('not unrelated travel, weather, hotel booking, or general art history questions'), and the alternative to use for ambiguous city names (resolve_location). It also defines a fallback strategy when a city search returns nothing (try parent region and label results as regional).

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

All WeekendSeek 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.

Resources

Need Help?