Square Yards

Convert a land/area measurement between the units used in INDIA — metric (sq metre, sq km, hectare, are, sq cm), imperial (sq feet, sq yard/"gaj", sq inch, acre) and traditional Indian land units (cent, decimal, ground, guntha, marla, kanal, killa, ankanam, bigha, biswa, kattha). Use THIS for any unit-conversion NUMBERS ("how many sq ft in a bigha", "convert 5 acre to gaj", "200 gaj in sq feet"). Pure calculator — no ids, no live data. Pass `value` (a positive number) and `from`; give `to` for a single target, or omit it to get the value in the common units at once. Units accept friendly aliases (sqft, sqm, gaj, acre, cent, ground…). IMPORTANT: bigha, biswa and kattha differ by state, so pass a state-qualified code (BIGHA_PUCCA_UP_I, BISWA_HP_I, KATTHA_BIHAR, …); a bare "bigha" or an unknown unit returns the list of valid codes. For property PRICE/EMI numbers use estimate_home_loan; for live listings use search_properties.

area_conversion

Compare 2-4 entities of the SAME type side by side (two projects, three localities, two listings), rendered as a comparison table. Pick this over calling get_entity_details repeatedly when the user asks to compare or contrast named places or properties. All items must share one `entity`, and you must already hold each numeric `id`: resolve each first via search_entities / search_properties / search_projects, never guessing. For city/locality/micromarket set `idType` to the id's source (beats default, or dotcom); it is ignored for project/listing. Cross-type comparison is not supported, and property-rates is not comparable. To RANK many localities or answer "which area is best" use recommend_localities.

compare_entities

Fetch FULL DETAIL for ONE entity by numeric id - the last drill-down step. Use ONLY when the search tools (search_properties / search_projects / search_entities) did not already answer: a project's possession/completion date, per-wing RERA, amenities or spec; a listing's full attributes; a locality's price rates & pros/cons. For how/what/why questions (loans, vastu, process) use search_faq, not this. You MUST already hold the id from a prior result - never guess an id or slug; if you only have a NAME, call the matching search tool FIRST and copy its id (pick the one whose name+city matches; else say so). Which id, by entity: listing -> a search_properties result's `id`; project -> a search_projects result's `id`, OR a search_entities `type:"project"` result's `dotcomId` (project has one id space); developer -> a search_entities `type:"builder"` result's `dotcomId`; city/locality/micromarket -> a search_entities result's `beatsId` (default) or `dotcomId` (then set idType="dotcom"). For projects the result includes `possessionStartingFrom`, the authoritative possession date (earliest upcoming RERA completion). For a PLACE's PRICE / PROPERTY RATES / market insights use entity="property-rates": resolve the place via search_entities, take its `beatsId`, then call with entity="property-rates", rateType=(city|locality|micromarket) and id=that beatsId. Optional `fields` adds sections (comma-separated); omit for the primary detail. Returns a compact, intent-filtered detail object.

get_entity_details

Calculate a home-loan EMI, or estimate how much a buyer can afford, for INDIA home loans. mode="emi": given loanAmount (or propertyPrice + down payment) + rate + tenure, returns the monthly EMI, total interest and total payable. mode="affordability": given monthly/annual NET income (+ existing EMIs, optional down-payment cash), returns the max EMI capacity, max loan and max property price via FOIR + RBI LTV tiers. Use THIS for any loan NUMBERS question ("EMI on X", "what can I afford on Y salary", "how much down payment do I need") — e.g. turn a listing/project card price into an EMI. For loan PROCESS/documents/eligibility prose use search_faq instead. Pure calculator: no ids, no live data. Money is absolute INR (1.2 Cr → 12000000). Defaults: 8.75% p.a., 20-year tenure, FOIR 0.50, stamp+registration ≈6%. Results are indicative with the disclaimer included — never present them as a loan offer.

estimate_home_loan

Rank 2-20 localities (or a city's top localities) for END-USE vs INVESTMENT, as a scored list. ROUTING: pick THIS when the user names MANY areas or asks for "the best area(s)" / a recommendation (compare_entities is only a 2-4 side-by-side TABLE and never ranks). Resolve each locality NAME to an id via search_entities (entityType="locality") FIRST, then pass `localities:[{id,idType}]` (or `cityId` to rank a city's top localities). Optional `budget` (absolute INR) flags each `inBudget`; `goal` = end_use | investment | both (default). HONEST + deterministic: it only combines signals get_entity_details already returns and NEVER invents a verdict. Sub-scores (0-100): connectivity/lifestyle/livability = the backend 0-5 index x20; appreciation = price-trend % (0%->50, +/-12.5%->100/0); liquidity (govt registered-deal volume) + value (rental yield) are ranked RELATIVE to the set. Weights - end-use: livability .35, connectivity .30, lifestyle .25, value .10; investment: appreciation .40, liquidity .30, value .20, connectivity .10; overall = their mean. A missing signal is OMITTED (not zero-filled), BUT a locality is only RANKED when present signals cover >50% of the goal's CORE (discriminating) weight — investment = appreciation/liquidity/yield (connectivity alone can't rank it), end-use = livability/connectivity/lifestyle; thinner ones go to `insufficientData` (with known signals + reason), so a one-signal locality can never top the list. signalCoverage is that CORE-weight share (0-1); each item also carries signalsUsed + raw numbers (avgRate, rentalYield, priceTrendPct, transactions) and VERBATIM pros/cons. India only, read-only.

recommend_localities

