Tineo

Search Airbnbs

assistant_airbnb_search_user

Read-onlyIdempotent

Search Airbnb listings by location and dates. Use when the user is not asking about a specific trip in Tineo. Returns a slim list of cards (title, type, rating, host, URL). location must be a city or area, not a whole country (ask the user which city). Each card has distance_km from the requested place and in_requested_area; listings outside the area come last. If none are in the area, say so with their distances and do NOT re-search the same place with a reworded location string. Amenity filtering only via the amenities enum; there is NO keyword/free-text filter, so tell the user anything else can't be filtered. If structuredContent.status is 'unavailable', do NOT retry the same search: share structuredContent.fallback_search_url (a prefilled airbnb.com search), offer a hotel search, or a support ticket.

Input Schema

Name	Required	Description
`adults`	No
`infants`	No	Infants under 2. Airbnb does not count them as guests.
`check_in`	Yes	Check-in date YYYY-MM-DD.
`children`	No
`currency`	No	ISO 4217 currency code (default USD).
`location`	Yes	City, neighborhood, or landmark with its region and country (e.g., 'Lisbon, Portugal', 'Brooklyn, NY, USA', 'Orange, NSW, Australia').
`min_beds`	No
`amenities`	No	Only listings with ALL of these amenities. These are the only supported amenity filters; there is no keyword/free-text filter.
`check_out`	Yes	Check-out date YYYY-MM-DD.
`price_max`	No
`price_min`	No
`room_type`	No
`max_results`	No	Default 5, max 5.
`min_bedrooms`	No
`min_bathrooms`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 20, 2026

addedInput schema / properties / infants

Added value: +{
+  "description": "Infants under 2. Airbnb does not count them as guests.",
+  "maximum": 5,
+  "minimum": 0,
+  "type": "integer"
+}

Changed1 schema field changedOct 17, 2026

changedInput schema / properties / location / description

Previous value: -"City, neighborhood, or landmark (e.g., 'Lisbon, Portugal', 'Brooklyn')."New value: +"City, neighborhood, or landmark with its region and country (e.g., 'Lisbon, Portugal', 'Brooklyn, NY, USA', 'Orange, NSW, Australia')."

First observedOct 3, 2026

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/openWorld/non-destructive, yet the description adds substantial behavioral context beyond them: the returned card fields, area-membership ordering via distance_km/in_requested_area, the amenity-only filtering constraint (no keyword filter), and the unavailable-status handling with fallback_search_url and the explicit 'do NOT retry' rule.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with purpose and scope, and each sentence contributes actionable guidance rather than filler. It is somewhat dense and run-on, but the length is justified by the tool's complexity (15 params, no output schema, sibling disambiguation).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly explains the return value (slim list of cards) and even the structuredContent.status/fallback_search_url failure path. Combined with the location and amenity constraints, it is nearly complete for invocation; the gap is the unaddressed remaining query parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 47%, below the 50% threshold, so the description carries a compensation burden. It adds real meaning for location ('must be a city or area, not a whole country') and amenities (enum-only, no free-text), but says nothing about guests, price, room_type, beds/bathrooms, or max_results, leaving half the parameters undocumented in both places.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb+resource ('Search Airbnb listings by location and dates') and explicitly carves out scope with 'Use when the user is not asking about a specific trip in Tineo,' clearly distinguishing it from the sibling assistant_airbnb_search_trip. It also characterizes the output shape, so the agent knows exactly what this tool returns.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit when/when-not guidance (trip-specific vs general search), a location pre-condition to resolve with the user, an anti-pattern rule ('do NOT re-search the same place with a reworded location string'), and concrete alternatives for the unavailable case (fallback_search_url, hotel search, support ticket). This is the strongest form of routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Tineo tools Inspect

Try in Browser

Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?