RealAI

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`.

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 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.