Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

datasets_airbnb_facets

Compute suppressed facet distribution counts for Airbnb market listings, honoring filters like country, market, rating, room type, and amenities to analyze segment sizes.

Instructions

Facet the Airbnb markets dataset. Returns suppressed distribution counts over the Airbnb markets dataset, honoring the same filters as search. Facet enum: country, market, currency, superhost, guest_favorite, rating_band, review_band, admin1 (top subdivision), locality (settlement), room_type (entire_place/private_room/hotel/shared_room), property_type (Airbnb's canonical listing type from the detail page), amenities (each amenity with the count of listings offering it). Enrichment-derived facets include a coverage object with the number and share of filtered listings carrying that dimension; buckets stay empty below the 20% minimum visibility gate. Coverage above the gate may still be partial. group_by enum: country, market, admin1, locality, room_type, property_type.

Input Schema

NameRequiredDescriptionDefault
facetYesFacet enum: country, market, currency, superhost, guest_favorite, rating_band, review_band, admin1, locality, room_type, property_type, amenities
marketNoExact metro-market filter, max 128 characters
countryNoExact ISO-3166-1 alpha-2 country filter, e.g. FR
group_byNoAggregate cell dimension enum: country, market, admin1, locality, room_type, property_type. Defaults to country
superhostNoCount only Superhost listings
min_ratingNoMinimum listing rating, from 0 through 5
active_sinceNoFreshness filter, an ISO-8601 date (YYYY-MM-DD)
min_listingsNoMinimum listings per bucket; raises the small-cell suppression floor
guest_favoriteNoCount only Guest Favorite listings (an observed lower bound; the badge under-counts)
min_review_countNoMinimum listing review count, 0 or greater

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.17.5
    • addedInput schema / properties / facet / enum
      Added value: +[
+  "country",
+  "market",
+  "currency",
+  "superhost",
+  "guest_favorite",
+  "rating_band",
+  "review_band",
+  "admin1",
+  "locality",
+  "room_type",
+  "property_type",
+  "amenities"
+]
    • addedInput schema / properties / group_by / enum
      Added value: +[
+  "country",
+  "market",
+  "admin1",
+  "locality",
+  "room_type",
+  "property_type"
+]
  2. Changed3 schema fields changedv1.5.0
    • changedInput schema / properties / facet / description
      Previous value: -"Facet enum: country, market, currency, superhost, rating_band, review_band"New value: +"Facet enum: country, market, currency, superhost, guest_favorite, rating_band, review_band, admin1, locality, room_type, property_type, amenities"
    • changedInput schema / properties / group_by / description
      Previous value: -"Aggregate cell dimension enum: country, market. Defaults to country"New value: +"Aggregate cell dimension enum: country, market, admin1, locality, room_type, property_type. Defaults to country"
    • addedInput schema / properties / guest_favorite
      Added value: +{
+  "description": "Count only Guest Favorite listings (an observed lower bound; the badge under-counts)",
+  "type": "boolean"
+}
  3. Addedv1.2.0

TDQS

A3.8/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 well: it discloses small-cell suppression, a 20% minimum visibility gate below which buckets stay empty, a coverage object with count and share, and that coverage above the gate 'may still be partial'. It does not cover auth, rate limits, or response shape, but the suppression/coverage semantics are genuinely useful and not in any structured field.

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?

Dense but front-loaded with the core action first, then enum detail, then suppression caveats. There is minor redundancy ('Airbnb markets dataset' repeated in the opening two sentences), but the size is justified by two enums that must be spelled out.

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 10-parameter tool with no annotations and no output schema, the description covers the facets, group_by, suppression behavior, and coverage semantics adequately. It could say more about the shape of the returned distribution counts, but it is complete enough for an agent to call the tool correctly.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning over the schema by defining enum values the schema only lists (e.g. admin1 = top subdivision, locality = settlement, property_type = canonical detail-page type, amenities = per-amenity listing counts) and explaining the group_by dimension defaults. This enriches the enum semantics beyond the structured field.

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

Purpose4/5

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

The description states a specific verb and resource ('Facet the Airbnb markets dataset. Returns suppressed distribution counts') and enumerates the exact facets produced, so an agent knows this returns aggregates rather than listings. It references 'the same filters as search', which implicitly links it to datasets_airbnb_search, but does not explicitly contrast the two.

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 only implied: the reader infers this tool is for aggregate/distribution views while search is for listings, and that filters carry over ('honoring the same filters as search'). There is no explicit when-to-use/when-not statement or named alternative to steer selection among the many sibling datasets tools.

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