Skip to main content
Glama

Pinuy Binuy Analyzer

by app.railway.up.pinuy-binuy-analyzer-production
OverviewDiscussionsAdmin

asset_analyze

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cityYesHebrew city name, e.g. "לוד".
gushNoBlock (גוש), optional.
nameNoCompound name, optional.
planNoPlan number, optional.
helkaNoParcel (חלקה), optional, with gush.
floorsNoExisting floors, when known (used when one address is given; otherwise looked up per building).
contextNoOptional facts for the synthesis, e.g. "4 בניינים, 16 דירות כל אחד, 4 קומות".
addressesNoBuilding 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.
apartmentsNoExisting apartments, when known (used when one address is given; otherwise looked up per building).
neighborhoodNoNeighbourhood, optional (e.g. "בן גוריון"). The web research is held to "שכונת X, <city>"; without it the neighbourhood the deal records give the parcel is used.
wait_secondsNoHow 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / addresses / description
      Previous 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."
    • addedInput schema / properties / addresses / items / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "properties": {
+      "address": {
+        "type": "string"
+      },
+      "gush": {
+        "type": "integer"
+      },
+      "helka": {
+        "type": "integer"
+      }
+    },
+    "required": [
+      "address"
+    ],
+    "type": "object"
+  }
+]
    • removedInput schema / properties / addresses / items / type
      Removed value: -"string"
    • addedInput schema / properties / neighborhood
      Added 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"
+}
  2. Changed1 schema field changed
    • addedInput schema / properties / wait_seconds
      Added 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"
+}
  3. Changed2 schema fields changed
    • addedInput schema / properties / apartments
      Added value: +{
+  "description": "Existing apartments, when known (used when one address is given; otherwise looked up per building).",
+  "type": "integer"
+}
    • addedInput schema / properties / floors
      Added value: +{
+  "description": "Existing floors, when known (used when one address is given; otherwise looked up per building).",
+  "type": "integer"
+}
  4. Changed1 schema field changed
    • addedInput schema / properties / context
      Added value: +{
+  "description": "Optional facts for the synthesis, e.g. \"4 בניינים, 16 דירות כל אחד, 4 קומות\".",
+  "type": "string"
+}
  5. Added

TDQS

A4.4/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All Pinuy Binuy Analyzer toolsInspect
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