Skip to main content
Glama

Ads near a point

dv_nearby
Read-onlyIdempotent

Find Divar ads near a GPS point by category, radius, price, and filters; results are sorted nearest first with coordinates, distances, price chips, and thumbnails.

Instructions

Ads on the map around a GPS point, nearest first, with coordinates, distance, price chips and a thumbnail.

Up to 200 ads per area are available (total_in_area is the true count). Pin positions are fuzzed by about 500 m for most categories (approximate_location), so distances are approximate. A category is required (Divar's map returns nothing without one). Map prices are rounded in the site's display (1.5 billion = 1,500,000,000); sale pins give the total price and, for homes, price_per_m2. Next: dv_post for details.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
latYesLatitude, e.g. 35.7. Get one from dv_place_search or dv_districts.
lonYesLongitude, e.g. 51.4.
limitNoMax ads in the answer.
queryNoFree text in title or description, e.g. 'پراید 111'.
filtersNoOther category filters (keys from dv_filters): {'size': {'min': 80, 'max': 120}, 'rooms': ['دو'], 'parking': true}. Unknown keys are returned in `ignored`.
categoryYesRequired: the map shows nothing without a category. Slug or Persian name, e.g. 'apartment-sell', 'apartment-rent', 'light'. List them with dv_categories.
radius_mNoSearch radius in metres.
max_priceNoToman; monthly rent in rent categories.
min_priceNoToman; monthly rent in rent categories.
brand_modelNoVehicles, phones: brand/model, e.g. ['پژو 206'].
max_depositNoRent categories: deposit (ودیعه) in Toman.
min_depositNoRent categories: deposit (ودیعه) in Toman.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations: a 200-ad cap per area with total_in_area as the true count, ~500 m pin fuzzing (approximate_location) making distances approximate, and rounded map prices. These are exactly the caveats an agent needs and are consistent with readOnly/idempotent hints.

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?

Front-loads the purpose and return shape, then the constraints/caveats, then the next step. Dense but every sentence (fuzzing, cap, category requirement, price rounding) earns its place; no filler.

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

Completeness5/5

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

With no output schema, the description carries the return contract (coordinates, distance, price chips, thumbnail, total_in_area) and the key limitations (cap, fuzz, approximate distances). A mutation-free 12-param tool is fully covered for correct invocation.

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%, so parameters are already well documented (lat/lon sourced from dv_place_search/dv_districts, filters keys from dv_filters, price units). The description reinforces the required-category rule and price rounding but adds little parameter syntax beyond the schema — baseline 3.

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?

States a specific verb+resource+scope: ads on the map around a GPS point, returned nearest-first, with the exact payload fields (coordinates, distance, price chips, thumbnail). The map/geographic framing and the 'Next: dv_post for details' routing make it distinguishable from the many search siblings.

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?

Gives clear context for use (geographic point search) and a hard precondition ('a category is required'), plus a next-step pointer to dv_post. It stops short of explicitly naming an alternative like dv_search for non-map queries, so it is contextual rather than fully routing.

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