This server provides AI agents with access to travel.art's art-tourism data via the Model Context Protocol, enabling four main capabilities:
find_art_events: Search biennales, art fairs, and festivals by free-text query, country, event type, or date filters. Returns event details, dates, venues, ticket info, and links to full visitor guides.
find_museum_guide: Search museum visitor guides (e.g., Louvre, Uffizi) by museum name, city, or country. Returns 2026-verified ticket prices, opening hours, essential works in viewing order, recommended route durations, and guide links.
find_layover_itinerary: Discover 3–6 hour art-focused layover plans from major European hub airports, filterable by city, country, IATA code, or max duration. Returns time budgets, art highlights, key venues, and logistical details.
recommend_art_trip: Get a curated multi-day art-tourism itinerary for a specific city and date range, combining active events with museum guides — sourced strictly from travel.art's published content.
Model Context Protocol server for travel.art — art-tourism data (biennales, art fairs, museum visitor guides) exposed to AI agents.
Live at https://mcp.travel.art/. Public, unauthenticated, free.
Four tools, accessible via MCP Streamable HTTP (request/response mode, JSON-RPC 2.0 over HTTP POST):
find_art_eventsSearch travel.art's catalogue of biennales, art fairs, and festivals.
{
"name": "find_art_events",
"arguments": {
"query": "biennale", // optional free-text
"country": "IT", // optional ISO 3166-1 alpha-2
"type": "art-fair", // optional: biennale | art-fair | festival
"activeOn": "2026-06-20", // optional ISO 8601 date
"startsAfter": "2026-09-01",
"endsBefore": "2026-12-31"
}
}Returns events with dates, venues, ticket info, summaries, and the canonical guideUrl linking to travel.art's full editorial visitor guide.
find_museum_guideSearch travel.art's catalogue of museum visitor guides.
{
"name": "find_museum_guide",
"arguments": {
"query": "louvre",
"city": "Paris",
"country": "FR"
}
}Returns museums with current 2026 ticket info (including the Louvre's two-tier €22 EU / €32 non-EU pricing under Louvre Nouvelle Renaissance), opening hours, essential works in viewing order, route durations, and guideUrl to the full guide.
find_layover_itinerarySearch travel.art's catalogue of 3–6 hour art-focused layover plans from major European hub airports.
{
"name": "find_layover_itinerary",
"arguments": {
"query": "caravaggio", // optional free-text
"city": "Rome", // optional
"country": "IT", // optional
"airport": "FCO", // optional IATA code (e.g., MXP, CDG, AMS)
"maxDurationHours": 4 // optional ceiling
}
}Returns itineraries with airports served, time-on-ground budget, art focus (artist / museum / theme), key venues, 2026-verified highlights (booking rules, Monday-closure traps, transit math), and guideUrl to the full hour-by-hour guide.
recommend_art_tripRecommend an art-tourism itinerary for a city. Grounded only in travel.art's published content — no fabrication.
{
"name": "recommend_art_trip",
"arguments": {
"city": "Florence",
"startDate": "2026-06-15",
"endDate": "2026-06-18"
}
}Returns events active during the trip dates plus museum guides for the city, with guideUrl for each.
Related MCP server: Akebono MCP
# Health check
curl https://mcp.travel.art/health
# List tools (MCP)
curl -X POST https://mcp.travel.art/ \
-H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'
# Call a tool
curl -X POST https://mcp.travel.art/ \
-H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"find_art_events","arguments":{"country":"IT"}}}'Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or the Windows/Linux equivalent:
{
"mcpServers": {
"travel-art": {
"url": "https://mcp.travel.art/"
}
}
}Restart Claude Desktop. The three tools should appear in the available tools list.
Any MCP-capable client that supports Streamable HTTP transport works the same way — point it at https://mcp.travel.art/.
The same catalogue and the same three tools are also available as a local stdio MCP server, for clients that prefer a spawned process over a remote URL (and so directory evaluators can introspect the server without hitting the hosted endpoint):
git clone https://github.com/alexzavialov/travel-art-mcp.git
cd travel-art-mcp
npm install
npm start # → npx tsx src/stdio.tsTo wire it into Claude Desktop as a local server instead of the remote URL:
{
"mcpServers": {
"travel-art": {
"command": "npx",
"args": ["tsx", "src/stdio.ts"]
}
}
}The stdio server is functionally identical to the hosted endpoint — same tools.ts, same data.ts.
As of the latest publish:
Art events (22): 6 cornerstone events (Whitney Biennial, Venice Biennale, Art Basel Switzerland/Paris/Miami, Frieze London) + 16 catalogue events spanning 4 continents — Sydney/Yokohama/Gwangju/Lyon/Manifesta-16 Ruhr biennales; Art Basel Hong Kong, Frieze NY/Seoul, EXPO Chicago, TEFAF NY, The Armory Show, 1-54 London, Art SG art fairs; Rothko/Florence, Raphael/Met, Duchamp/MoMA museum exhibitions
Museum essentials (12): The Louvre, Musée d'Orsay, Vatican Museums + Sistine Chapel, Galleria degli Uffizi, Museo del Prado, British Museum, The Met, MoMA, Reina Sofía, Rijksmuseum, Van Gogh Museum, Tate Modern
Layover itineraries (6): Milan (Leonardo, 5h MXP/LIN), Rome (Caravaggio, 4h FCO/CIA), Florence (Renaissance, 6h FLR/PSA), Amsterdam (Rijks + Van Gogh, 4h AMS), Paris (Louvre lightning, 3h CDG/ORY), London (BM + Tate, 5h LHR/LGW/STN/LTN/LCY)
Growing weekly as new cornerstone articles publish on travel.art
Each record includes a lastVerified ISO date; AI agents that weight freshness can prefer recently-verified records.
src/
index.ts # Worker entry — MCP HTTP protocol (JSON-RPC 2.0), GET info page, /health, /robots.txt
stdio.ts # Local stdio entry — same tools over MCP stdio transport (@modelcontextprotocol/sdk)
tools.ts # Tool definitions + handlers (shared by both entries)
data.ts # Static dataset (typed events + museums)
package.json
tsconfig.json
wrangler.toml # Cloudflare Workers configStack: TypeScript. Two transports share one codebase: the hosted entry (index.ts) implements MCP HTTP (JSON-RPC 2.0) directly for Cloudflare Workers compatibility; the local entry (stdio.ts) uses @modelcontextprotocol/sdk over stdio. Both serve identical tools from tools.ts + data.ts.
git clone https://github.com/alexzavialov/travel-art-mcp.git
cd travel-art-mcp
npm install
npx wrangler login # if not already
npx wrangler deployYou'll need a Cloudflare account (free tier is sufficient — 100k requests/day).
To bind to a custom domain, update wrangler.toml with a routes entry, OR use the Cloudflare dashboard's Workers → your-worker → Settings → Triggers to add a Custom Domain.
Issues and pull requests welcome.
The catalogue (src/data.ts) is hand-curated from published cornerstone articles on travel.art. Patches that add new events, museums, or destinations should ideally come with a corresponding visitor guide on travel.art so the guideUrl link resolves to substantive content — but exceptions for high-quality factual data (with primary sources cited) are considered.
MIT. Use it, fork it, deploy your own copy with your own catalogue.
Server-side issues / data corrections: mcp@travel.art
General travel.art editorial: editor@travel.art
Project home: travel.art
Privacy policy: travel.art/privacy/
Search travel.art's catalogue of upcoming and current art events (biennales, art fairs, festivals). Returns events with dates, venues, ticket info, summary, and a link to travel.art's full visitor guide. Use for queries like 'when is Venice Biennale 2026', 'art fairs in October 2026', 'what's on in Miami in December'.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Free-text query (event name, theme, keyword). Optional. | |
| country | No | ISO 3166-1 alpha-2 country code (e.g., 'IT', 'CH', 'GB', 'US'). Optional filter. | |
| type | No | Filter by event type. Optional. | |
| activeOn | No | ISO 8601 date (YYYY-MM-DD). Returns only events whose date range covers this date. Optional. | |
| startsAfter | No | ISO 8601 date. Returns only events starting on or after this date. Optional. | |
| endsBefore | No | ISO 8601 date. Returns only events ending on or before this date. Optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the return content (dates, venues, ticket info, summary, link) and implies a read-only search, but does not mention pagination or potential result size limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of three sentences, front-loaded with the main purpose, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 optional parameters and no output schema, the description adequately covers the tool's functionality and return values. However, it does not explain parameter interactions (e.g., activeOn vs startsAfter/endsBefore) but the schema handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description provides no additional meaning beyond what the schema already gives for each parameter, relying on the schema for details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches travel.art's catalogue of art events (biennales, art fairs, festivals) and distinguishes it from siblings (find_museum_guide, recommend_art_trip) by specifying the exact domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit example queries (e.g., 'when is Venice Biennale 2026') that clarify when to use the tool, but it does not explicitly state when not to use it or name alternatives beyond the sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search travel.art's catalogue of museum visitor guides. Returns museums with current 2026 ticket info, opening hours, address, essential works in viewing order, route duration, and a link to travel.art's full guide. Use for queries like 'how to visit the Louvre', 'Vatican Museums skip the line', 'Uffizi best route'.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Free-text query (museum name, work, artist, city). Optional. | |
| city | No | City filter (e.g., 'Paris', 'Rome', 'Florence'). Optional. | |
| country | No | ISO 3166-1 alpha-2 country code. Optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavior: it searches a catalogue, returns specific data (2026 ticket info, hours, etc.) and is presumably read-only. No mention of side effects or destructive actions, which is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first explains purpose and output, second gives usage examples. No extraneous information, front-loaded with key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description explicitly lists what is returned (ticket info, opening hours, etc.). Three optional parameters are common and well-documented. Sufficient for an agent to understand when to use and what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes all three parameters (query, city, country) with 100% coverage. Description adds no additional semantics beyond listing example queries, which is already implied by the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it searches travel.art's catalogue of museum visitor guides, lists specific return fields (ticket info, hours, address, etc.) and provides concrete example queries. Differentiates from siblings (find_art_events, recommend_art_trip) by focusing on museum visit logistics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage examples like 'how to visit the Louvre' that clarify when to invoke. Does not explicitly state when not to use or contrast with siblings, but the examples strongly imply its specific domain of museum guides.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recommend an art-tourism trip itinerary for a specific city using only travel.art's published content. Returns events active during the trip dates, museum guides for the city, and links to all relevant travel.art guides. The recommendation is grounded in published data only — no fabrication.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | Destination city (e.g., 'Paris', 'Venice', 'Florence', 'London', 'Basel', 'Miami Beach'). | |
| startDate | No | ISO 8601 trip start date. Optional — if provided, filters events to those active on or near these dates. | |
| endDate | No | ISO 8601 trip end date. Optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states 'no fabrication' and that the recommendation is 'grounded in published data only', which is critical for trust. However, it does not mention side effects or permissions; given it is a read-only recommendation, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences. The first sentence front-loads the purpose and main constraint. The second sentence details outputs and reiterates data integrity. There is no redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the lack of an output schema, the description fully explains what the tool returns: events, museum guides, and links. It also addresses the potential concern of data fabrication. For a tool with three parameters (one required) and clear output, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters with clear descriptions. The description does not add significant additional meaning beyond restating that startDate/endDate filter events. Given 100% schema coverage, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Recommend an art-tourism trip itinerary'), the resource ('for a specific city'), and a key constraint ('using only travel.art's published content'). This distinguishes it from sibling tools find_art_events and find_museum_guide, which are more focused on individual events or guides.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool returns (events, museum guides, links) and emphasizes reliance on published data. It implicitly guides usage for full itinerary planning, but lacks explicit guidance on when to use alternatives. A clear note on when not to use it (e.g., for single-event lookup) would improve it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct aspect of art travel: events, museum guides, and trip planning. There is no overlap in their purposes.
All three tools follow a consistent verb_noun pattern: find_art_events, find_museum_guide, recommend_art_trip, making them predictable and easy to distinguish.
Three tools is on the low side but still appropriate for a focused art travel domain. Each tool serves a clear purpose and does not feel excessive.
The tool set covers the core functionalities for art tourism—events, museum guides, and trip recommendations. Minor gaps like individual artwork search exist but are not critical.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Live festival data for AI agents: lineups, set times, dates, locations and ticket links worldwide.
Travel & commerce intelligence for AI agents: search, book & price-track hotels, events, retail.
Multilingual travel guides, gear picks and booking links for AI travel agents.
AI training dataset marketplace: 2M+ museum artworks with Golden Codex enrichment
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/alexzavialov/travel-art-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
