Loading ToolBench
MCP server for Airbnb search and listing details
The server defines 2 tools with explicit schemas and descriptions visible in index.ts. Both tools follow verb_noun naming (airbnb_search, airbnb_listing_details) and have non-empty descriptions (>20 chars). Schemas are present with typed properties. However, descriptions are minimal and lack LLM optimization guidance (what to do when, prerequisites, when to use vs similar tools). Parameter descriptions exist but are sparse (single phrases, no constraints or format guidance). Output schemas are not documented, LLMs cannot predict what fields will be returned. Error handling is basic (McpError used but no recovery guidance visible). Security: the tool accepts ignoreRobotsText parameter to override robots.txt, raising concerns about responsible crawling and compliance. Overall, this is a functional but thin implementation lacking the depth needed for production confidence.
Get detailed information about a specific Airbnb listing. Provide direct links to the user
Search for Airbnb listings with various filters and pagination. Provide direct links to the user
Minimal tool descriptions lack LLM-optimization guidance. 'Search for Airbnb listings with various filters and pagination. Provide direct links to the user' does not explain WHEN to use this tool, WHAT the output structure looks like, or any prerequisites. Average A+ tool descriptions are 194 chars; these are ~90 chars with generic phrasing.
Output schemas are not documented in the code. LLMs cannot plan downstream operations or extract the correct fields without knowing what fields are returned, their types, or which are nullable. Zero visibility into response structure (e.g., does airbnb_search return listings array with fields [id, name, price, url, availability]?).
ignoreRobotsText parameter (boolean flag on both tools) allows bypassing robots.txt rules. This raises compliance and ethical concerns, Airbnb's robots.txt likely forbids scraping. No description explains the risk, legal implications, or when this should ever be used. Tool descriptions should make state-modifying or risky operations explicit.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 30 | - | v1 |
Parameter descriptions are minimal single phrases with no format guidance. E.g., 'Check-in date (YYYY-MM-DD)' is acceptable but lacks dependency hints ('required if searching availability') or validation rules. 'Number of adults' lacks min/max constraints. LLMs cannot infer bounds, they may pass negative or absurd values.
No pagination limit documented. airbnb_search accepts a cursor parameter but does not state how many results are returned per call, what the maximum page size is, or what total count looks like. Without result limits, LLMs may receive contexts blown out by hundreds of listings.
Error handling visible in code (McpError, ErrorCode) but no guidance on recovery, categorization, or next steps. Code imports ErrorCode but no documentation of how errors map to user-fixable vs. retryable vs. fatal. LLMs receive raw errors with no actionable path forward.
propertyType enum on airbnb_search includes 4 values (entire_home, private_room, shared_room, hotel_room) with decent descriptions in the parameter annotation, but parameter descriptions lack guidance on mutual exclusivity or what happens if multiple property types are desired. LLMs may misunderstand whether the parameter filters to one type or accepts multiple.