tickadoo® MCP 服务器通过模型上下文协议 (MCP) 将实时体验发现功能引入 AI 助手。它使兼容的客户端能够访问全球 680 多个城市中可预订的剧院、演出、旅游、景点和活动。
内部说明： 这是位于
mcp.tickadoo.com的面向公众的 AI 代理 MCP，支持 Claude、ChatGPT、Cursor、Smithery 和其他 MCP 客户端。用于读取生产数据库以进行临时团队调查的独立内部/mcp-db端点在翻转后已停用；它已被 howard 仓库中的db-investigateClaude 技能所取代。当 tickadoo 团队文档提到“MCP”且没有限定词时，指的就是此服务器。
🌐 语言：落地页提供以下语言版本：EN · JA · 中文 · 한국어 · DE · FR · ES · IT · PT · tlhIngan Hol 🖖
tickadoo® MCPサーバーは、AIアシスタント（Claude、ChatGPT、Gemini等）から680以上の都市で13,000以上の体験（劇場、ツアー、アトラクション）を検索できます。APIキー不要、認証不要、即座に接続可能です。
tickadoo® MCP服务器让AI助手（Claude、ChatGPT、Gemini等）可以搜索680+城市中13,000+体验活动（剧院、旅游、景点）。无需API密钥，无需认证，即时连接。
tickadoo® MCP 서버는 AI 어시스턴트(Claude, ChatGPT, Gemini 등)에서 680+ 도시의 13,000+ 체험(극장, 투어, 관광명소)을 검색할 수 있습니다.
当前版本：v1.4.2
17 个只读 MCP 工具，包含搜索、比较、城市指南、家庭日、交通和本地旅行提示工作流
覆盖 681 个城市的 13,090 种产品，支持 40 多种语言
基于规则的受众 + 标签丰富（100% 覆盖）
带有实际日期和价格的可用性时段
包含结账深层链接 + Ghost Checkout 的预订合同
伦敦 30 个剧院场馆的无障碍数据
两个搜索工具上均具备完整的 AI 代理智能层：
_available_filters（10 个字段：tag_counts, price_range, duration_range, audience, setting, physical, languages, tags, wheelchair, free_cancellation）
_conversation_starters（基于结果数据的上下文提示）
_related_searches（基于标签的后续建议）
_booking_urgency（转化信号：今日可用性、免费取消、评分、轮椅）
_cross_sell, _intent_token, _accessibility
📊 结果摘要行 + 🔍 文本响应中的过滤提示
🔥 文本详细响应中的紧急信号
智能过滤恢复（当过滤条件过于严格时引导 AI 代理）
1 个机器可读的产品订阅源资源
用于托管 MCP 客户端的远程 HTTP 端点
用于桌面和开发工作流的本地 stdio 入口点
工具 | 描述 |
| 在 681 个城市中搜索 13,090 多种体验，支持 11 个过滤器（受众、环境、轮椅、体力要求、时长、语言、评分、取消政策、价格、标签、类别）+ 6 种排序选项（包括 best_value） |
| 按情感意图搜索（浪漫、放松、经济实惠、雨天、冒险、美食）——将心情映射到标签、受众、评分、环境和价格过滤器 |
| 在经纬度附近查找体验，支持相同的 11 个过滤器、可配置的半径和日期过滤 |
| 浏览支持的城市，支持可选过滤和结果限制 |
| 针对单一体验进行快速的日期特定可用性检查——返回匹配的时段、人均价格、 |
| 通过 slug 或预订路径获取特定 tickadoo 体验的详细可用性、定价、场馆和图像信息 |
| 2-5 个体验的并排比较，并标出最佳价值、最高评分、最受欢迎和最适合家庭的获胜者 |
| 7 天城市规划器，包含早/中/晚细分 |
| 今晚的体验，按开始时间排名并带有紧急信号 |
| 几小时内开始的体验，按最快开始时间排序 |
| 精选城市概览：热门亮点、类别组合、价格范围、最佳建议、内部提示 |
| 20 个首发城市的本地内部建议：交通、货币、安全、文化、食物、紧急电话、常用短语 |
| 从城市默认机场、车站或港口到酒店坐标的出租车、地铁/轻轨、巴士和火车接送估算 |
| 带有年龄感知过滤和地理聚类的家庭日规划器 |
| 针对给定体验的语义 + 启发式混合“您可能也喜欢”的结果 |
所有工具都公开了 readOnlyHint、destructiveHint 和 openWorldHint 的 MCP 工具注解。
每个搜索响应都包含专为 AI 代理设计的元数据键：
键 | 描述 |
| 12 个字段：标签、受众、环境、价格范围、时长范围等 |
| 自动精选前 3 名：最佳价值、最高评分、最受欢迎 |
| 根据结果价格进行经济/中档/高端分组 |
| 基于标签的类别细分（例如“8 个游轮，6 个导览，5 个餐饮”） |
| 引用实际产品的上下文感知提示 |
| 用于缩小结果范围的基于标签的建议 |
| 推荐的后续操作 |
get_experience_details 添加了：_booking_urgency, _cross_sell, _intent_token, _accessibility
Related MCP server: Nightlife Search
资源 | 描述 |
| OpenAI 商业产品订阅源格式的机器可读产品订阅源 |
托管的 MCP 端点：
https://mcp.tickadoo.com/mcp
远程 MCP 配置示例：
{
"mcpServers": {
"tickadoo": {
"url": "https://mcp.tickadoo.com/mcp"
}
}
}远程 HTTP MCP（推荐——无需 API 密钥，无需本地安装）：
claude mcp add --transport http tickadoo https://mcp.tickadoo.com/mcp或通过 npm 添加为本地 stdio：
claude mcp add tickadoo -- npx -y @tickadoo/mcp-server请参阅 https://code.claude.com/docs/en/mcp 获取完整的 Claude Code MCP 文档。
Claude Dispatch 使用相同的远程 MCP URL 配置：
{
"mcpServers": {
"tickadoo": {
"url": "https://mcp.tickadoo.com/mcp"
}
}
}将其添加到 ~/.gemini/settings.json：
{
"mcpServers": {
"tickadoo": {
"httpUrl": "https://mcp.tickadoo.com/mcp"
}
}
}使用 Perplexity 的自定义远程连接器：
设置 → 连接器 → 自定义连接器 → 远程
名称：tickadoo
MCP 服务器 URL：https://mcp.tickadoo.com/mcp
传输：Streamable HTTP
认证：None
对 Perplexity 付费订阅者可用
适用于 ChatGPT Pro、Business、Enterprise 和 Edu 计划：
打开 设置 → 应用与连接器 → 高级 → 开发者模式开启
回到应用与连接器 → 创建
名称：tickadoo
URL：https://mcp.tickadoo.com/mcp
认证：None
在新聊天中：+ → 更多 → 开发者模式 → 添加来源 → tickadoo
相同的 httpUrl 配置适用于：
Android Studio (mcp.json)
Firebase Studio (.idx/mcp.json 或 .gemini/settings.json)
发布后从 npm 运行：
npx -y @tickadoo/mcp-server通过 npx 的 stdio 配置示例：
{
"mcpServers": {
"tickadoo": {
"command": "npx",
"args": ["-y", "@tickadoo/mcp-server"]
}
}
}安装并构建：
npm install
npm run build直接运行 stdio 服务器：
node dist/index.jsstdio 配置示例：
{
"mcpServers": {
"tickadoo": {
"command": "node",
"args": ["/path/to/tickadoo-mcp/dist/index.js"]
}
}
}远程 MCP 端点：https://mcp.tickadoo.com/mcp
tickadoo：https://www.tickadoo.com
命令 | 用途 |
| 通过 esbuild 打包 stdio 服务器 ( |
| 运行单元测试套件 (vitest) |
| 针对本地 stdio 服务器运行 MCP 冒烟测试套件 |
| 针对 HTTP 端点运行 MCP 冒烟测试套件 |
| 通过 |
| 部署主 MCP Worker ( |
| 部署 |
共享服务器逻辑位于 src/shared/* — API 客户端、格式化、工具定义、资源注册。传输包装器：
src/index.ts — 本地 stdio 传输（在 npm 上发布为 @tickadoo/mcp-server）
src/worker.ts — Cloudflare Worker (Hono + WebStandardStreamableHTTPServerTransport) 服务于 https://mcp.tickadoo.com
widgets-worker/ — 独立的 Cloudflare Worker，服务于 https://widgets.tickadoo.com 的可嵌入小部件
两个 Worker 均通过 Cloudflare Workers 部署：
主 MCP worker：wrangler.jsonc → mcp.tickadoo.com
Widgets worker：widgets-worker/wrangler.jsonc → widgets.tickadoo.com
CI：.github/workflows/deploy-cf.yml 在每次推送到 main 时运行并部署两个 Worker。
变量 | 默认值 | 描述 |
|
| tickadoo API 基础 URL |
|
| 日志详细程度： |
|
| tickadoo 网站基础 URL |
tickadoo® 始终为小写。标语是 What Do You Wanna Doo?® 请在所有集成和文档中保持小写。
MIT — tickadoo Inc.
Find shows, events and experiences near a geographic location on tickadoo®. Use when a user shares their location or asks for things to do near them.
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | Latitude | |
| longitude | Yes | Longitude | |
| radius_km | No | Search radius in km (default 25) | |
| language | No | Language code | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the agent knows this is a safe, non-destructive query operation. The description adds context about location-based searching but doesn't disclose additional behavioral traits like rate limits, authentication needs, or result format. With annotations covering the core safety profile, a 3 is appropriate as the description provides some useful context without rich behavioral details.
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, front-loaded with the core purpose and followed by usage guidance. Every sentence earns its place by providing essential information without redundancy or fluff, making it highly efficient and easy to parse.
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 the tool's moderate complexity (location-based search), rich annotations (read-only, open-world), and full schema coverage, the description is mostly complete. It lacks details on output format (no output schema provided) and doesn't mention pagination or result limits, but the purpose and usage are well-covered, making it adequate for agent selection.
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%, with all parameters (latitude, longitude, radius_km, language) documented in the schema. The description doesn't add meaning beyond the schema, such as explaining coordinate systems or language code specifics. Baseline 3 is correct when the schema fully describes parameters.
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 purpose: 'Find shows, events and experiences near a geographic location on tickadoo®.' It specifies the verb ('Find'), resource ('shows, events and experiences'), and context ('near a geographic location'), distinguishing it from sibling tools like get_experience_details (detail view) and list_cities (city listing).
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 usage guidance: 'Use when a user shares their location or asks for things to do near them.' This clearly indicates when to invoke this tool versus alternatives, helping the agent select it based on user context rather than other tools like search_experiences (which might not be location-based).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed availability, venue details, and images for a specific tickadoo® experience. Prefer passing the tickadoo slug or booking URL path; provider and provider_id are legacy fallback inputs.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Preferred: tickadoo slug or path, e.g. 'london-dungeon-tickets' or '/london/london-dungeon-tickets' | |
| provider | No | Legacy fallback only: hidden provider name used internally | |
| provider_id | No | Legacy fallback only: hidden provider-specific product ID | |
| days | No | Number of days of availability to fetch (default 30, max 180) | |
| language | No | Reserved for future language-aware API support | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, non-destructive, and open-world behavior, which the description does not contradict. It adds context by specifying input preferences and the scope of data fetched (availability, venue details, images), enhancing understanding beyond the annotations.
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 front-loaded with the core purpose and usage guidelines in two concise sentences, with no wasted words. Every sentence contributes directly to tool understanding and selection.
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 the tool's complexity (5 parameters, no output schema) and rich annotations, the description is mostly complete. It covers purpose, usage, and input semantics well, but could benefit from mentioning potential outputs or limitations, though annotations help mitigate this gap.
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?
With 100% schema description coverage, the schema fully documents all parameters. The description adds value by clarifying input preferences (slug as preferred, provider/provider_id as legacy fallbacks) but does not provide additional semantic details beyond what the schema already covers.
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 specific action ('Get detailed availability, venue details, and images') and the resource ('a specific tickadoo® experience'), distinguishing it from sibling tools like find_nearby_experiences, list_cities, and search_experiences by focusing on details for a single experience rather than searching or listing.
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?
It provides explicit guidance on when to use this tool by specifying preferred inputs ('tickadoo slug or booking URL path') and fallback options ('provider and provider_id are legacy fallback inputs'), helping the agent choose this over alternatives for retrieving detailed information on a known experience.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all cities where tickadoo® has bookable experiences. Use to help users discover available destinations.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Language code | en |
| query | No | Optional city name or slug filter (e.g. 'new', 'paris', 'tokyo') | |
| limit | No | Maximum number of cities to return (default 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering safety and scope. The description adds minimal behavioral context beyond this, such as the purpose of 'discover available destinations,' but doesn't detail aspects like rate limits, authentication needs, or pagination behavior. It doesn't contradict annotations, so it meets the baseline for having annotations.
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 concise and front-loaded: two sentences that directly state the tool's purpose and usage without unnecessary details. Every sentence earns its place by providing essential information, making it efficient and well-structured.
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 the tool's low complexity (a read-only list operation), rich annotations (covering safety and scope), and 100% schema coverage, the description is mostly complete. It lacks an output schema, but the description doesn't need to explain return values. However, it could be more complete by mentioning potential limitations or result formats, slightly reducing the score.
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%, meaning all parameters are well-documented in the schema itself. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain the 'query' parameter's filtering behavior in more detail). With high schema coverage, the baseline score is 3, as the description doesn't compensate but also doesn't need to.
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 purpose: 'List all cities where tickadoo® has bookable experiences.' It specifies the verb ('List') and resource ('cities'), and distinguishes it from siblings by focusing on destinations rather than experiences. However, it doesn't explicitly differentiate from potential sibling tools like 'search_cities' if they existed, so it's not a perfect 5.
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 implied usage context: 'Use to help users discover available destinations.' This suggests it's for discovery purposes, but it doesn't explicitly state when to use this tool versus alternatives like 'search_experiences' or 'find_nearby_experiences' from the sibling list. No exclusions or clear alternatives are mentioned, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for shows, theatre, events, tours and experiences in a specific city on tickadoo®. Use when a user asks what to do in a city, wants event/show recommendations, or is looking for tickets.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City name or slug (e.g. 'london', 'new-york', 'paris', 'tokyo', 'dubai') | |
| language | No | Language code (e.g. 'en', 'de', 'fr', 'es') | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the agent knows this is a safe, read-only search operation with open-world semantics. The description adds useful context about the types of content searched (shows, theatre, events, tours, experiences) and the tickadoo® platform, but doesn't provide additional behavioral details like rate limits, authentication needs, or pagination behavior.
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 perfectly concise and front-loaded: the first sentence states the core functionality, and the second sentence provides clear usage guidelines. Every sentence earns its place with no wasted words or redundant 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?
Given that this is a search tool with good annotations (read-only, open-world) and 100% schema coverage, the description provides adequate context about what's being searched and when to use it. However, without an output schema, the description doesn't explain what the search returns (e.g., result format, pagination), leaving a minor gap in completeness.
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%, with both parameters ('city' and 'language') fully documented in the schema. The description doesn't add any parameter-specific semantics beyond what's already in the schema (e.g., it doesn't explain city validation rules or language code formats). With complete schema coverage, the 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 the specific action ('Search for shows, theatre, events, tours and experiences') and resource ('in a specific city on tickadoo®'), distinguishing it from siblings like 'find_nearby_experiences' (which implies proximity-based search) and 'get_experience_details' (which retrieves specific item details). The verb 'search' is precise and the resource scope is well-defined.
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 explicitly provides when-to-use guidance: 'Use when a user asks what to do in a city, wants event/show recommendations, or is looking for tickets.' This gives clear context for invocation and distinguishes it from alternatives like 'list_cities' (which lists available cities rather than searching within one).
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.1.0find_nearby_experiencesget_experience_detailslist_citiessearch_experiencesScored across 4 tools
Each tool has a clearly distinct purpose with no overlap: find_nearby_experiences uses geographic location, get_experience_details retrieves details for a specific experience, list_cities enumerates available destinations, and search_experiences searches within a specific city. The descriptions explicitly differentiate their use cases, eliminating any ambiguity.
All tool names follow a consistent verb_noun pattern (e.g., find_nearby_experiences, get_experience_details, list_cities, search_experiences) with clear, descriptive verbs and nouns. There are no deviations in style or convention, making the set highly predictable and readable.
With 4 tools, the set is well-scoped for a ticketing/experience discovery server, covering key functionalities like location-based finding, detailed lookups, city listing, and city-specific searches. Each tool earns its place without redundancy or excessive complexity.
The tool surface covers core discovery and information retrieval workflows effectively, including location-based and city-specific searches, detailed views, and destination listing. A minor gap exists in booking or transaction capabilities, but agents can work around this for recommendation and exploration tasks.
Find, price, and book tours, day trips, and activities worldwide, with live dates and prices.
Search & compare prices for tours, activities and tickets across multiple providers.
Find live events worldwide and link each seller's tickets. Some ticket links are affiliate links.
Free walking tours & activities in 1,000+ cities — live availability, ratings & booking links.
