Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

datasets_housing_markets_facets

Facet the US housing markets dataset and return aggregation counts by region type, state, property type, parent metro, income vintage, latest status, or period.

Instructions

Facet the US housing markets dataset. Returns terms aggregation counts for the housing markets dataset. Facet enum: region_type, state_code, property_type, parent_metro, parent_metro_code, income_vintage, is_latest, period_begin. region_type enum: national, metro, county, city, zip. property_type enum: All Residential, Single Family Residential, Condo/Co-op, Townhouse, Multi-Family (2-4 Unit), Single Units Only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoFull-text query over region name and city, max 256 characters
facetYesFacet enum: region_type, state_code, property_type, parent_metro, parent_metro_code, income_vintage, is_latest, period_begin
latestNoFilter for the most recent period per region and property type
periodNoExact period start date filter, YYYY-MM-DD
zip_codeNoExact zip code filter (zip-level rows only), e.g. 60616
state_codeNoExact two-letter state code filter, e.g. CA
region_typeNoRegion level enum: national, metro, county, city, zip
max_inventoryNoMaximum active inventory
min_inventoryNoMinimum active inventory
property_typeNoProperty type enum: All Residential, Single Family Residential, Condo/Co-op, Townhouse, Multi-Family (2-4 Unit), Single Units Only
max_median_domNoMaximum median days on market
min_homes_soldNoMinimum homes sold in the period
min_median_domNoMinimum median days on market
max_salary_to_buyNoMaximum salary needed to buy in USD per year
min_salary_to_buyNoMinimum salary needed to buy in USD per year
parent_metro_codeNoExact parent metro (CBSA) code filter, e.g. 16980
max_price_to_incomeNoMaximum price-to-income ratio
min_price_to_incomeNoMinimum price-to-income ratio
max_median_list_priceNoMaximum median list price in USD
max_median_sale_priceNoMaximum median sale price in USD
min_median_list_priceNoMinimum median list price in USD
min_median_sale_priceNoMinimum median sale price in USD

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.17.5
    • addedInput schema / properties / facet / enum
      Added value: +[
+  "region_type",
+  "state_code",
+  "property_type",
+  "parent_metro",
+  "parent_metro_code",
+  "income_vintage",
+  "is_latest",
+  "period_begin"
+]
    • addedInput schema / properties / region_type / enum
      Added value: +[
+  "national",
+  "metro",
+  "county",
+  "city",
+  "zip"
+]
  2. Addedv1.5.0

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose the return shape ('terms aggregation counts'), which is useful, but it says nothing about whether filters constrain the aggregation, whether results are paginated, or any limits on the counts returned. This is adequate but leaves the agent guessing about core behavior beyond the output format.

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 short, front-loaded with the action, and the enum lists are organized clearly. It is somewhat redundant with the schema (repeating enum values), but the length is justified for a tool with enumerable facets and does not waste words.

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

Completeness3/5

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

For a 22-parameter tool with no annotations and no output schema, the description is thin: it does not explain how the many filter parameters interact with the facet aggregation, nor what a typical response looks like beyond 'terms aggregation counts.' It is minimally viable but leaves significant context to be inferred from the input 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 description coverage is 100%, so the baseline is 3 even without extra parameter detail in the description. The description repeats the facet, region_type, and property_type enums already present in the schema, adding no new meaning beyond what the structured fields already provide.

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 ('Facet'), resource ('US housing markets dataset'), and output form ('terms aggregation counts'), making the core purpose clear. It does not name or distinguish itself from the sibling `datasets_housing_markets_search`, so an agent must infer the facet-vs-search distinction from the sibling name rather than from the description.

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

Usage Guidelines2/5

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

No guidance is given about when to use this tool instead of alternatives such as `datasets_housing_markets_search` or `datasets_housing_markets_item`. The description implies faceting use but provides no exclusions, prerequisites, or conditions that would help an agent choose among the sibling dataset 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