Resolve a place/builder/project NAME (city, locality, micromarket, builder, project, landmark) into the ids the other tools need; returns ranked entity SUMMARIES, never full listings/projects. For a normal search BY PLACE do NOT call this first -> call search_properties or search_projects with `location` set (they resolve the place themselves in ONE call). Use search_entities ONLY to disambiguate an ambiguous place, get a landmark's coordinates, or resolve a builder/project name to an id. When you do use it, chain in the SAME turn: resolving a place but fetching no listings/projects/detail is INCOMPLETE. Reading results: - city/locality/micromarket/builder -> carries ready-made `forProperties` (beats-space ids -> search_properties) and `forProjects` (dotcom-space ids -> search_projects) scope objects; pass the matching one's fields VERBATIM, never build or transform ids. - type:"project" -> take its `dotcomId`; drill in with get_entity_details (entity="project") or scope search_projects by it. - type:"landmark" -> take its `coordinates` as lat/long (or landmarkId "lat|lng|name") for a near-<landmark> radius search. Routing after resolving: resale/rent -> search_properties; new-construction -> search_projects; general buy -> BOTH; one entity's full detail or a place's price-rates -> get_entity_details. Always pick the ONE result whose name and city match the user's words ("Noida" -> the city Noida, not Greater Noida). (search_faq answers how/what/why and needs no id.)

search_entities

Search NEW-CONSTRUCTION projects/developments (NOT resale listings) - under-construction, new-launch, ready-to-move, upcoming - returned as project cards (developer, price band, BHK configs, status, RERA). ROUTING: pick THIS for "project/new launch/under construction"; use search_properties for resale/rental listings; for a general buy intent with no new-vs-resale preference call BOTH in the same turn. SIMPLEST PATH (one call): pass `location` as the place in the user's words ("Noida", "Wakad Pune") plus filters - it resolves the place itself, so you need NOT call search_entities first. For precise/repeat scope you may instead pass an entity's `forProjects` ids (cityId/localityId/micromarketId/builderId - DOTCOM id space) VERBATIM; explicit ids override `location`. Never reuse a search_properties BEATS id here, and never guess ids. SPECIFIC NAMED project: do NOT use this discovery list (a city-scoped search returns the wrong project) - resolve the name via search_entities (entityType="project"), take its `dotcomId`, and open it with get_entity_details (entity="project", id=that dotcomId). A geo (lat/long or landmark) search adds `distanceInKm` per card. Defaults: RESIDENTIAL projects unless buildingType=2 (commercial) or a type/q is set; default order is "Top Selling" (Square Yards promoted/featured ranking - cards carry isFocus/isAssured/hasExclusive flags; use `sort` for price/connectivity order). A card price + estimate_home_loan gives its EMI. DRILL-DOWN: every card has an `id` - for possession/completion date, per-wing RERA, amenities or full spec call get_entity_details (entity="project", id=that `id` verbatim - never the name/slug).

search_projects

Search actual SALE or RENT LISTINGS - individual resale/rental units, shown as property cards. ROUTING: listing intent ("flats/for sale/resale/to rent") -> THIS; "project/new launch/under construction" -> search_projects; a general buy with no resale-vs-new preference -> call BOTH (this with Sale + search_projects); a PLACE's price rates / per-sq-ft / market trends (not individual units) -> get_entity_details entity="property-rates" (NOT a listings search). ALWAYS set listingType (Sale|Rent). SIMPLEST (one call): pass `location` as the place in the user's words ("Gurgaon") plus filters - it auto-resolves the place, so do NOT call search_entities first. For precise scope pass an entity's `forProperties` ids (cityId/subLocalityId/microMarketId = BEATS ids) VERBATIM; explicit ids or lat/long override `location`; never guess numeric ids and never reuse a `forProjects`/dotcom id (different id space). budget = absolute INR (40 lakh -> 4000000); area in sq ft; bedrooms = BHK label ("2 BHK"). propertyTypeName takes EXACT propertyType values (Apartment, Villa, Builder Floor, Independent House, Office Space, Shop, Plot, ...) - "Studio"/"1 RK"/"Ind Floor" are bedrooms (unitType) values, NOT types. With NO propertyTypeName the search defaults to RESIDENTIAL types - set a commercial type explicitly for offices/shops (project-scoped searches exempt). A geo search (lat/long or landmark) adds `distanceInKm` per card. Results follow Square Yards ranking; promoted cards carry isFeatured/isExclusive flags (use `sort` for price/newest order). Each card carries a normalized pricePerSqft (₹/sq.ft) + areaSqft so "cheapest per sq.ft" is directly answerable; a dataQualityFlag caveats an implausible area/price. For "what EMI would this cost" pass a card price to estimate_home_loan. DRILL-DOWN: every listing has an `id` -> get_entity_details entity="listing" id=that `id`, copied verbatim (never the title or URL).

search_properties

Answer INFORMATIONAL/advisory real-estate questions -- buying/renting/selling process, home loans, legal, RERA rights, NRI purchases, Azuro-managed rentals -- from the bundled Square Yards FAQ corpus. Pick this for general how/what/why questions; needs NO id, does NOT touch listings/projects. Do NOT use it to find inventory (use search_entities -> search_properties/search_projects), for a PLACE-specific price/rates question (use get_entity_details entity="property-rates"), or for EMI/affordability NUMBERS (use estimate_home_loan, not this). Optionally pass `category` (e.g. buying/renting/selling) to scope results; `top_k` caps returned Q/A pairs (default 3).

search_faq