ハワイ観光専用の最初のMCPサーバーです。 AIアシスタント向けのハワイのツアー、イベント、お得な情報を提供します。AAAK構造化レスポンス対応により、コンシューマーエージェントは散文を再解析することなく結果を処理できます。
Claude、ChatGPT、その他のAIに「ハワイで何をすべき？」と尋ねると、このMCPサーバーは予約可能な実データを返します：
2,583件の予約可能な体験（Viator、GetYourGuide、Klook、Groupon）
579件のイベント（オアフ島、マウイ島、ハワイ島、カウアイ島）
540件以上の厳選レストラン（ワイキキおよびオアフ島全域）
ライブ天気情報（全4島対応、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 } を返し、デプロイ状態を確認可能
ディスカバリー：GET /.well-known/mcp/server.json
Related MCP server: Famxplor Family Travel Activities
デフォルトでは、MCPツールの結果は散文の塊として返されます。データをプログラムで利用したいエージェントは、価格、予約URL、島名などを抽出するためにMarkdownを再解析する必要があります。AAAKはこれを解決します。
AAAKが有効な場合（かつ呼び出し側のクライアントが許可リストにある場合）、すべてのツール結果には、機械可読形式でデータを保持する型付きの structuredContent フィールドが含まれ、トークン節約のためにマーケティング用の末尾テキストは text から削除されます。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スキーマ：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 probeClaude 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を再起動します。ツールピッカーに3つのハワイ関連ツールが表示されるはずです。以下を試してみてください：
オアフ島で100ドル以下のシュノーケリングツアーを探して
今週末ホノルルで開催されるイベントは何？
ハワイ島での家族向けアドベンチャーの一日を計画して — 最安値のオプションで
ストリーミングHTTP MCPをサポートするすべてのクライアントは、以下に直接接続できます：
https://mcp-server-nani-v3-20.up.railway.app/mcpAPIキー、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 | 1人あたりの最大価格（USD） | ||||
|
|
|
|
|
| 予約プラットフォームでフィルタリング |
| 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 は、ハワイの観光産業向けのAI搭載多言語観光コンシェルジュです。コンシェルジュエージェント「Nani」は5言語（英語、日本語、韓国語、中国語、スペイン語）を話し、6つのアフィリエイトネットワークにわたる2,583件の予約可能な体験にアクセスできます。
このMCPサーバーは、Model Context Protocolを話すあらゆるAIアシスタントに対して、その機能の一部を公開します。
ウェブサイト: https://aloha.fyi
連絡先: alohatours@proton.me
ライセンス: MIT
アロハの心で構築。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.
