AI-powered MCP server for analyzing pinuy-binuy (urban renewal) real estate projects in Israel. Provides tools to evaluate building demolition/reconstruction projects, tenant rights, compensation calculations, and project feasibility.
Scored across 13 tools
Several tools return compound/statutory data with overlapping scope: compound_full, get_compound_details, urban_renewal_registry, vatmal_compounds, and search_compounds all surface compound information, and planning_by_parcel vs planning_status_by_plan both return plan detail. The detailed 'use when' descriptions mitigate this somewhat, but an agent could still misselect between registry-backed vs merged vs drill-down views.
Mixed conventions coexist: verb-first tools (get_compound_details, get_methodology, list_recent_statutory_changes, list_top_mispriced_compounds, search_compounds) alongside bare noun_noun names (asset_result, compound_full, lead_score, urban_renewal_registry, vatmal_compounds). Everything is snake_case and readable, but the verb pattern is not applied predictably across the set.
13 tools is well-scoped for a multi-faceted analytics server spanning analysis, planning, registry, lead scoring, and opportunity ranking. Each tool maps to a distinct capability and none feel redundant filler.
Coverage is broad for the pinui-binui/urban-renewal domain: full analysis + async retrieval, compound drill-down, registry, VATMAL, parcel/plan planning, lead scoring, methodology, and change/mispricing feeds. Minor gaps include no explicit bulk list-all-compounds operation, though search_compounds largely covers it.
Full Asset Analyzer check of one or more buildings (or a compound) in an Israeli city, running every tool per building: gush/helka from a building-level address match (never guessed), the iplan plans covering the parcel point (renewal plans first), whether the parcel is inside a declared renewal compound (ות"מל, רשויות/מיסוי), MAVAT building rights and plan documents, the municipal building file, the compound registry, web research (Perplexity: nearby projects, developers, city policy, market; unverified, official data wins), then a data-grounded feasibility synthesis with feasibility, profit, location and priority scores and a 100-point deal score over seven criteria with its grade (scoring.deal_total, scoring.criteria). Returns structured data, one text line per finding, and a per-tool ok/error status. A check takes 1 to 4 minutes: past wait_seconds it returns {pending, run_id}; then call asset_result. Limited per day.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | Hebrew city name, e.g. "לוד". | |
| gush | No | Block (גוש), optional. | |
| name | No | Compound name, optional. | |
| plan | No | Plan number, optional. | |
| helka | No | Parcel (חלקה), optional, with gush. | |
| floors | No | Existing floors, when known (used when one address is given; otherwise looked up per building). | |
| context | No | Optional facts for the synthesis, e.g. "4 בניינים, 16 דירות כל אחד, 4 קומות". | |
| addresses | No | Building addresses with house numbers, e.g. ["ערבה 2","ערבה 4"]. When a building's gush/helka is verified, give it as {"address":"ערבה 4","gush":4012,"helka":83}: that parcel is used for the building instead of the address lookup. | |
| apartments | No | Existing apartments, when known (used when one address is given; otherwise looked up per building). | |
| neighborhood | No | Neighbourhood, optional (e.g. "בן גוריון"). The web research is held to "שכונת X, <city>"; without it the neighbourhood the deal records give the parcel is used. | |
| wait_seconds | No | How long to wait for the result before returning {pending, run_id} (default 50, max 290). The check keeps running either way; collect it with asset_result. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden and does so well: it discloses runtime (1-4 minutes), the wait_seconds/pending/run_id contract, that the run continues regardless, a daily cap, that gush/helka is never guessed, and that web research is unverified with official data taking precedence. It also states the return shape.
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 purpose, then the pipeline, then the async and return contract. Dense and mostly waste-free, though the long enumeration of sub-tools makes it heavier than ideal for a single paragraph.
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 properly explains returns (structured data, one text line per finding, per-tool ok/error, scoring.deal_total and scoring.criteria) and the asynchronous pending/run_id flow. For an 11-parameter orchestrator with a daily cap, this covers what an agent needs to invoke and collect it 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% across 11 parameters, so the schema already documents each field including the addresses union and wait_seconds semantics. The description adds little parameter-specific meaning beyond the schema; baseline 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?
The description states a specific verb and resource ('Full Asset Analyzer check of one or more buildings... in an Israeli city') and enumerates the sub-analyses it performs (gush/helka, iplan plans, renewal compound, MAVAT, municipal file, web research, feasibility synthesis). It distinguishes itself from siblings by being the composite orchestrator, and explicitly names asset_result as the follow-up collector.
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?
Gives clear context for use: a full multi-building/compound check, with the async collection path via asset_result spelled out and the rate limit noted. It does not, however, state when NOT to use it in favour of narrower siblings like planning_by_parcel or compound_full, so the alternative-routing guidance is incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Collect the result of an asset_analyze check that returned {pending: true, run_id} because it ran longer than wait_seconds. Returns the full result when done, or {pending: true} while the check is still running (call again in about a minute). Does not count against the daily limit.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | The run_id asset_analyze returned, e.g. "31.a1b2c3d4e5f6". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the two possible return shapes (full result vs {pending: true}), the polling cadence, and the quota exemption ('does not count against the daily limit'). It does not cover error cases or run_id expiry, keeping it short of a 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?
Two sentences, front-loaded with what it does and why it exists, then the return contract. Every clause carries information; 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 and no annotations, the description correctly covers the return contract and the polling loop, which is what an agent needs to call it correctly. Missing only edge-case behavior such as failure results or run_id lifetime.
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?
Only one parameter and schema description coverage is 100%, so the schema already documents run_id (including its format and origin). The description adds no format or constraint detail beyond the schema, which matches the baseline 3.
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 ('Collect the result of an asset_analyze check') and pins its role in the async workflow, making it clearly distinct from the sibling asset_analyze that produces the work. An agent can tell what this does 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the trigger condition (asset_analyze returned {pending: true, run_id} because it exceeded wait_seconds) and the retry behavior ('call again in about a minute'). It does not name a sibling alternative to avoid, but the conditional context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unified full picture for one Israeli urban-renewal compound: merges the authoritative urban_renewal registry status (Card A), live iplan Xplan statutory detail (Card B: deposit/approval dates + local/district committee), any VATMAL (ות"מל) compounds in the same city, and - when a gush+helka is given - the parcel-level plans (Card E), and - when addresses are given - the renewal plan covering each building (Card F). A name that matches no declared compound returns registry=null (registry_match='none'). Identify by mispar (compound number), plan number, city, name, or gush+helka.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Hebrew city name. | |
| gush | No | Block number (גוש) for parcel-level plans. | |
| name | No | Compound name (partial match ok). | |
| plan | No | Plan number, e.g. "506-1047059". | |
| helka | No | Parcel number (חלקה), with gush. | |
| mispar | No | Compound number (MisparMitham). | |
| addresses | No | Building addresses in the city (e.g. ["ערבה 2","ערבה 4"]). Each is geocoded and checked against the iplan plan covering it (Card F). Needs city. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose a key failure mode: an unmatched name returns registry=null with registry_match='none'. It also explains the input-conditional output composition. It omits the read-only safety profile, any external-API/latency behavior, and whether results are cached.
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 purpose before enumerating the merged cards. Dense but each clause earns its place; the middle sentence is somewhat run-on with a nested parenthetical but stays readable and information-rich.
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 does describe the returned composition (Cards A/B/E/F plus city-level VATMAL) and the null/registry_match edge case. For a 7-parameter, zero-required aggregation tool it is largely complete, though it could clarify how partial/absent inputs degrade the response.
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%, so baseline is 3, but the description adds real meaning: it maps the combined gush+helka to Card E parcel plans and the addresses array to Card F building plans, and clarifies these are the compound/city/plan identifiers. This goes beyond the schema's per-field descriptions.
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 ('unified full picture for one Israeli urban-renewal compound') and enumerates exactly which data sources it merges (registry Card A, iplan Xplan Card B, VATMAL, parcel cards E, building cards F). This aggregation framing clearly distinguishes it from single-source siblings like urban_renewal_registry, planning_by_parcel, and vatmal_compounds.
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?
Gives clear context on how to invoke it by listing five identity routes (mispar, plan, city, name, gush+helka) and states the conditional data each route unlocks (gush+helka -> Card E, addresses -> Card F). It does not name an alternative tool or state when to prefer a lighter sibling, so no explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return full per-field details for one pinui-binui compound by slug or numeric id. Use when user wants to drill into a specific compound (e.g. "tell me more about קהילת קליבלנד").
| Name | Required | Description | Default |
|---|---|---|---|
| slug_or_id | Yes | Compound slug (preferred) or numeric id as string. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It indicates a read operation and scope ('full per-field details'), but lacks specifics on authentication, rate limits, or response structure.
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 concise, front-loaded sentences with no wasted words.
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 simple retrieval tool with one parameter, the description covers invocation and purpose. Could optionally mention that details are 'per-field', but overall complete given lack of output schema.
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% with a clear parameter description. The description adds usage context ('by slug or numeric id') and an example, but does not significantly enhance meaning beyond the schema.
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 clearly states the action ('Return full per-field details') and the resource ('one pinui-binui compound'), distinguishing it from sibling tools like search_compounds or list_top_mispriced_compounds.
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 states when to use ('when user wants to drill into a specific compound') with an example, but does not provide exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the QUANTUM scoring methodology, statutory weights, citation patterns, refusal list, and live data endpoint URLs. Use first when an AI agent or user is unfamiliar with QUANTUM or needs to cite QUANTUM properly.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description fully discloses the tool's behavior: it returns methodology, weights, patterns, refusal list, and URLs. With zero parameters and a read-only nature (implied by 'Return'), the description covers all relevant behavioral traits without contradiction.
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?
The description is two sentences long, front-loads the key purpose in the first sentence, and contains zero filler. Every word contributes to understanding the tool's function and recommended usage.
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 parameterless tool with no output schema, the description thoroughly enumerates the returned data (methodology, weights, citations, refusal list, endpoints). It also provides usage context ('Use first when...'), making it self-sufficient for an agent to decide when to invoke it.
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?
There are no parameters, so schema coverage is 100% by default. The description adds meaningful context by listing the specific data categories returned (e.g., 'statutory weights', 'citation patterns'), which compensates for the lack of parameters and justifies a baseline-adjusted score of 4.
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 explicitly states it returns 'QUANTUM scoring methodology, statutory weights, citation patterns, refusal list, and live data endpoint URLs.' This specific verb+resource combination clearly distinguishes it from sibling tools like 'get_compound_details' or 'search_compounds', which serve different purposes.
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?
The description provides direct guidance: 'Use first when an AI agent or user is unfamiliar with QUANTUM or needs to cite QUANTUM properly.' It implicitly excludes use cases where the user already knows the methodology or needs compound-level data, though it doesn't explicitly list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score a website lead (the Minhelet lead form): the lead-quality score 0 to 10 from the form fields, combined with the Asset Analyzer feasibility of its building (final = round(0.4 x quality + 0.6 x feasibility), capped at 3 for NO-GO and 7 for GO-WITH-CAUTION) and its tier (חם, חמים, קר, חלקי, זבל). With analyze: true it starts the asset check of the lead's building and adjacent buildings (counts against the asset_analyze daily limit; junk leads are not checked); past wait_seconds it returns {pending, run_id}, then call lead_score again with the same lead and that run_id. Without either, it scores lead quality alone.
| Name | Required | Description | Default |
|---|---|---|---|
| lead | Yes | The lead form body as the website posts it (first_name, last_name, email, phone, city, street, building_number, building_units, building_floors, project_status, has_active_project, has_active_representation, adjacent_buildings_addresses, resident_consensus, known_opponents, has_signed_poa, message, ...). | |
| run_id | No | The run_id an earlier lead_score or asset_analyze returned: combine with that check. | |
| analyze | No | Start the asset check of the lead's building(s). | |
| wait_seconds | No | With analyze: how long to wait before returning {pending, run_id} (default 50, max 290). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full load and discloses rich behavior: the scoring formula, caps for NO-GO and GO-WITH-CAUTION, daily-limit consumption for asset checks, that junk leads are skipped, the pending return shape, and the exact retry pattern with run_id. These are exactly the side effects and constraints an agent needs.
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?
The description is front-loaded with the core purpose and packs necessary detail without filler. It would benefit from lighter paragraph structure or bullets, but every clause earns its place given the tool's complexity.
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 tool of this complexity with a 100%-covered schema and no output schema, the description is thorough on behavior but never describes the final success return shape (fields included by the score result). The pending return is covered, but the normal output remains unspecified, leaving a meaningful gap for an agent to interpret results.
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%, so the schema already documents each parameter. The description adds substantial meaning beyond that: it explains how analyze and wait_seconds interact, reveals the default and max wait, and describes the run_id retry contract, which the schema does not fully convey.
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 opens with a precise verb and resource: 'Score a website lead (the Minhelet lead form)'. It immediately distinguishes the tool from siblings by naming the Asset Analyzer and describing the combined scoring logic, so an agent knows this is the only tool that produces a lead-quality plus feasibility score.
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 clearly explains the effect of each mode: 'With analyze: true it starts the asset check...', 'Without either, it scores lead quality alone', and the retry flow when pending. However, it does not explicitly state when to choose lead_score over directly calling asset_analyze or asset_result, leaving that relative routing unstated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return pinui-binui compounds that transitioned to a new statutory stage (declared, deposited, approved, permit, construction) within the last N days. Use when user asks "what changed recently" or "any new pinui-binui approvals".
| Name | Required | Description | Default |
|---|---|---|---|
| days | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. Discloses tool is read-only (returns data), specifies time window and stages. No contradictions. Lacks output format details but sufficient for expected behavior.
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: first states action and scope, second gives example queries. No unnecessary words. Front-loaded with core purpose.
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?
Given one parameter, no output schema, and no annotations, description is mostly complete. Covers what, when, and example use. Lacks output format or ordering details, but acceptable for a list utility.
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?
Only parameter 'days' explained as 'within the last N days' in description, adding meaning beyond schema. Schema coverage is 0%, so description compensates adequately.
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?
Description explicitly states it returns compounds transitioning to new statutory stages within N days. Uses specific verb 'Return' and lists stages. Distinguishes from siblings by focusing on recent changes.
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 says 'Use when user asks what changed recently or any new approvals.' Provides clear context without explicitly listing alternatives, but siblings imply different uses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the current top Israeli pinui-binui compounds ranked by QUANTUM Mispricing Score = premium_gap * count(active_listings) * statutory_certainty. Use when the user asks for "top pinui-binui opportunities", "most undervalued pinui-binui compounds", "Israeli urban renewal arbitrage", or any variant. Results are regenerated hourly from the QUANTUM analyzer database.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum compounds to return. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses hourly regeneration and formula, which is sufficient for a read-only tool.
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 that efficiently cover purpose, usage, and transparency with no redundant information.
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 simple tool with one parameter and no output schema, the description adequately covers purpose, usage, and update frequency.
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 baseline is 3. The description adds no extra meaning beyond the schema's parameter description for 'limit'.
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 explicitly states the tool returns 'top Israeli pinui-binui compounds ranked by QUANTUM Mispricing Score' using a specific formula, distinguishing it from siblings like get_compound_details or search_compounds.
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?
The description provides explicit usage scenarios ('top pinui-binui opportunities', 'most undervalued pinui-binui compounds', etc.), though it does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parcel-level statutory planning for a specific building/parcel. Resolves a gush + helka (block + parcel) to its location via the govmap cadastre, then returns the iplan Xplan plans covering that exact parcel (status, deposit/approval dates, committees). Use for a single building that is not necessarily inside a declared compound.
| Name | Required | Description | Default |
|---|---|---|---|
| gush | Yes | Block number (גוש). | |
| helka | Yes | Parcel number (חלקה). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the underlying resolution via 'govmap cadastre' and the returned fields (status, dates, committees), but does not state safety (read-only), failure behavior for invalid gush/helka, or other operational traits.
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: the first delivers the core workflow, the second the usage guidance. No filler or repetition of schema property names.
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 2-parameter lookup with no output schema, it explains the return contents (status, deposit/approval dates, committees) and the use case, which is largely sufficient. It omits edge cases (e.g., no plans found, invalid block/parcel) but those are minor given the siblings provide a clear selection context.
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% with basic labels ('Block number', 'Parcel number'). The description adds meaning by explaining that gush+helka are resolved together via the cadastre to locate the parcel, which clarifies the combined semantic role beyond the schema.
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 verb ('resolves' and 'returns') with a precise resource: iplan Xplan plans covering an exact parcel. It also distinguishes itself from compound-focused siblings by noting it is for 'a single building that is not necessarily inside a declared compound.'
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?
The final sentence gives clear when-to-use context ('Use for a single building that is not necessarily inside a declared compound'). It does not explicitly name alternative tools or state when not to use, but the compound exclusion implies a boundary against compound-level siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live statutory detail for a specific plan from the iplan "תכנון זמין" / Xplan system: current status, deposit and approval dates, district + local committee, approving authority, and authorized-unit counts. Query by plan number, or by ITM (wkid 2039) point to get every plan covering that location.
| Name | Required | Description | Default |
|---|---|---|---|
| x | No | ITM easting (with y) for a point-in-polygon query. | |
| y | No | ITM northing (with x). | |
| plan_number | No | Plan number, e.g. "507-0177683". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It does add useful behavioral context: the data is 'live', and a point query returns every covering plan. However, it does not state whether the operation is read-only, how results are shaped, whether plan_number and x/y are exclusive, or any error/limit behavior.
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 dense sentences with no filler: the first states what the tool returns, and the second explains the two query modes. The most important usage information is front-loaded and every phrase contributes.
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?
The description covers purpose, key outputs, and both query modes well. However, with no annotations and no output schema, it should more explicitly state that at least one query path must be supplied, that plan_number and x/y are alternatives, and what the response format or edge cases look like. These gaps could confuse an agent invoking the tool.
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%, so the schema already documents each parameter. The description adds extra meaning by specifying the ITM coordinate reference as wkid 2039 and clarifying that x/y form a point-in-polygon query returning all plans covering that location. This goes beyond the schema's terse field descriptions.
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 names a concrete resource (a statutory plan from the iplan/Xplan system) and enumerates the returned details: status, dates, committees, approving authority, and unit counts. It also clarifies the secondary point-query behavior. It does not explicitly distinguish from siblings, but the specific resource and output fields make the purpose sufficiently clear.
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 provides explicit usage modes: query by plan_number, or query by an ITM point (x/y) to retrieve all plans covering that location. This is clear context for when to use each parameter combination. It does not name sibling alternatives, but none of the listed siblings are obviously in the same statutory-plan domain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Keyword search across QUANTUM-tracked pinui-binui compounds by compound name, city, or neighborhood. Use when user asks about a specific compound or area.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Optional Hebrew city name filter (e.g. "תל אביב", "רמת גן"). | |
| limit | No | ||
| query | Yes | Search query (Hebrew or English). Matched against compound name, city, neighborhood. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the search scope and fields, but omits details on pagination, result limits, error behavior, or whether the search is fuzzy/exact. This is insufficient for an unannotated tool.
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 concise sentences that front-load the purpose and provide usage guidance. No redundant or unnecessary words.
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?
The description covers purpose and usage but lacks behavioral details (pagination, sorting, error handling, output structure) that would help an agent use the tool reliably, especially given the absence of annotations and output schema.
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 67% (query and city have descriptions, limit does not). The tool description paraphrases the query parameter's matching fields but adds no new semantics for city or limit. It does not compensate for the missing limit description.
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 explicitly states the verb 'search', the resource 'QUANTUM-tracked pinui-binui compounds', and the search fields 'compound name, city, or neighborhood'. It distinguishes itself from sibling tools like get_compound_details by focusing on keyword-based lookup.
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?
The description advises 'Use when user asks about a specific compound or area', providing clear context. However, it does not explicitly exclude cases where a compound ID is known or mention sibling tools like get_compound_details as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Authoritative statutory status for declared Israeli pinui-binui compounds, sourced from the Government Authority for Urban Renewal registry (data.gov.il). Returns compound number, name, city, official status, plan number, declaration date, unit counts, permits, and MAVAT/govmap deep-links. Use to confirm a compound is officially declared and at what statutory stage.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Hebrew city filter (e.g. "רמת גן"). | |
| limit | No | ||
| mispar | No | Compound number (MisparMitham) for an exact lookup. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden, and it does well by disclosing the authoritative data source, the fact that it returns a defined set of status-related fields, and the confirm-only purpose. It does not mention pagination/limit behavior, possible status values, or data freshness, which would make the behavior fully transparent.
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 deliver source, authority, output fields, and intended use with no filler. The key scoping phrase 'authoritative statutory status' is front-loaded, making the tool easy to scan.
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?
No output schema exists, so the description compensates by listing the returned fields and the statutory-purpose framing. Given the simple optional-parameter input schema, the main omission is not explaining default behavior when no parameters are supplied or how this differs from search_compounds.
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 67%: city and mispar are described in the schema, and the description adds little parameter-specific meaning beyond mentioning compound number as a return field. The limit parameter is not described in either the schema or the description, though its type, default, min, and max are given in the schema.
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 clearly identifies the tool as a lookup of authoritative statutory status for Israeli pinui-binui compounds from the government registry, and lists the concrete fields returned. It does not explicitly contrast itself with siblings like search_compounds or get_compound_details, missing the explicit differentiation needed for a 5.
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?
The final sentence gives an explicit use case: confirm a compound is officially declared and at what statutory stage. However, it does not state when not to use this tool or name an alternative tool for related lookups, so it earns a 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List declared Israeli VATMAL (ות"מל — preferred-housing) urban-renewal complexes from the iplan vatmal_mitchamim_muchrazim layer: tamal plan number, compound name, city, district, submitter, planned units, area, declaration date. Filter by city or tamal number. Use for the ות"מל fast-track pipeline specifically.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Hebrew city filter (e.g. "רמת גן"). | |
| limit | No | ||
| tamal | No | VATMAL plan-number filter (e.g. "1001"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden, and it clearly frames the operation as a read-only listing scoped to a declared layer. It also discloses the available filters and output fields. It does not discuss pagination or rate limits, but the schema's limit parameter mitigates the main gap.
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?
The description front-loads the action and resource, then packs the output fields into a compact colon-separated list. Every sentence earns its place, and there is no filler or redundant repetition of schema details.
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 simple optional-filter list tool with no output schema, the description covers the source layer, return fields, filters, and intended use case. Minor ambiguity remains about whether city and tamal combine and what happens when neither filter is provided, but these are small gaps for such a straightforward tool.
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?
The schema already documents city and tamal, covering 67% of parameters; the description mostly rephrases this as 'Filter by city or tamal number' and clarifies that tamal refers to a plan number. It adds nothing meaningful about the limit parameter, so it does not go beyond the baseline.
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 opens with a specific verb and resource: 'List declared Israeli VATMAL ... complexes from the iplan vatmal_mitchamim_muchrazim layer' and enumerates the exact fields returned. This clearly distinguishes it from sibling tools focused on details, search, methodology, or statutory changes, and the 'fast-track pipeline' phrase marks its niche.
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 gives explicit usage context: 'Use for the ות"מל fast-track pipeline specifically,' which helps an agent know when to prefer this tool. It does not name alternative tools or state when not to use it, so it stops short of the top tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
lead_scoreasset_analyze4 fields changedInput schema / properties / addresses / descriptionPrevious value: -"Building addresses with house numbers, e.g. [\"ערבה 2\",\"ערבה 4\"]."New value: +"Building addresses with house numbers, e.g. [\"ערבה 2\",\"ערבה 4\"]. When a building's gush/helka is verified, give it as {\"address\":\"ערבה 4\",\"gush\":4012,\"helka\":83}: that parcel is used for the building instead of the address lookup."Input schema / properties / addresses / items / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "properties": {
+ "address": {
+ "type": "string"
+ },
+ "gush": {
+ "type": "integer"
+ },
+ "helka": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "address"
+ ],
+ "type": "object"
+ }
+]Input schema / properties / addresses / items / typeRemoved value: -"string"Input schema / properties / neighborhoodAdded value: +{
+ "description": "Neighbourhood, optional (e.g. \"בן גוריון\"). The web research is held to \"שכונת X, <city>\"; without it the neighbourhood the deal records give the parcel is used.",
+ "type": "string"
+}asset_analyze1 field changedInput schema / properties / wait_secondsAdded value: +{
+ "description": "How long to wait for the result before returning {pending, run_id} (default 50, max 290). The check keeps running either way; collect it with asset_result.",
+ "type": "integer"
+}asset_resultasset_analyze2 fields changedInput schema / properties / apartmentsAdded value: +{
+ "description": "Existing apartments, when known (used when one address is given; otherwise looked up per building).",
+ "type": "integer"
+}Input schema / properties / floorsAdded value: +{
+ "description": "Existing floors, when known (used when one address is given; otherwise looked up per building).",
+ "type": "integer"
+}asset_analyze1 field changedInput schema / properties / contextAdded value: +{
+ "description": "Optional facts for the synthesis, e.g. \"4 בניינים, 16 דירות כל אחד, 4 קומות\".",
+ "type": "string"
+}asset_analyzecompound_full1 field changedInput schema / properties / addressesAdded value: +{
+ "description": "Building addresses in the city (e.g. [\"ערבה 2\",\"ערבה 4\"]). Each is geocoded and checked against the iplan plan covering it (Card F). Needs city.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}compound_full2 fields changedInput schema / properties / gushAdded value: +{
+ "description": "Block number (גוש) for parcel-level plans.",
+ "type": "integer"
+}Input schema / properties / helkaAdded value: +{
+ "description": "Parcel number (חלקה), with gush.",
+ "type": "integer"
+}planning_by_parcelcompound_fullvatmal_compoundsplanning_status_by_planurban_renewal_registryget_compound_detailsget_methodologylist_recent_statutory_changeslist_top_mispriced_compoundssearch_compounds
Add one secure layer between your agents and this server.