Real-time Israeli rental listings, pricing estimates, and neighborhood intelligence across Tel Aviv and central Israel. Search 5+ deduped sources with hourly liveness, view specs, estimate fair-market rent, and explore local transit and area context directly inside your agent.
Scored across 6 tools
Most tools target distinct actions (search listings, get one listing, estimate a price, resolve place names), and descriptions explicitly cross-reference each other. However, 'coverage' and 'neighborhood_context' overlap heavily, since both can return a city's neighborhood registry, which could cause misselection when an agent just wants place naming.
Four tools follow a predictable verb_noun-ish pattern (estimate_price, find_neighborhoods_near, get_listing, search_listings). The two noun-only names (coverage, neighborhood_context) deviate from that pattern but are still clear and readable, so consistency is mostly maintained.
Six tools is well-scoped for a real-estate listing service, with each tool covering a clearly bounded capability (search, detail, price estimate, geography, context, naming). No redundant or filler tools appear in the set.
For a read-oriented listing server the surface covers discovery, filters, single-listing detail, pricing, and neighborhood/geography context, which is solid coverage. Minor gaps exist, such as price-trend/history queries across an area or any save/compare workflow, but core agent workflows are supported.
Which Israeli cities, regional groups and localities Dorit searches, with rent/sale availability and neighborhood counts; with a city, that city's neighborhood registry (ids, slugs, names in Hebrew, English and Russian, centroids) and its named areas. Call this first when unsure how a place is named.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | A city by name or slug: returns its full neighborhood registry and its named areas. Omit for the list of cities, regional groups and localities. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds useful domain scope (Israeli places only) and the fact this is the authoritative naming registry, but no rate limits, auth needs, or caveats about data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight clauses separated by a semicolon, with the no-argument behavior stated first and the city-argument behavior second. Slightly dense noun stacking, but every phrase carries information and nothing is padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must convey return values, and it does enumerate them for both branches (coverage list with rent/sale availability and counts; neighborhood registry with ids, slugs, multilingual names, centroids). It is nearly sufficient, though the exact response shape and field names remain unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single city parameter, and the schema already explains the name-or-slug form and the omit-for-list behavior. The description restates the same registry contents (ids, slugs, multilingual names, centroids) without adding new semantics, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource: Dorit's coverage of Israeli cities, regional groups and localities, plus the neighborhood registry returned when a city is supplied. An agent can tell this is a place/name lookup. It does not, however, differentiate itself from the sibling neighborhood_context, which plausibly overlaps with the city-level neighborhood data described here.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Call this first when unsure how a place is named" gives an explicit trigger condition for invoking the tool, and the schema clarifies the omit-vs-provide branch. No sibling alternative is named for the case where the agent already knows the naming, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Grounded rent or sale price estimate from Dorit's listing corpus: a headline figure with a low–high band, sample size and window, for a neighborhood or street subject (location + rooms) or for one listing (listing_id, which also says whether its asking price is above or below market). A refusal (insufficient_data, unsupported_market, unknown_location, needs_clarification) means there is no honest number — never replace it with a guess.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City, when the location alone is ambiguous. | |
| floor | No | ||
| rooms | No | Required with location. | |
| location | No | A neighborhood, a street, or "street, city" — as the user named it. | |
| amenities | No | Only amenities the user stated; an omitted one neither raises nor lowers the estimate. | |
| condition | No | ||
| listing_id | No | Price a specific Dorit listing against its market. When set, send no other field. | |
| property_type | No | Sale only: apartment, unit, garden, house, twofamily, penthouse, duplex. | |
| square_meters | No | ||
| transaction_type | No | Defaults to rent. Sale estimates run in fewer cities and also return registered sold deals for a street subject. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, closed-world behavior, so the safety profile is covered. The description adds genuine behavioral context beyond that: the enumerated refusal reasons (insufficient_data, unsupported_market, unknown_location, needs_clarification) and the instruction never to substitute a guess, plus the shape of a successful return.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core output promise, then the input modes, then the refusal contract; every sentence carries information. The long parenthetical on listing_id slightly blurs the structure but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly supplies the return shape (figure, band, sample size, window, above/below-market comparison) and the failure modes. It leaves some ambiguity about which of the 10 optional parameters combine legitimately outside the two stated modes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 70%, and the schema itself documents the key constraints (rooms required with location, listing_id exclusive, transaction_type default). The description reinforces the mode selection between location+rooms and listing_id but adds little per-parameter syntax or format detail beyond what the schema already carries.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (grounded rent or sale price estimate) and defines the two distinct subject modes: a location+rooms query and a single-listing query. An agent can tell exactly what this produces (headline figure, low–high band, sample size, window) versus what siblings like search_listings return.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly routes between the two invocation modes (location+rooms vs listing_id, which must be sent alone) and explains what each mode yields. It also specifies that refusals are authoritative, but never names a sibling tool or states when to prefer search_listings or get_listing instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The neighborhood containing a place and those within walking distance of it: a station or rail line, a landmark, a campus, a mall, a street or an address, or another neighborhood. Returns neighborhood ids you can pass to search_listings. Stations that are planned or under construction are marked.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City by name or slug, when known. Narrows an ambiguous place. | |
| place | Yes | A train or light-rail station or line, a landmark, a campus, a mall, a street or street address, or another neighborhood — in Hebrew when the user wrote Hebrew. | |
| radius_meters | No | Walking radius; defaults to 800. | |
| transaction_type | No | sale keeps bordering neighborhoods inside the cities where sale search is open. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered structurally. The description adds genuinely new behavioral detail beyond that: the return payload is neighborhood ids, and stations that are planned or under construction are flagged in the output. It does not cover pagination or result-count behavior, keeping it below 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three front-loaded sentences with no filler; the scope definition leads and the return contract follows. Minor redundancy: the enumerated place types duplicate what the 'place' schema field already says, costing a little density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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-value burden and does so by naming neighborhood ids and the planned-station marking. For a 4-parameter read-only lookup whose schema is fully documented, that is nearly complete; only result limits or error behavior remain unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents every parameter including the 800m default and the transaction_type semantics. The description's place-type list largely restates the schema's own 'place' description rather than adding syntax or format guidance, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a precise verb+resource+scope: the neighborhood containing a place plus those within walking distance. It also enumerates the accepted place kinds, so an agent knows exactly what input domain is covered. It does not, however, differentiate itself from the sibling neighborhood_context, which is the most likely confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It supplies clear context for use — 'Returns neighborhood ids you can pass to search_listings' establishes the workflow position and downstream consumer. It stops short of stating when NOT to use it (e.g., versus neighborhood_context) or any prerequisites, so no explicit alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full details of one live Dorit listing: photos, recorded features, move-in timing, posting and re-offer timestamps, price history, and the last liveness check. A listing that was taken down or aged out of search returns only its status (taken_down or expired). Contact details and the source ad link are not exposed; the url opens the listing page on dorit.bot.
| Name | Required | Description | Default |
|---|---|---|---|
| listing_id | Yes | Dorit listing id, as returned by search_listings or found in a dorit.bot/apartment/<id> link. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-open-world behavior, so the bar is lower, yet the description still adds real context: taken-down or aged-out listings return only a status (taken_down/expired), and contact details plus the source ad link are deliberately withheld while the url opens the dorit.bot page. It does not cover auth requirements, rate limits, or behavior for an id that never existed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, zero filler. The core payload (what the listing returns) is front-loaded, followed immediately by the degenerate-status case and the excluded fields. Every clause carries information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly carries the return-value burden and does so well: it enumerates the returned fields and the reduced taken_down/expired shape. The only unaddressed case is an id that doesn't exist at all (error vs. empty response), which slightly limits completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single listing_id parameter, so the schema already documents its meaning, positive-only constraint, and the dorit.bot/apartment/<id> lookup form. The description adds nothing further about the parameter, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource and scope: 'Full details of one live Dorit listing,' then enumerates exactly what is returned (photos, features, move-in timing, timestamps, price history, liveness check). This clearly distinguishes it from the list-style sibling search_listings, which returns multiple listings rather than one listing's full record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: the reader infers you call this after search_listings has produced an id, and the schema description confirms that provenance. However, the description never explicitly says 'use this to drill into a single listing' or names search_listings as the entry point, and gives no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What a neighborhood is like: Dorit's editorial description, typical asking rents by room count, live listing count, rail and light-rail stations nearby, and bordering neighborhoods — plus a dorit.bot browse link. Without a neighborhood, returns the city's description and its neighborhood registry. Use estimate_price for a priced subject.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City by name or slug. | |
| language | No | Language of the description; defaults to the connected user's language. | |
| neighborhood | No | Neighborhood by name or slug. Omit for the city itself: its description and neighborhood list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint, idempotentHint, openWorldHint=false), so the remaining burden is small. The description still adds real value by disclosing the dual-mode behavior (neighborhood present vs. omitted) and the presence of an external browse link, which the annotations do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the payload contents, then the fallback mode, then the sibling pointer — a sensible order with no filler. The opening list of return fields is long, but each item is informative rather than padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description has to carry the return-shape burden, and it does so thoroughly for both modes. Combined with annotations covering the safety profile, an agent has everything needed to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — city, language, and the neighborhood omit-semantics are all documented in the schema. The description restates the neighborhood-omission behavior but adds no syntax, format, or constraint detail beyond it, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description enumerates exactly what the tool returns — editorial description, rents by room count, live listing count, rail stations, bordering neighborhoods, and a browse link — and states the fallback mode when no neighborhood is given. It also names a sibling it is not (estimate_price), so an agent can differentiate it without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly routes priced questions to estimate_price and explains the omit-the-neighborhood mode for city-level data, which is genuine when-to-use guidance. It stops short of clarifying how it relates to the other close siblings (find_neighborhoods_near, search_listings), so it isn't fully exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Dorit's live apartment listings (rent or sale) in Israeli cities, localities and regional groups, narrowed to neighborhoods or named areas, with structured filters: price, rooms, size, floor, move-in month, property type, roommates and features. Returns compact listings with dorit.bot links, newest first by default, and what the place names resolved to. Use get_listing for one listing's full details and photos.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| sort | No | newest | |
| cities | No | Cities, localities or regional groups by name in Hebrew, English or Russian, or by slug ("תל אביב", "Tel Aviv", "tel-aviv", "עמק חפר"). A group covers every settlement in it. Omit when neighborhoods or search_area already say where. | |
| max_sqm | No | ||
| min_sqm | No | ||
| features | No | true requires the feature; false excludes it; omitted does not filter. elevator=true means an elevator or a low floor (see max_floor_without_elevator). | |
| max_floor | No | ||
| max_price | No | ||
| max_rooms | No | ||
| min_floor | No | ||
| min_price | No | ||
| min_rooms | No | Israeli room count (whole or half rooms; a living room counts). | |
| page_size | No | Defaults to the plan's page size (10 on trial, 25 on premium). | |
| roommates | No | exclusive = only rooms in shared flats; excluded (default) = whole apartments only. | |
| handover_by | No | Sale only: latest handover month, YYYY-MM. | |
| neighborhoods | No | Neighborhoods, named areas of a city ("הצפון הישן", "מערב ראשון לציון"), landmarks or housing projects, by name, slug or the ids coverage and find_neighborhoods_near return. A neighborhood inside a listed city narrows that city to it; one in another city is added to the search. | |
| property_types | No | Asset types: apartment, unit, garden, house, twofamily, penthouse, duplex. Omit for all. | |
| entrance_months | No | Rent only: acceptable move-in months, YYYY-MM. A listing naming no month is treated as available now or within the month. | |
| transaction_type | No | rent (monthly ILS) or sale (total ILS). Sale is open in fewer cities. | rent |
| exclude_neighborhoods | No | ||
| max_floor_without_elevator | No | Highest acceptable floor when the building has no elevator; above it an elevator is required. Same as features.elevator=true with this walk-up limit. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/openWorldHint=false, so safety is covered. The description adds genuinely useful behavior beyond them: results are compact listings with dorit.bot links, sorted newest first by default, and the response reports what place names resolved to — the last point is important because it warns the agent that name resolution may not match intent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose and scope, followed by a return-value note and a sibling routing tip. Dense but every clause carries actionable information for a 21-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 21-parameter tool with nested feature objects and no output schema, the description covers scope, filter families, default sort, and result shape adequately. It omits pagination/plan page-size behavior and the rent-vs-sale default and city-coverage caveat that live only in the schema, which keeps it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 52%, so the description carries extra weight. It enumerates the filter dimensions (price, rooms, size, floor, move-in month, property type, roommates, features) and thereby names roughly every under-documented numeric/enum parameter group that the schema leaves bare, such as min/max price and sqm. It still doesn't explain units or rent-vs-sale value semantics, so not a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (search live apartment listings for rent or sale) and scopes it to Israeli cities, localities and regional groups. It also names the sibling relationship explicitly, pointing to get_listing for single-listing detail, so an agent can separate it from get_listing and find_neighborhoods_near without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes single-listing lookups to get_listing, and the filter enumeration plus 'narrowed to neighborhoods or named areas' tells the agent when this broad search is the right entry point. It lacks an explicit 'don't use this when...' exclusion or guidance on combining with estimate_price/neighborhood_context, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
