Local RapidAPI MCP server for ContinuumOS providing Airbnb accommodation search and OpenWeather current weather data
Two tools with minimal documentation. Both have basic input schemas with type definitions, but descriptions are extremely brief (under 20 chars baseline violation). Parameter descriptions are present but generic. No output schemas documented. No error handling guidance. Tool names follow verb_noun pattern but lack clarity on what distinguishes them from similar travel/weather tools. Missing idempotency, pagination, and composition guidance.
Get current weather from OpenWeather for a city.
Search accommodations using RapidAPI Airbnb endpoint with placeId.
Descriptions critically short (under 20 chars). 'Search accommodations using RapidAPI Airbnb endpoint with placeId' and 'Get current weather from OpenWeather for a city' lack WHEN to use, prerequisites, and return value guidance. LLMs cannot determine tool selection intent.
No output schemas documented. LLMs cannot plan downstream calls or extract required fields (e.g., does Airbnb search return booking_id, price, availability?). Violates pattern:tool requirement.
Parameter descriptions are generic ('Number of adults', 'Currency code', 'City name'). Missing format constraints, valid ranges, and dependency hints. E.g., does placeId accept Google Place IDs only? What format? What if invalid?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 39 | 2026-07-28+ | v2 |
No error handling guidance. If placeId is invalid or API rate-limited, what should the LLM do? No recovery hints, retryability classification, or actionable error messages defined.
API credentials (RAPIDAPI_KEY, OPEN_WEATHER_MAP_API_KEY) exposed in .mcp.json config file. While not tool parameters, this violates secret-injection pattern, credentials should use vault or secure env injection, never checked into repos.