RealAI

By RealAI Systems, LLC

Get New App Alerts

Open in ChatGPT

Open in Claude

Overview

The RealAI Connector provides Claude access to RealAI’s authoritative real estate data catalog, spanning 126 million US properties (including 230,000 multifamily communities with unit-level operating detail), aggregated data on the 250 million people who live in them, their rent and leasing activity, and market/geographic data from the metro down to the census-block level. RealAI doesn't just describe properties and places — it scores and ranks them. Every area and building carries normalized national and local benchmarks across hundreds of attributes, so RealAI can rank an entire population — markets, neighborhoods, or buildings — against any combination of criteria a user cares about, rather than profiling one place at a time off a fixed template. Two examples of data depth most tools can't match: migration data that captures not just population flows but the age, income, wealth, and education profile of who is moving in versus out of a market; and unit-level rent-roll history built from nightly listings nationwide — asking vs. in-place rents, occupancy, days on market, rent growth, turnover, and tradeouts.

Tools

entity_search_by_name

ChatGPT

Search for real estate geographies and multifamily properties by name using fuzzy matching. Handles misspellings and partial names — use 1–2 words for best results. Covers markets (MSAs), counties, submarkets, neighborhoods, census places, zip codes, states, and multifamily properties. Single-family homes are not indexed here — resolve the geographic context (market / county / zipcode / state) with this tool, then query_data on property with that geo id filter + address CONTAINS_IGNORE_CASE, then query_data on property_residential filtered by the returned id. score is jaro_winkler_similarity between the query and the entity name — string similarity, not semantic correctness. A high score can still be the wrong entity (e.g. same name in the wrong state); ask the user to disambiguate when type or location does not clearly match the intent. Pass attributes.source_type (lowercase) to downstream tools, not entityType.

explore_data

ChatGPT

Discover what data is available before calling query_data. Call in sequence: scope "entities": list available entity types and their foreign keys. scope "topics": get the exact topic name strings and each topic's required_filters[] for a specific entity. Required before using query_data — topic names are opaque and cannot be guessed. scope "fields": get queryable field names for specific topics. Only needed when you plan to project specific fields in query_data — prefer querying by topic without projection. Pass the topics filter to keep the response small. A single query_data call can query multiple topics for the same entity; prefer combining topics over issuing separate calls.

query_data

ChatGPT

Query structured data from the data catalog. Topic names must come from explore_data scope "topics" — they are opaque identifiers that cannot be inferred from natural language. Prefer querying by topic without a field projection — it is simpler, more resilient, and returns a good baseline set of fields for analysis. Only project specific fields when you need a large number of rows (e.g. all properties in a market) and want to keep the response narrow. If you do project specific fields, you MUST first call explore_data with scope "fields" for that topic. Do not guess field names, and do not infer them from topic descriptions. Filters and sort use dot-notation field paths: "topic.field" for topic fields, bare names for identity fields. Check required_filters[] on each topic from the explore_data "topics" response and include them, or the call will return a 400. Values in required_filters[].values are case-sensitive and differ per topic. Field names in required_filters[] are already dot-notated — copy them into your filters as-is. Field names returned by explore_data scope="fields" are bare — you must dot-notate them yourself before using them as filter or sort fields (see the rule above). Combine multiple topics for the same entity into one call rather than issuing separate calls. Topics with separate_data_source:true must be queried alone (one per call). Filters must be specific enough to match a small number of rows — whether a CONTAINS_IGNORE_CASE value that is too short or partial, or an identity field that covers a large set (e.g. a city or region). Queries matching thousands of rows will time out. For large entities like property (126M+ rows), always combine a geographic identity filter (zipcode_id, centum_id, neighborhood_id, census_place_id, submarket_id, county_id, market_id, or state_id) with any other filter to avoid timeouts.