The aloha-fyi-hawaii server provides AI assistants with real, bookable Hawaii tourism data for trip planning across the Hawaiian islands.
search_hawaii_tours: Search 2,583+ bookable tours and activities (snorkeling, helicopter tours, luaus, etc.) by keyword, island (Oahu, Maui, Big Island, Kauai), price range, and category. Returns pricing, ratings, and affiliate booking links from Viator, GetYourGuide, Klook, and Groupon.
search_hawaii_events: Find 579+ upcoming events (concerts, festivals, luaus, nightlife) across 70+ venues, filterable by keyword, island, and how many days ahead to look.
get_hawaii_deals: Discover budget-friendly deals and discounts on tours and activities (including Groupon offers), sorted by value, with a configurable maximum price (default $100).
plan_hawaii_day: Generate a curated full-day itinerary (morning, afternoon, evening) for a specific island or area, customized by vibe (adventure, chill, cultural, romantic, family, or budget), with booking links included.
Integrates Groupon deals and discounts for Hawaii tourism activities, allowing search and access to budget-friendly options through the MCP server.
Integrates Klook booking platform for Hawaii tours and activities, providing access to bookable experiences through the MCP server's search capabilities.
The first dedicated Hawaii tourism MCP server. Hawaii tours, events, and deals for AI assistants — now with AAAK structured-response support so consumer agents can parse results without re-parsing prose.
When someone asks Claude, ChatGPT, or any AI "what should I do in Hawaii?" — this MCP server returns real, bookable data:
2,500+ bookable experiences from partner booking platforms (live counts: /health)
Live events across Oahu, Maui, Big Island, and Kauai, refreshed weekly
600+ curated restaurants across the islands
Live weather for all four islands (OpenMeteo)
Day-plan itineraries with morning / lunch / afternoon / dinner picks
Affiliate tracking on every booking link
Real MCP protocol — Streamable HTTP, stateless, spec version 2025-03-26
AAAK v0.1 — typed structuredContent envelope alongside human-readable text. See docs/aaak-spec.md.
Powered by aloha.fyi — Hawaii's AI concierge.
Note on canonical source. This repository is the public-facing mirror of the production
mcp-serverdirectory insidebaphometnxg/Nani-V3. Production deploys are driven from there; this repo is kept in sync as a standalone reference for community use and for anyone who wants to self-host. File issues here or upstream — both work.
Production MCP server (no install, no setup):
https://mcp.aloha.fyi/mcpTransport: Streamable HTTP (stateless)
Protocol version: 2025-03-26
Auth: none (public, read-only)
Health: GET /health — returns aaak: { protocol, enabled, allowlist_size } so deploy state is observable
Discovery: GET /.well-known/mcp/server.json
Related MCP server: Famxplor Family Travel Activities
By default, MCP tool results come back as a prose blob — agents that want to consume the data programmatically have to re-parse markdown to recover prices, booking URLs, islands, etc. AAAK fixes that.
When AAAK is enabled (and the calling client is on the allowlist), every tool result includes a typed structuredContent field carrying the data in machine-parseable form, and the marketing trailer is dropped from text to save tokens. When AAAK is off, the wire format is byte-equivalent to v1.0.0 — no surprises for clients that don't opt in.
Lossless invariants — preserved on every revenue-bearing row:
booking_url (affiliate revenue)
source (compliance + attribution)
price_cents (the only numeric field user decisions hinge on)
island (every recommendation is island-scoped)
Example (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 }
}Full spec: docs/aaak-spec.md. Generated JSON Schema: docs/aaak.schema.json.
Verification scripts for self-hosters and contributors:
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 probeAdd to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"aloha-fyi-hawaii": {
"url": "https://mcp.aloha.fyi/mcp"
}
}
}Restart Claude Desktop. You should see the six Hawaii tools appear in the tool picker. Try:
Find me snorkeling tours in Oahu under $100
What events are happening in Honolulu this weekend?
Plan a family adventure day on the Big Island — cheapest options
Any client that supports Streamable HTTP MCP can point directly at:
https://mcp.aloha.fyi/mcpNo API key, no OAuth, no signup.
curl -X POST https://mcp.aloha.fyi/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_toursSearch 2,500+ bookable Hawaii tours and activities by keyword, island, price range. Returns tours with booking links; filter by platform via source.
Param | Type | Description |
| string (required) | e.g. "snorkeling", "helicopter tour", "family luau" |
|
| Defaults to |
| number | Maximum price per person in USD |
|
| Filter by booking platform |
| number | Results (max 20, default 5) |
get_hawaii_dealsFind budget deals and discounts. Returns discounted and low-price options sorted cheapest first.
Param | Type | Description |
| string (required) | e.g. "snorkeling", "helicopter", "luau" |
| number | Default 100 |
| number | Results (max 20, default 5) |
search_hawaii_eventsFind upcoming events, concerts, festivals, and nightlife across all Hawaiian islands. Updated weekly from venue and promoter sources.
Param | Type | Description |
| string | e.g. "live music", "luau", "concert" |
|
| Defaults to |
| number | How many days ahead to search (default 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.jsRequires:
Node.js 20+
DATABASE_URL env var (PostgreSQL with an experiences table — schema in schema.sql)
No PII is collected by the MCP server. Stateless mode — no sessions, no cross-request profiles. Standard request metadata is logged for abuse prevention only.
Full privacy policy: aloha.fyi/privacy
Built by Michael Crain — Hawaii resident, cinematographer, and founder of aloha.fyi.
aloha.fyi is an AI-powered multilingual tourism concierge for Hawaii's visitor industry. The concierge agent "Nani" speaks 5 languages (English, Japanese, Korean, Chinese, Spanish) and has access to 2,500+ bookable experiences across multiple partner platforms.
This MCP server exposes a subset of that capability to any AI assistant that speaks the Model Context Protocol.
Website: https://aloha.fyi
Contact: alohatours@proton.me
License: MIT
Built with aloha. Powered by AI. Rooted in Hawaiian culture. 🌺
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. Dates show when Glama detected each change.
v1.0.0get_hawaii_dealsplan_hawaii_daysearch_hawaii_eventssearch_hawaii_toursEach 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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/baphometnxg/aloha-fyi-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
