首个专门针对夏威夷旅游的 MCP 服务器。 为 AI 助手提供夏威夷旅游、活动和优惠信息 —— 现在支持 AAAK 结构化响应，以便消费者代理无需重新解析文本即可处理结果。
当有人问 Claude、ChatGPT 或任何 AI“我在夏威夷该做什么？”时，此 MCP 服务器会返回真实、可预订的数据：
2,583 个可预订体验，来自 Viator、GetYourGuide、Klook 和 Groupon
579 个活动，覆盖欧胡岛、茂宜岛、大岛和可爱岛
540+ 家精选餐厅，位于威基基及欧胡岛各地
实时天气，覆盖全部四个岛屿 (OpenMeteo)
每日行程规划，包含早/午/下午/晚餐推荐
联盟追踪，应用于每个预订链接
真正的 MCP 协议 —— 可流式传输 HTTP，无状态，规范版本 2025-03-26
AAAK v0.1 —— 在人类可读文本之外提供类型化的 structuredContent 信封。请参阅 docs/aaak-spec.md。
由 aloha.fyi 提供支持 —— 夏威夷的 AI 礼宾服务。
关于规范来源的说明。 本仓库是
baphometnxg/Nani-V3内部生产环境mcp-server目录的公开镜像。生产环境部署由此驱动；本仓库作为社区使用和希望自行托管者的独立参考保持同步。在此处或上游提交问题均可。
生产环境 MCP 服务器（无需安装，无需设置）：
https://mcp-server-nani-v3-20.up.railway.app/mcp传输：可流式传输 HTTP（无状态）
协议版本：2025-03-26
身份验证：无（公开，只读）
健康检查：GET /health —— 返回 aaak: { protocol, enabled, allowlist_size } 以便观察部署状态
Related MCP server: Famxplor Family Travel Activities
默认情况下，MCP 工具结果以文本块形式返回 —— 希望以编程方式使用数据的代理必须重新解析 Markdown 以提取价格、预订 URL、岛屿等信息。AAAK 解决了这个问题。
当启用 AAAK（且调用客户端在白名单中）时，每个工具结果都包含一个类型化的 structuredContent 字段，以机器可解析的形式携带数据，并从 text 中删除营销尾注以节省 Token。当 AAAK 关闭时，线路格式与 v1.0.0 的字节等效 —— 对于未选择加入的客户端不会有意外。
无损不变量 — 在每一行产生收入的数据中保留：
booking_url（联盟收入）
source（合规性 + 归因）
price_cents（用户决策所依赖的唯一数值字段）
island（每项推荐都限定在特定岛屿）
示例 (search_hawaii_tours)：
{
"ok": true,
"kind": "result",
"tool": "search_hawaii_tours",
"protocol": "aaak/0.1",
"query": { "query": "snorkeling", "island": "oahu", "limit": 1 },
"results": [
{
"title": "Hanauma Bay Snorkel",
"source": "viator",
"island": "oahu",
"area": "east_oahu",
"category": "tour",
"price_cents": 8900,
"rating": 4.7,
"review_count": 2341,
"description": "Guided snorkeling at Oahu's most famous reef...",
"booking_url": "https://aloha.fyi/r/aB3kT9pQz1",
"is_deal": false
}
],
"meta": { "count": 1, "cached": false, "source_diversity": 1 }
}完整规范：docs/aaak-spec.md。生成的 JSON Schema：docs/aaak.schema.json。
验证脚本（供自托管者和贡献者使用）：
npm run aaak:test # 12 hand-written conformance fixtures
npm run aaak:smoke # 9 adapter-output validations
npm run aaak:gate # ~70 env-gate / trailer / allowlist invariants
npm run aaak:verify -- --expect=aaak --ua=claude-code/1.0 # live probe添加到您的 Claude Desktop 配置中（macOS 上为 ~/Library/Application Support/Claude/claude_desktop_config.json）：
{
"mcpServers": {
"aloha-fyi-hawaii": {
"url": "https://mcp-server-nani-v3-20.up.railway.app/mcp"
}
}
}重启 Claude Desktop。您应该会在工具选择器中看到三个夏威夷工具。尝试：
帮我找欧胡岛 100 美元以下的浮潜之旅
这个周末檀香山有什么活动？
规划大岛的家庭冒险日 —— 最便宜的选项
任何支持可流式传输 HTTP MCP 的客户端都可以直接指向：
https://mcp-server-nani-v3-20.up.railway.app/mcp无需 API 密钥，无需 OAuth，无需注册。
curl -X POST https://mcp-server-nani-v3-20.up.railway.app/mcp \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"curl","version":"1.0"}}}'search_hawaii_tours按关键词、岛屿、价格范围搜索 2,583 个可预订的夏威夷旅游和活动。返回来自 Viator、GetYourGuide、Klook 和 Groupon 的旅游项目，并附带联盟预订链接。
参数 | 类型 | 描述 | ||||
| string (必填) | 例如 "snorkeling", "helicopter tour", "family luau" | ||||
|
|
|
|
|
| 默认为 |
| number | 每人最高价格（美元） | ||||
|
|
|
|
|
| 按预订平台筛选 |
| number | 结果数量（最多 20 个，默认 5 个） |
get_hawaii_deals查找预算优惠和折扣。返回 Groupon 优惠和按价格从低到高排序的低价选项。
参数 | 类型 | 描述 |
| string (必填) | 例如 "snorkeling", "helicopter", "luau" |
| number | 默认 100 |
| number | 结果数量（最多 20 个，默认 5 个） |
search_hawaii_events查找夏威夷各岛即将举行的活动、音乐会、节日和夜生活。来自 70 多个场地的 579+ 个活动，每周更新。
参数 | 类型 | 描述 | ||||
| string | 例如 "live music", "luau", "concert" | ||||
|
|
|
|
|
| 默认为 |
| number | 向前搜索的天数（默认 7） |
git clone https://github.com/baphometnxg/aloha-fyi-mcp.git
cd aloha-fyi-mcp
npm install
npx tsc
DATABASE_URL="postgresql://..." PORT=9624 node dist/http.js要求：
Node.js 20+
DATABASE_URL 环境变量（带有 experiences 表的 PostgreSQL —— 架构在 schema.sql 中）
MCP 服务器不收集任何个人身份信息 (PII)。无状态模式 —— 无会话，无跨请求配置文件。仅记录标准请求元数据以防止滥用。
完整隐私政策：aloha.fyi/privacy
由 Michael Crain 构建 —— 夏威夷居民、电影摄影师及 aloha.fyi 创始人。
aloha.fyi 是一个为夏威夷旅游业提供的人工智能多语言礼宾服务。礼宾代理“Nani”会说 5 种语言（英语、日语、韩语、中文、西班牙语），并可访问 6 个联盟网络中的 2,583 个可预订体验。
此 MCP 服务器向任何使用模型上下文协议 (Model Context Protocol) 的 AI 助手公开了该功能的一部分。
联系方式: alohatours@proton.me
许可证: MIT
以 aloha 精神构建。由 AI 提供支持。植根于夏威夷文化。 🌺
Find the best budget deals and discounts for Hawaii tours and activities. Includes Groupon deals, sales, and value options.
| Name | Required | Description | Default |
|---|---|---|---|
| activity | Yes | Type of activity, e.g. 'snorkeling', 'helicopter', 'luau', 'food tour' | |
| max_price_dollars | No | Maximum price per person | |
| limit | No | Number of deals to return |
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 mentions 'budget deals,' 'discounts,' and sources like Groupon, implying a search or read operation, but doesn't clarify if it's read-only, requires authentication, has rate limits, or what the output format might be. For a tool with no annotations, this leaves significant behavioral gaps, such as whether it performs external API calls or returns structured data.
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, stating the core purpose in the first sentence. The second sentence adds useful context about deal types without redundancy. Both sentences earn their place by clarifying scope, making it efficient and well-structured, though it could be slightly more detailed for a perfect score.
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 (3 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain return values, error handling, or behavioral traits like data freshness or limitations. Without annotations or output schema, the description should provide more context on what the tool returns and how it behaves, but it falls short, leaving the agent with insufficient information for reliable use.
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 has 100% description coverage, providing clear details for all parameters (activity, max_price_dollars, limit). The description adds no additional parameter semantics beyond implying a focus on 'budget' and 'discounts,' which loosely relates to max_price_dollars but doesn't enhance the schema's information. With high schema coverage, the baseline score is 3, as the description doesn't compensate with extra insights.
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 the best budget deals and discounts for Hawaii tours and activities.' It specifies the verb 'find' and resource 'deals and discounts,' and mentions sources like Groupon deals, sales, and value options. However, it doesn't explicitly differentiate from sibling tools like 'search_hawaii_tours' or 'plan_hawaii_day,' which might also involve finding activities, so it lacks sibling differentiation for a perfect score.
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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools or specify contexts like budget-focused searches versus general planning. Without explicit when-to-use or when-not-to-use instructions, the agent must infer usage from the description alone, which is insufficient for effective tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a suggested full-day itinerary for a Hawaiian island or area. Includes morning, afternoon, and evening activities with booking links.
| Name | Required | Description | Default |
|---|---|---|---|
| island | Yes | Which island | |
| vibe | No | Trip vibe | chill |
| area | No | Specific area like 'waikiki', 'north shore', 'kona' |
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 mentions 'booking links,' hinting at external resources, but does not cover critical aspects like whether this tool requires authentication, has rate limits, returns real-time data, or involves any destructive actions. For a tool with no annotations, this leaves significant gaps in understanding its behavior and 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 a single, well-structured sentence that efficiently conveys the tool's purpose and output. It is front-loaded with the main action ('Get a suggested full-day itinerary') and includes essential details without unnecessary words, making it highly concise and effective.
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 (3 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and output structure but lacks details on behavioral traits, error handling, or how the itinerary is generated. Without annotations or an output schema, more context on what the tool returns and its operational constraints would improve 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?
The schema description coverage is 100%, with clear descriptions for all parameters (island, vibe, area). The description adds minimal value beyond the schema, as it does not explain how parameters affect the itinerary (e.g., how 'vibe' influences activity selection) or provide additional context. With high schema coverage, the baseline score of 3 is appropriate, as the description does not significantly enhance parameter understanding.
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 with a specific verb ('Get') and resource ('suggested full-day itinerary for a Hawaiian island or area'), and it distinguishes from siblings by focusing on itinerary planning rather than deals, events, or tours. It specifies the output structure ('morning, afternoon, and evening activities with booking links'), making the purpose explicit and differentiated.
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 implies usage for itinerary planning but does not explicitly state when to use this tool versus alternatives like get_hawaii_deals, search_hawaii_events, or search_hawaii_tours. It provides some context by mentioning 'booking links,' suggesting it might be for planning with booking options, but lacks clear exclusions or direct comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find upcoming events, concerts, festivals, and nightlife across all Hawaiian islands. Covers 579+ events from 70+ venues.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | What kind of event, e.g. 'live music', 'luau', 'concert', 'food festival' | |
| island | No | Which island | any |
| days_ahead | No | How many days ahead to search |
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 mentions the data scope ('579+ events from 70+ venues') but does not cover critical aspects like rate limits, authentication needs, pagination, or error handling. For a search tool with zero annotation coverage, this leaves significant gaps in understanding its operational 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 front-loaded and efficient, consisting of two sentences that convey the tool's purpose and scope without unnecessary details. Every sentence adds value, making it appropriately sized 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 moderate complexity (3 parameters, no annotations, no output schema), the description is partially complete. It covers the purpose and data scope but lacks behavioral details and output information. Without an output schema, the description should ideally hint at return values, but it does not, leaving gaps in contextual understanding.
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 schema already documents all parameters (query, island, days_ahead) with descriptions and defaults. The description does not add any parameter-specific information beyond what the schema provides, such as examples or constraints, resulting in a baseline score of 3.
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 with specific verbs ('Find upcoming events, concerts, festivals, and nightlife') and resources ('across all Hawaiian islands'), distinguishing it from siblings like get_hawaii_deals or search_hawaii_tours by focusing on events rather than deals or tours. It also provides scope details ('579+ events from 70+ venues'), making it highly specific.
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 no guidance on when to use this tool versus alternatives like get_hawaii_deals or plan_hawaii_day. It mentions the scope but does not specify contexts, prerequisites, or exclusions, leaving the agent to infer usage based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Hawaii tours and activities by keyword, island, price range, and category. Returns bookable experiences with pricing and affiliate links.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What the user is looking for, e.g. 'snorkeling with turtles', 'helicopter tour', 'family luau' | |
| island | No | Which Hawaiian island | any |
| max_price_dollars | No | Maximum price per person in USD | |
| category | No | Type of experience | any |
| limit | No | Number of results to return |
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 mentions that the tool returns 'bookable experiences with pricing and affiliate links', which gives some insight into output behavior. However, it lacks details on permissions, rate limits, error handling, or whether the search is real-time or cached, leaving significant gaps for a tool with multiple parameters.
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, well-structured sentence that efficiently conveys the tool's purpose, key parameters, and output. It is front-loaded with the main action and includes no redundant or unnecessary information, making it highly concise.
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 (5 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and output type but lacks behavioral details and usage guidelines relative to siblings. Without annotations or output schema, more context on permissions, errors, or result formatting would improve 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%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema by listing the search criteria (keyword, island, price range, category) but does not provide additional syntax, format, or usage context for parameters. This meets the baseline for high schema coverage.
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 for Hawaii tours and activities by specific criteria (keyword, island, price range, category) and returns bookable experiences with pricing and affiliate links. It uses a specific verb ('search') and resource ('Hawaii tours and activities'), but does not explicitly distinguish it from sibling tools like 'search_hawaii_events' or 'get_hawaii_deals', which likely have overlapping domains.
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 no guidance on when to use this tool versus alternatives like 'search_hawaii_events' or 'get_hawaii_deals'. It mentions the tool's functionality but does not specify contexts, prerequisites, or exclusions that would help an agent choose between sibling tools effectively.
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.0.0get_hawaii_dealsplan_hawaii_daysearch_hawaii_eventssearch_hawaii_toursScored across 4 tools
Each tool has a clearly distinct purpose: get_hawaii_deals focuses on budget deals and discounts, plan_hawaii_day provides full-day itineraries, search_hawaii_events finds events and nightlife, and search_hawaii_tours searches for tours and activities. There is no overlap or ambiguity between these functions.
All tool names follow a consistent verb_noun pattern with 'hawaii' as a common domain identifier: get_hawaii_deals, plan_hawaii_day, search_hawaii_events, and search_hawaii_tours. The naming is predictable and uniform throughout.
With 4 tools, the count is reasonable for a Hawaii travel planning server, covering key areas like deals, itineraries, events, and tours. It is slightly on the lower side but well-scoped for its purpose, with each tool earning its place.
The tool set covers core travel planning functions: finding deals, planning days, searching events, and searching tours. Minor gaps might include tools for accommodations or transportation, but agents can likely work around these with the provided tools for a comprehensive Hawaii trip experience.
Skiplagged MCP Server for flight search, hotel booking, and travel planning
Public MCP server for discovering open jobs. Search, filter, and get application links.
AI marketplace — flights, tours, activities, transport & more via MCP. No auth required.
Hotel booking MCP server. Search, book, and manage reservations across 250K+ properties worldwide.
