Skip to main content
Glama

Housing Intel

by io.github.pipeworx-io
OverviewDiscussionsAdmin

Housing Metro Demand

housing_metro_demand
Read-onlyIdempotent

Demand + rent-durability signals for a shortlist of US metros in ONE call — population & 5-year growth, renter share, median household income, and unemployment, straight from Census ACS. Deterministic by metro (CBSA-keyed) — NO FRED series-ID guessing. Pass metros ("City, ST", e.g. the top results from housing_market_screen). This is the Stage-2 "is the demand real?" filter on a yield shortlist — high yield in a shrinking metro is a trap. No API key needed. HIGHEST-LAG SOURCE IN THIS PACK: figures are a Census ACS 5-YEAR rolling average (currently 2018-2022, released Dec 2023) — for structural demand, not a current-quarter read. freshness states the exact age.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax metros to enrich (default 25, max 100).
metrosYesMetro names to enrich, "City, ST" form, e.g. ["Lubbock, TX","Pittsburgh, PA"] — match the housing_market_screen output. Required.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNo
metrosNo
matchedNo
acs_yearNo
analysisNo
freshnessNo
population_growth_basisNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "acs_year": {
+      "type": "number"
+    },
+    "analysis": {
+      "type": "string"
+    },
+    "freshness": {
+      "properties": {
+        "acs_5yr_release_date": {
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "age_days_since_release": {
+          "type": "number"
+        },
+        "as_of": {
+          "type": "string"
+        },
+        "statement": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "matched": {
+      "type": "number"
+    },
+    "metros": {
+      "items": {
+        "properties": {
+          "cbsa": {
+            "type": "string"
+          },
+          "median_household_income": {
+            "type": "number"
+          },
+          "metro": {
+            "type": "string"
+          },
+          "population": {
+            "type": "number"
+          },
+          "population_growth_5yr_pct": {
+            "type": "number"
+          },
+          "renter_share_pct": {
+            "type": "number"
+          },
+          "unemployment_rate_pct": {
+            "type": "number"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "note": {
+      "type": "string"
+    },
+    "population_growth_basis": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}
  2. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
+  {
+    "metros": [
+      "Lubbock, TX",
+      "Pittsburgh, PA"
+    ]
+  },
+  {
+    "limit": 10,
+    "metros": [
+      "Denver, CO",
+      "Austin, TX",
+      "Boise, ID"
+    ]
+  }
+]
  3. Added

TDQS

A4.9/5.0
Behavior5/5

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

While annotations already cover read-only, open-world, idempotent, and non-destructive aspects, the description goes well beyond by disclosing key behavioral traits: deterministic by CBSA, no API key required, and the crucial data-lag caveat that figures are a 5-year rolling average with an exact release date. This adds substantial operational context beyond what annotations provide.

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?

The description is dense but every sentence earns its place. It opens with the core purpose, then clarifies deterministic behavior, inserts usage context, and finishes with the critical data-lag warning. No redundancy; the structure front-loads the most important information and progressively adds operational caveats.

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

Completeness5/5

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

The presence of an output schema means return values need not be described. The description covers purpose, input format, usage context, data source, and lag, which is sufficient for an agent to correctly invoke the tool. The reference to `freshness` fields in the output further ties the behavioral caveat to the expected result, making this complete.

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 baseline is 3. The description adds meaning beyond the schema by specifying the exact 'City, ST' format for the metros parameter and referencing housing_market_screen output, which clarifies the expected input structure. It also implicitly explains the limit parameter's role by noting it is optional and capped, although the schema already covers that.

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 explicitly states the tool's function: 'Demand + rent-durability signals for a shortlist of US metros in ONE call' and enumerates the exact data points (population, growth, renter share, income, unemployment). It clearly differentiates from siblings by specifying the deterministic CBSA-keyed nature and explicitly contrasting with FRED-based tools. The reference to 'Stage-2 filter' and association with housing_market_screen also provides positional clarity.

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?

The description provides explicit when-to-use guidance: 'This is the Stage-2 "is the demand real?" filter on a yield shortlist' and warns against using it for current-quarter reads due to the ACS 5-year rolling average. It also tells the user to pass results from housing_market_screen, effectively routing usage. The lag warning serves as a clear when-not-to-use indicator.

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

All Housing Intel toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources