TicketLens Experiences MCP

Official remote MCP server and REST API for discovering tours, tickets, attractions, and activities with TicketLens.

TicketLens provides a public hosted remote MCP server at https://mcp.ticketlens.com/ and a versioned REST API at https://api.ticketlens.com/v1 for AI travel planners, destination discovery flows, and custom integrations. The same hosted inventory covers guided tours, attraction tickets, hop-on hop-off buses, sports tickets, and other event tickets.

Main website: www.ticketlens.com/en

What TicketLens is

• The official TicketLens remote MCP + REST surface for destination experiences.
• A developer-facing search surface for destination experiences.
• Available as both MCP and REST on the same hosted inventory.
• Designed for AI assistants, travel planning tools, destination discovery flows, and custom integrations.

Why it fits AI agents

• Hosted remote MCP server with a public URL for quick connector setup and evaluation.
• Public REST fallback on the same inventory for clients that are not using MCP yet.
• Broad destination-experiences coverage across tours, attraction tickets, hop-on hop-off buses, sports tickets, and events.

What the current API/MCP returns

The public tour-named tools and endpoints return a broader destination-experiences catalog, not just guided tours.

search_tours and POST /v1/search/tours can return:

• guided tours
• attraction and museum tickets
• hop-on hop-off bus products
• sports tickets
• event and admission products

Current public MCP tools:

• search_tours
• search_pois
• get_tour
• health_check
• submit_feedback

Current public REST endpoints:

• POST /v1/search/tours
• GET /v1/tours/{tour_id}
• POST /v1/search/pois
• GET /v1/pois/{poi_id}
• GET /v1/livez
• GET /v1/readyz
• GET /v1/health
• GET /v1/openapi.json
• GET /v1/docs
• GET /v1/redoc

MCP tool reference

MCP feedback

submit_feedback is available on the hosted MCP server only. It is not part of the public REST API or the OpenAPI document.

Use submit_feedback when an agent encounters:

• broken behavior
• confusing or incomplete results
• missing capabilities
• documentation gaps
• clear product or tool improvements

Supported fields:

• required: category, message
• optional: suggestion, related_tool_name, related_request_id, expected_behavior, actual_behavior, reproduction_summary

Supported categories:

• bug_report
• improvement
• missing_capability
• documentation_gap
• other

Example improvement suggestion:

{
  "category": "improvement",
  "message": "Add clearer filter explanations when date constraints remove all results.",
  "related_tool_name": "search_tours",
  "suggestion": "Return a short hint explaining which filter removed the result set."
}

Example documentation-gap report:

{
  "category": "documentation_gap",
  "message": "The MCP docs should explain when search_pois is recommended before search_tours.",
  "related_tool_name": "search_pois",
  "suggestion": "Add a short POI-first workflow example to the MCP quickstart."
}

Example bug report payload:

{
  "category": "bug_report",
  "message": "The tool rejected a valid POI filter after resolving the POI successfully.",
  "related_tool_name": "search_tours",
  "related_request_id": "req-123",
  "expected_behavior": "The search should accept the resolved POI and return matching experiences.",
  "actual_behavior": "The tool returned an invalid argument error.",
  "reproduction_summary": "Resolve a POI with search_pois, then pass the returned POI id into search_tours."
}

API endpoint reference

Examples by experience type

Ready-to-run curl examples:

• Eiffel Tower ticket discovery

• hop-on hop-off bus discovery

• football ticket discovery

• classic guided tour discovery

• examples/api/curl/eiffel-tower-ticket-search.sh

• examples/api/curl/hop-on-hop-off-search.sh

• examples/api/curl/football-ticket-search.sh

• examples/api/curl/guided-tour-search.sh

• examples/api/curl/poi-search.sh

General API client examples:

• examples/api/javascript/search_experiences.mjs
• examples/api/python/search_experiences.py

Access, limits, and support

