RentalHunter

Search PG / co-living

search_pg

Read-onlyIdempotent

Searches PG (paying guest), hostel and co-living beds by city and area. Use for queries mentioning PG, paying guest, hostel, co-living, sharing, a bed, or boys/girls accommodation. Rent is per bed per month. Locality is exact. Returns PGs with room types, per-bed rent, meals, gender, move-in costs and a listing link. An empty result means nothing matched.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "city": "<city>"
    },
    "name": "search_pg"
  }
}

Input Schema

Name	Required	Description
`city`	Yes	City slug
`meals`	No	PG meal slots required when meals are included.
`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.
`sharing`	No	PG sharing types (multi-select).
`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.
`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).
`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
`near_transit`	No	True only when near transit is required. Omit or false means not required, not excluded.
`rent_bracket`	No	PG rent brackets (multi-select, INR per bed).
`attached_bath`	No	True only when an attached bath is required. Omit or false means not required, not excluded.
`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.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 2, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already establish readOnly/idempotent/non-destructive, so the description's value is in what it adds: rent is per bed per month, locality matching is exact, the empty-result semantic, and the exact shape of what comes back. It does not cover result ordering, result caps or pagination, which would round out a search tool.

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?

Five short sentences, front-loaded with purpose then trigger vocabulary, then output shape, then the empty case. Every sentence carries information an agent can act on; nothing is padded.

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

Completeness4/5

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

For an 18-parameter tool with no output schema, the description does the important work of describing the return payload and the no-match semantic. Only minor gaps remain around result ordering, truncation and how currency converts rent bounds.

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 description coverage is 100% across 18 parameters, so the schema already carries parameter meaning and the baseline is 3. The description mostly restates schema facts (per-bed-per-month rent, exact locality) rather than resolving subtle ones, such as how currency interacts with the INR-denominated rent_min/rent_max bounds.

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?

"Searches PG (paying guest), hostel and co-living beds by city and area" gives a specific verb, resource and scope, and the trigger vocabulary (PG, hostel, co-living, sharing, a bed) implicitly partitions this from the search_rentals sibling. An agent can correctly route PG queries here without opening the schema.

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

Usage Guidelines4/5

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

"Use for queries mentioning PG, paying guest, hostel, co-living, sharing, a bed, or boys/girls accommodation" gives explicit triggering conditions, and "An empty result means nothing matched" sets expectations on no-match. It stops short of naming search_rentals as the alternative for non-PG housing, so the when-not side is only inferred.

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?