This server exposes travel.art's art-tourism data to AI agents via MCP, allowing them to search published events, museum guides, and generate city-based itineraries.
find_art_events — Search upcoming/current art events (biennales, art fairs, festivals) by type, country, free-text query, or date range; returns dates, venues, ticket info, summaries, and guide links.
find_museum_guide — Search museum visitor guides (e.g., Louvre, Vatican, Uffizi) by city, country, or query; returns 2026 ticket info, opening hours, address, essential works, route duration, and guide links.
recommend_art_trip — Generate a city-based art trip itinerary using only published content; optionally filter events by trip dates and returns relevant museum guides and links.
Protocol features — Supports MCP initialization, tool listing, and tool calling over Streamable HTTP with JSON-RPC 2.0 (protocol version 2025-03-26).
Health check — A /health endpoint is available for monitoring.
Public access — Read-only server with no authentication required.
Model Context Protocol server for travel.art. Live at https://mcp.travel.art/.
Exposes travel.art's art-tourism data to AI agents over the Model Context Protocol (Streamable HTTP transport, request/response mode).
Three tools as of v1:
find_art_events — biennales, art fairs, festivals with dates, venues, ticket info, summaries, links to full guides
find_museum_guide — major museums (Louvre, Vatican, Uffizi) with 2026 ticket info, opening hours, essential works
recommend_art_trip — city-based itinerary using only published travel.art content
Catalogue v1.6.0: 23 events + 12 museums + 6 layover itineraries (synced from the published calendar and cornerstone articles; event facts re-verified 2026-09-14).
Related MCP server: Akebono MCP
mcp/
src/
index.ts # Worker entry, MCP HTTP protocol (JSON-RPC 2.0)
tools.ts # Tool definitions + handlers
data.ts # Static dataset (typed)
scripts/ # (Future) sync from content/<slug>/index.md frontmatter
data/ # (Future) sync output
package.json
wrangler.toml
tsconfig.jsonRuntime: Cloudflare Workers, free tier (100k requests/day)
Language: TypeScript
Transport: MCP Streamable HTTP (request/response, no SSE — single-shot tool calls)
Protocol version: 2025-03-26
Auth: None (public read-only)
curl https://mcp.travel.art/healthcurl -X POST https://mcp.travel.art/ \
-H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"my-client","version":"0.1"}}}'curl -X POST https://mcp.travel.art/ \
-H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":2,"method":"tools/list"}'curl -X POST https://mcp.travel.art/ \
-H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"find_art_events","arguments":{"country":"IT"}}}'Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS):
{
"mcpServers": {
"travel-art": {
"url": "https://mcp.travel.art/"
}
}
}cd mcp
npm install
npx wrangler deploy(Requires CLOUDFLARE_API_TOKEN + CLOUDFLARE_ACCOUNT_ID in env or wrangler login.)
The Worker is bound to the mcp.travel.art custom domain via Cloudflare API (one-time setup; see DECISIONS.md 2026-05-08).
Build-time data extraction — replace hand-curated data.ts with a sync script that reads content/<slug>/index.md frontmatter (events from Event-typed schema, museums from Place-typed schema). New cornerstones flow into MCP automatically.
More tools — find_artist_residencies, find_collateral_events, today_in_art_tourism (calendar of what's open today across our catalogue).
Authentication tier — currently public read-only. If commercial clients want high-volume programmatic access, add API-key tier under Account API Tokens.
Streaming responses — for long itinerary recommendations, switch to SSE.
Rate limiting — per-IP throttle (currently relies on Cloudflare's own DDoS protection).
Schema versioning — mcp.travel.art/v1, /v2 URL versioning when we break compatibility.
See .claude/agents/mcp-architect.md for the full agent operating spec.
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 |
|---|---|---|---|
| type | No | Filter by event type. Optional. | |
| 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. | |
| activeOn | No | ISO 8601 date (YYYY-MM-DD). Returns only events whose date range covers this date. Optional. | |
| endsBefore | No | ISO 8601 date. Returns only events ending on or before this date. Optional. | |
| startsAfter | No | ISO 8601 date. Returns only events starting on or after this 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 communicates that the tool is read-only ('Search', 'Returns'), scopes the data source ('travel.art's catalogue'), and describes what is returned (dates, venues, ticket info, summary, link). It does not mention edge behaviors like pagination or no-result handling, but the essential behavior is transparent.
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 two sentences plus example queries. It is front-loaded with the primary purpose, then lists return contents, then provides usage examples. Every sentence earns its place with zero 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?
The tool has 0 required parameters and no output schema, but the description adequately covers what the tool returns (dates, venues, ticket info, summary, link) and provides clear usage examples. It could mention default sorting or behavior without filters, but for a search tool this is sufficient.
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 schema descriptions cover 100% of the parameters, each with a clear explanation (e.g., 'ISO 8601 date (YYYY-MM-DD). Returns only events whose date range covers this date'). The description adds context through example queries but does not add parameter-specific nuances beyond what the schema already provides, warranting the baseline score.
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 opens with 'Search travel.art's catalogue of upcoming and current art events', which clearly identifies the verb (Search), resource (catalogue of art events), and scope (travel.art). It also enumerates event types ('biennales, art fairs, festivals') and distinguishes itself from sibling tools like find_museum_guide and recommend_art_trip by focusing specifically on events.
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 ('when is Venice Biennale 2026', 'art fairs in October 2026', 'what's on in Miami in December'), giving clear context for when to use the tool. However, it does not explicitly state when not to use it or mention alternatives by name, stopping short of a full 'when/when-not' guideline.
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 layover-itinerary catalogue — short-window (3–6h) art-focused trips between flight connections from major European hub airports. Returns itineraries by city, airport, art focus, or duration, with venues, transit notes, and a link to travel.art's full hour-by-hour guide. Use for queries like 'art layover in Rome from Fiumicino', '4-hour Caravaggio plan', 'short Louvre window from CDG', 'Amsterdam 4 hours Schiphol'.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City filter (e.g., 'Milan', 'Rome', 'Florence', 'Amsterdam', 'Paris', 'London'). Optional. | |
| query | No | Free-text query (city, artist, museum, airport, theme). Optional. | |
| airport | No | IATA airport code the layover serves (e.g., 'MXP', 'FCO', 'AMS', 'CDG', 'LHR'). Optional filter. | |
| country | No | ISO 3166-1 alpha-2 country code (e.g., 'IT', 'NL', 'FR', 'GB'). Optional. | |
| maxDurationHours | No | Maximum time-on-ground budget in hours. Returns only itineraries that fit ≤ this duration. Optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses what the tool returns ('itineraries by city, airport, art focus, or duration, with venues, transit notes, and a link') and sets expectations with the '3–6h' window. This goes beyond the schema by adding behavioral context, though it doesn't address edge cases like result limits or availability constraints.
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 two sentences: the first front-loads the core purpose and scope, the second provides concrete usage examples. Every phrase earns its place with no filler or 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?
Despite having no output schema, the description clearly states what is returned (itineraries, venues, transit notes, link) and supplies ample example queries. It's complete for a simple optional-parameter search tool, though a bit more detail on result ordering or limitations could push it to 5.
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 coverage is 100%, so the baseline is 3. The description adds value by giving example queries ('4-hour Caravaggio plan', 'Amsterdam 4 hours Schiphol') that illustrate how to combine parameters (city, airport, duration) in practice, going beyond the schema's individual parameter 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?
The description clearly states the tool's function: 'Search travel.art's layover-itinerary catalogue' with a specific scope ('short-window (3–6h) art-focused trips between flight connections from major European hub airports'). It also distinguishes from sibling tools by focusing on layover itineraries rather than events, museum guides, or general trip recommendations.
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 clear usage context through explicit example queries ('Use for queries like...'), which effectively communicates when to use the tool. However, it does not explicitly mention when not to use it or name alternative sibling tools, so it stops short of a 5.
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 |
|---|---|---|---|
| city | No | City filter (e.g., 'Paris', 'Rome', 'Florence'). Optional. | |
| query | No | Free-text query (museum name, work, artist, city). 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 carries the burden of disclosure. It transparently lists the output fields and the data year (2026), implying a read-only search operation. It does not cover edge cases like empty results or parameter precedence, but for a search tool it provides strong behavioral context.
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 three sentences, front-loaded with the core purpose, followed by the return value details and example queries. Every sentence contributes meaningfully with no redundancy or fluff.
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?
The description is complete for a search tool with no output schema: it explains what the tool returns and offers sample queries. It could slightly improve by clarifying how the optional parameters (city, query, country) combine, but the overall context is sufficient.
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 schema already describes all three parameters with 100% coverage, so the baseline is 3. The description's example queries add some usage context but do not add new meaning about parameter formats, relationships, or constraints beyond what the schema provides.
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 museum visitor guides, with a specific verb and resource. It lists the return content (ticket info, opening hours, address, works, route duration, link) and provides example queries, making it distinct from sibling tools like find_art_events or recommend_art_trip.
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 gives explicit example queries for when to use the tool, such as 'how to visit the Louvre' or 'Uffizi best route'. It does not explicitly mention when not to use it or name alternative tools, but the context and sibling list make the appropriate use case clear.
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'). | |
| endDate | No | ISO 8601 trip end date. Optional. | |
| startDate | No | ISO 8601 trip start date. Optional — if provided, filters events to those active on or near these dates. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explicitly states the recommendation is 'grounded in published data only — no fabrication,' which is a critical trust assurance. It also discloses the return composition (events, museum guides, links). This adds value beyond the schema and addresses potential concerns about hallucination. It doesn't mention side effects, but this is a read-only recommendation tool, so none expected.
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 exactly three sentences: purpose, output contents, and a grounding guarantee. It is front-loaded with the main action, and every sentence contributes meaningful information without redundancy or filler. This is a model of concise, well-structured tool documentation.
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 a 3-parameter tool with no output schema, the description sufficiently covers the essentials. It lists what the tool returns (events, museum guides, links) and provides a behavioral guarantee (no fabrication). It could offer more detail on the itinerary structure, but for a recommendation tool, this level of completeness is adequate. The richness of the description compensates for the lack of output schema.
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 mentions 'city' and 'trip dates' but does not add new semantic details beyond what the input schema already provides. For instance, the schema already explains that startDate filters events. The description repeats this without enriching it further, so the score stays at baseline.
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's function: 'Recommend an art-tourism trip itinerary for a specific city' using specific inputs. It defines the output (events, museum guides, links) and distinguishes itself from sibling tools like find_art_events and find_museum_guide by providing a composite itinerary. The verb 'recommend' and resource 'art-tourism trip itinerary' are specific and unambiguous.
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 establishes a clear usage context: when a user needs a full art-tourism itinerary for a city, including events and museum guides, this tool should be used. It also notes the constraint of using only travel.art's published content. While it doesn't explicitly name alternatives or exclusions, the 'trip itinerary' phrasing implies it is for broader planning vs. single-purpose tools. This gives clear context without explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.6.0find_art_events1 field changedInput schema / properties / type / enumPrevious value: -[
- "biennale",
- "art-fair",
- "festival"
-]New value: +[
+ "biennale",
+ "art-fair",
+ "festival",
+ "museum-exhibition"
+]find_layover_itineraryv0.1.0find_art_eventsfind_museum_guiderecommend_art_tripScored across 4 tools
Each tool targets a distinct catalogue type: layover itineraries, museum guides, art events, and full trip recommendations. The descriptions clearly differentiate scope (e.g., layover is airport-connection-specific, while recommend_art_trip is city-wide), so an agent should rarely misselect.
Three tools follow a clean 'find_<object>' pattern, but recommend_art_trip breaks the pattern by using 'recommend' instead of 'find'. This is a minor deviation and the names remain predictable and readable.
Four tools is a well-scoped size for a niche art-travel content server. Each tool has a clearly distinct purpose and none feel redundant or extraneous, fitting comfortably within the ideal 3–15 range.
The set covers the main user intents: finding events, museum guides, layover-specific itineraries, and full trip recommendations. There is no direct 'get by ID' tool, but the search tools return links to full guides, so the surface feels adequately complete for the domain.
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