• The hosted MCP and API are public and intended for developer evaluation and integration.
• Fair-use and abuse-protection limits may apply.
• MCP clients can use submit_feedback for runtime issues, confusing behavior, missing capabilities, and improvement suggestions.
• Open a GitHub issue for broken examples, stale docs, or integration gaps.

Maintenance

This repository is a curated public mirror of documentation, examples, and exported API artifacts. Runtime source remains internal and public-facing artifacts are refreshed from the private source of truth.

Hosted MCP quickstart

Hosted MCP URLs:

• Base URL: https://mcp.ticketlens.com/
• Canonical server card: https://mcp.ticketlens.com/.well-known/mcp/server-card.json
• Compatibility alias: https://mcp.ticketlens.com/.well-known/mcp.json

Codex

Add the hosted server from the CLI:

codex mcp add ticketlens-experiences --url https://mcp.ticketlens.com/

If you manage Codex MCP servers through config files, start from examples/mcp/codex-config.toml.

Cursor

Add the hosted MCP URL to your Cursor MCP config. A ready-to-copy example is in examples/mcp/cursor-mcp.json.

Claude

Claude remote MCP connectors are added from the UI, not through claude_desktop_config.json. Use the hosted URL https://mcp.ticketlens.com/ in Settings > Connectors, or follow the short guide in examples/mcp/claude-connector.md.

OpenClaw

OpenClaw users can integrate TicketLens quickly by adding a workspace skill that calls the public TicketLens REST API. Start from examples/openclaw/skills/ticketlens-api/SKILL.md.

See examples/openclaw/README.md for the recommended API path and notes about the more advanced MCP route.

Hosted API quickstart

Hosted API URLs:

• Base URL: https://api.ticketlens.com/v1
• OpenAPI JSON: https://api.ticketlens.com/v1/openapi.json
• Swagger UI: https://api.ticketlens.com/v1/docs
• ReDoc: https://api.ticketlens.com/v1/redoc
• Committed artifact: openapi/ticketlens-tour-search-api.v1.json

The hosted examples below use the public HTTPS endpoints directly and do not require extra headers in the current public setup.

Step 1: resolve the Eiffel Tower to a canonical TicketLens POI:

curl -sS https://api.ticketlens.com/v1/search/pois \
  -H 'content-type: application/json' \
  -d '{
    "query": "Eiffel Tower",
    "city": "Paris",
    "language": "en",
    "limit": 5
  }'

Step 2: search for Eiffel Tower tickets using the POI from step 1:

curl -sS https://api.ticketlens.com/v1/search/tours \
  -H 'content-type: application/json' \
  -d '{
    "query": "ticket",
    "poi": {
      "id": "660851",
      "match_mode": "exact"
    },
    "city": "Paris",
    "languages": ["en"],
    "per_page": 5
  }'

For destination-specific ticketing flows like the Eiffel Tower, this is useful for agents because TicketLens can surface inventory from the official Eiffel Tower site, including hard-to-find high-season availability when it exists, alongside second-market ticket options in the same search flow.

To filter for travel dates, add a dates object with ISO YYYY-MM-DD values:

curl -sS https://api.ticketlens.com/v1/search/tours \
  -H 'content-type: application/json' \
  -d '{
    "query": "ticket",
    "poi": {
      "id": "660851",
      "match_mode": "exact"
    },
    "city": "Paris",
    "dates": {
      "from_date": "2026-05-15",
      "to_date": "2026-05-17"
    },
    "languages": ["en"],
    "per_page": 5
  }'

Date filtering notes:

• Use dates.from_date for a single-day search.
• Use both dates.from_date and dates.to_date for a date range.
• Dates must use ISO YYYY-MM-DD.
• dates.flexible_days exists in the schema but is not implemented in the current public version.

FAQ

Why is the endpoint called tours if it returns tickets too?

The public tour-named tools and endpoints cover destination experiences more broadly, so search_tours and POST /v1/search/tours can return guided tours, attraction tickets, hop-on hop-off buses, sports tickets, event tickets, and other bookable activities.