Skip to main content
Glama
Crawlora MCP

Crawlora MCP

Official

datasets_airbnb_hosts_search

Search and filter Airbnb host profiles by name, bio, location, reviews, listings, Superhost or identity status, then sort results by review count, listing count, or hosting tenure.

Instructions

Search the Airbnb hosts dataset. Searches Airbnb hosts from the dataset id enum value airbnb-hosts — public host profiles with display name, location, bio, Superhost and identity-verification status, hosting tenure, total guest reviews, number of listings and interests. Each record is one host, not one listing. Sort enum: review_count_desc, listing_count_desc, hosting_years_desc, relevance. Billing: this search costs 1 credit per record returned, with a minimum of 2 (an empty result costs 2, a full page of 100 costs 100).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "datasets_airbnb_hosts_search"
  }
}

Input Schema

NameRequiredDescriptionDefault
qNoFull-text query over host name and bio, max 256 characters
pageNoPage number, defaults to 1
sortNoSort enum: review_count_desc, listing_count_desc, hosting_years_desc, relevance
interestNoExact interest as returned by the interest facet, e.g. Architecture, max 128 characters
locationNoFree-text match over the profile location, e.g. Portugal; every word must match, max 128 characters
page_sizeNoPage size, defaults to 20 and maxes at 100; page * page_size must be <= 10000
min_reviewsNoMinimum total guest reviews received, 0 or greater
is_home_hostNoFilter on the home-host flag
is_superhostNotrue keeps only Superhosts, false keeps only hosts without the badge
max_listingsNoMaximum number of listings the host manages, 0 or greater
min_listingsNoMinimum number of listings the host manages, 0 or greater
verificationNoExact verification as returned by the verification facet, e.g. Identity, max 128 characters
identity_verifiedNotrue keeps only hosts whose identity is verified
min_hosting_yearsNoMinimum years of hosting, 0 or greater

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.20

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does meaningful work: it discloses the credit billing model, including the non-obvious minimum of 2 credits (empty result costs 2, full page of 100 costs 100), which directly shapes page_size choices. It also clarifies record granularity. It stops short of stating auth requirements, result-cap/pagination behaviour beyond the schema's 10000-row constraint, or what the response payload contains.

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

Conciseness5/5

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

Three sentences, front-loaded with the resource definition before sort and billing details. Every clause carries information: dataset identity, record granularity, the sort vocabulary, and the cost model — no filler or marketing language.

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?

For a 14-parameter, annotation-free search tool with a fully documented schema, the description covers the essentials an agent needs to call it sensibly: what a record is, how to sort, and what it costs. The remaining gap is guidance on the sibling workflow (facet → search → item) and any indication of the response envelope, which matters somewhat given there is no output schema.

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 100%, so every parameter is already documented, and the description's sort enum listing largely restates the schema. The one genuine addition is tying cost to records returned, which gives page_size a business meaning the schema lacks. Otherwise it adds no semantics for the 14 filters (e.g. whether filters combine with AND, or how location word-matching behaves).

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?

States a specific verb and resource ("Search the Airbnb hosts dataset") and immediately defines the entity and payload: display name, location, bio, Superhost and verification status, tenure, review count, listing count, interests. The clause "Each record is one host, not one listing" explicitly disambiguates it from listing-oriented siblings such as airbnb_host_listings or airbnb_search.

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

Usage Guidelines3/5

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

Usage is implied rather than prescribed: an agent can infer this is the host-lookup tool, and the sort enum values hint at the common query shapes. But there is no explicit when-to-use/when-not-to-use guidance, no mention of when to prefer datasets_airbnb_hosts_facets for discovering interest/verification values or datasets_airbnb_hosts_item for a single profile — the facet dependency is only nodded at inside parameter text.

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

Deploy Server

Other Tools