El primer servidor MCP dedicado al turismo en Hawái. Tours, eventos y ofertas de Hawái para asistentes de IA — ahora con soporte para respuestas estructuradas AAAK, para que los agentes de consumo puedan analizar los resultados sin tener que volver a procesar el texto.
Cuando alguien le pregunta a Claude, ChatGPT o cualquier IA "¿qué debería hacer en Hawái?", este servidor MCP devuelve datos reales y reservables:
2583 experiencias reservables de Viator, GetYourGuide, Klook y Groupon
579 eventos en Oahu, Maui, la Isla Grande y Kauai
Más de 540 restaurantes seleccionados en Waikiki y en todo Oahu
Clima en tiempo real para las cuatro islas (OpenMeteo)
Itinerarios de planes diarios con opciones para mañana / almuerzo / tarde / cena
Seguimiento de afiliados en cada enlace de reserva
Protocolo MCP real — HTTP transmitible, sin estado, versión de especificación 2025-03-26
AAAK v0.1 — sobre de structuredContent tipado junto con texto legible por humanos. Ver docs/aaak-spec.md.
Desarrollado por aloha.fyi — el conserje de IA de Hawái.
Nota sobre la fuente canónica. Este repositorio es el espejo público del directorio
mcp-serverde producción dentro debaphometnxg/Nani-V3. Las implementaciones de producción se gestionan desde allí; este repositorio se mantiene sincronizado como una referencia independiente para uso de la comunidad y para cualquiera que desee alojarlo por su cuenta. Reporta problemas aquí o en el repositorio original; ambos funcionan.
Servidor MCP de producción (sin instalación, sin configuración):
https://mcp-server-nani-v3-20.up.railway.app/mcpTransporte: HTTP transmitible (sin estado)
Versión del protocolo: 2025-03-26
Autenticación: ninguna (pública, solo lectura)
Salud: GET /health — devuelve aaak: { protocol, enabled, allowlist_size } para que el estado de la implementación sea observable
Descubrimiento: GET /.well-known/mcp/server.json
Related MCP server: Famxplor Family Travel Activities
Por defecto, los resultados de las herramientas MCP se devuelven como un bloque de prosa; los agentes que desean consumir los datos mediante programación tienen que volver a analizar el markdown para recuperar precios, URLs de reserva, islas, etc. AAAK soluciona esto.
Cuando AAAK está habilitado (y el cliente que realiza la llamada está en la lista de permitidos), cada resultado de herramienta incluye un campo structuredContent tipado que contiene los datos en una forma legible por máquina, y el tráiler de marketing se elimina del text para ahorrar tokens. Cuando AAAK está desactivado, el formato de transmisión es equivalente en bytes a la v1.0.0 — sin sorpresas para los clientes que no optan por usarlo.
Invariantes sin pérdida — preservadas en cada fila que genera ingresos:
booking_url (ingresos de afiliados)
source (cumplimiento + atribución)
price_cents (el único campo numérico del que dependen las decisiones del usuario)
island (cada recomendación está limitada a una isla)
Ejemplo (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 }
}Especificación completa: docs/aaak-spec.md. Esquema JSON generado: docs/aaak.schema.json.
Scripts de verificación para quienes alojan el servidor por su cuenta y colaboradores:
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 probeAñadir a la configuración de Claude Desktop (~/Library/Application Support/Claude/claude_desktop_config.json en macOS):
{
"mcpServers": {
"aloha-fyi-hawaii": {
"url": "https://mcp-server-nani-v3-20.up.railway.app/mcp"
}
}
}Reinicia Claude Desktop. Deberías ver las tres herramientas de Hawái aparecer en el selector de herramientas. Prueba:
Búscame tours de snorkel en Oahu por menos de $100
¿Qué eventos hay en Honolulu este fin de semana?
Planifica un día de aventura familiar en la Isla Grande — opciones más baratas
Cualquier cliente que admita MCP HTTP transmitible puede apuntar directamente a:
https://mcp-server-nani-v3-20.up.railway.app/mcpSin clave de API, sin OAuth, sin registro.
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_toursBusca entre 2583 tours y actividades reservables en Hawái por palabra clave, isla o rango de precios. Devuelve tours de Viator, GetYourGuide, Klook y Groupon con enlaces de reserva de afiliados.
Parámetro | Tipo | Descripción | ||||
| string (requerido) | ej. "snorkel", "tour en helicóptero", "luau familiar" | ||||
|
|
|
|
|
| Por defecto |
| number | Precio máximo por persona en USD | ||||
|
|
|
|
|
| Filtrar por plataforma de reserva |
| number | Resultados (máx 20, por defecto 5) |
get_hawaii_dealsEncuentra ofertas económicas y descuentos. Devuelve ofertas de Groupon y opciones de bajo precio ordenadas de menor a mayor.
Parámetro | Tipo | Descripción |
| string (requerido) | ej. "snorkel", "helicóptero", "luau" |
| number | Por defecto 100 |
| number | Resultados (máx 20, por defecto 5) |
search_hawaii_eventsEncuentra próximos eventos, conciertos, festivales y vida nocturna en todas las islas hawaianas. Más de 579 eventos de más de 70 lugares, actualizados semanalmente.
Parámetro | Tipo | Descripción | ||||
| string | ej. "música en vivo", "luau", "concierto" | ||||
|
|
|
|
|
| Por defecto |
| number | Cuántos días de antelación buscar (por defecto 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.jsRequiere:
Node.js 20+
Variable de entorno DATABASE_URL (PostgreSQL con una tabla experiences — esquema en schema.sql)
El servidor MCP no recopila PII (información de identificación personal). Modo sin estado: sin sesiones, sin perfiles entre solicitudes. Los metadatos de solicitud estándar se registran solo para la prevención de abusos.
Política de privacidad completa: aloha.fyi/privacy
Creado por Michael Crain — residente de Hawái, director de fotografía y fundador de aloha.fyi.
aloha.fyi es un conserje turístico multilingüe impulsado por IA para la industria de visitantes de Hawái. El agente conserje "Nani" habla 5 idiomas (inglés, japonés, coreano, chino, español) y tiene acceso a 2583 experiencias reservables en 6 redes de afiliados.
Este servidor MCP expone una parte de esa capacidad a cualquier asistente de IA que hable el Protocolo de Contexto de Modelo (MCP).
Sitio web: https://aloha.fyi
Contacto: alohatours@proton.me
Licencia: MIT
Creado con aloha. Impulsado por IA. Arraigado en la cultura hawaiana. 🌺
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.
