RentalHunter

Check hunt details and search

guided_rental_questionnaire

Read-onlyIdempotent

Reports which hunt fields are still missing. When city, stay length, and budget are present, searches inventory. Does not save an alert or collect an email.

Input Schema

Name	Required	Description
`city`	No	City slug
`suits`	No	PG suits: working professionals or students.
`gender`	No	PG gender filter.
`has_ac`	No	True only when AC is required. Omit or false means not required, not excluded.
`status`	No	Household: Single, Couple, or Family (values single, partner, or family). single matches Everyone and Singles only. partner is Couple and matches Everyone and Couples. family matches Everyone and Families only.
`sharing`	No	PG sharing types (multi-select).
`area_min`	No	Optional minimum apartment size. Pair with area_unit. Omit for any size.
`currency`	No	Budget currency for price_max. Defaults to the city's local currency. USD rates are the live cached interbank quote. Saved alerts store the USD equivalent.
`has_lift`	No	True only when a lift or elevator is required. Omit or false means not required, not excluded.
`has_pets`	No	True when the seeker has pets. Excludes homes that explicitly disallow pets. Unknown pet policy still appears as ask about pets.
`locality`	No	Exact area inside the city, such as Baner or Kharadi. A Baner search does not return Hinjewadi.
`rent_max`	No	PG max rent per bed per month (INR).
`rent_min`	No	PG min rent per bed per month (INR).
`amenities`	No	PG property amenities (all required must be present on the listing).
`area_unit`	No	Unit for area_min. Use sqft in Pune and sqm in other cities. Defaults from the city when area_min is set and this is omitted.
`furnished`	No	Set true only when the seeker explicitly asks for furnished. Omit for any furnishing.
`no_curfew`	No	True when the seeker needs no gate curfew. Omit or false means not required, not excluded.
`price_max`	No	Max monthly rent in `currency` units. Defaults to the city's local currency (Pune INR, Dubai/Sharjah AED, Bangkok/Phuket THB, Vietnam VND). Example: 30000 INR, 4000 AED.
`lock_in_max`	No	Max lock-in months the seeker will accept
`stay_nights`	No	Desired stay length in nights (7=1 week … 330=11 months, 365=12 months). 11 months is offered everywhere; it is the standard residential lease in India.
`available_by`	No	Move-in by date, YYYY-MM-DD
`bedrooms_min`	No
`near_transit`	No	True only when near transit is required. Omit or false means not required, not excluded.
`pet_friendly`	No	True only when pets are required. Omit or false means not required, not excluded.
`accommodation`	No	Legacy stay type after city. Prefer property_type. pg starts the PG filter path (no bedroom/BHK filters). whole_home is a standard apartment hunt. Omit for any category.
`attached_bath`	No	True only when an attached bath is required. Omit or false means not required, not excluded.
`property_type`	No	Apartment vs PG / co-living after city. When pg, use sharing, gender, rent_min/rent_max per bed, meals_included, attached_bath, ac, suits, amenities — not bedrooms_min.
`meals_included`	No	PG meals included in rent.
`near_coworking`	No	True only when near coworking is required. Omit or false means not required, not excluded.
`deposit_months_max`	No	Max security deposit in months of rent

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedNov 2, 2026

addedInput schema / properties / accommodation

Added value: +{
+  "description": "Legacy stay type after city. Prefer property_type. pg starts the PG filter path (no bedroom/BHK filters). whole_home is a standard apartment hunt. Omit for any category.",
+  "enum": [
+    "pg",
+    "whole_home"
+  ],
+  "type": "string"
+}

addedInput schema / properties / amenities

Added value: +{
+  "description": "PG property amenities (all required must be present on the listing).",
+  "items": {
+    "enum": [
+      "wifi",
+      "housekeeping",
+      "laundry",
+      "power_backup",
+      "parking",
+      "gym"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / gender

Added value: +{
+  "description": "PG gender filter.",
+  "enum": [
+    "boys",
+    "girls",
+    "coed"
+  ],
+  "type": "string"
+}

addedInput schema / properties / meals_included

Added value: +{
+  "description": "PG meals included in rent.",
+  "type": "boolean"
+}

addedInput schema / properties / property_type

Added value: +{
+  "description": "Apartment vs PG / co-living after city. When pg, use sharing, gender, rent_min/rent_max per bed, meals_included, attached_bath, ac, suits, amenities — not bedrooms_min.",
+  "enum": [
+    "apartment",
+    "pg"
+  ],
+  "type": "string"
+}

addedInput schema / properties / rent_max

Added value: +{
+  "description": "PG max rent per bed per month (INR).",
+  "maximum": 500000,
+  "minimum": 0,
+  "type": "number"
+}

addedInput schema / properties / rent_min

Added value: +{
+  "description": "PG min rent per bed per month (INR).",
+  "maximum": 500000,
+  "minimum": 0,
+  "type": "number"
+}

addedInput schema / properties / sharing

Added value: +{
+  "description": "PG sharing types (multi-select).",
+  "items": {
+    "enum": [
+      "private",
+      "twin",
+      "triple",
+      "4plus"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / suits

Added value: +{
+  "description": "PG suits: working professionals or students.",
+  "enum": [
+    "professional",
+    "student"
+  ],
+  "type": "string"
+}

First observedOct 18, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered; the description adds real behavioral detail beyond that: the prerequisite gate (city + stay length + budget) and the explicit non-effects (no alert saved, no email collected). It stops short of saying what the results payload looks like or whether results are capped.

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?

Three short sentences, gate condition front-loaded after the primary behavior, negative scoping last. No waste, though "hunt" and "stay length" assume vocabulary the agent must map to stay_nights and the alert/hunt model.

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 no-required-parameter, 30-field tool with no output schema, the description covers the gate and the exclusions but not the return shape (a missing-fields report vs. inventory results), nor how partial input is handled. Adequate to call correctly, thin for interpreting what comes back.

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 coverage is 97%, so the schema already documents nearly all 30 parameters, and the baseline of 3 applies. The description contributes one genuinely new fact the schema lacks: that city, stay length and budget form the gating trio even though no parameter is marked required. It adds nothing about the remaining PG/apartment filter branches.

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?

States two concrete behaviors: reporting which hunt fields are missing, and searching inventory once city, stay length and budget are present. The narrow negative clause ("does not save an alert or collect an email") distinguishes it from save_hunt_alert, though it never names that sibling. Purpose is clear without being crisp about the questionnaire-gating role implied by the name.

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

Usage Guidelines3/5

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

Implies the invocation order (call this while the hunt is incomplete, and it will search once the gate is satisfied) and rules out alert-saving. It does not contrast with search_rentals or search_pg, which are the obvious alternatives once the fields are complete, so the agent must infer which tool to call after the gate passes.

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

All RentalHunter tools Inspect

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

Need Help?