UDCPR 2020 (Maharashtra) feasibility for a plot, with the clause behind every number.
Scored across 9 tools
The domain tools (feasibility, check_design, compare_uses, draw_plot) are mostly distinct, though check_design vs feasibility and draw_plot's embedded feasibility call slightly blur lines. The bigger issue is a retrieval cluster—search, search_udcpr, clause, and fetch all return UDCPR text and could easily be misselected, with clause and fetch especially close in output.
All names are snake_case and readable, which is good. However, the convention is mixed: some are verb_noun (check_design, compare_uses, draw_plot, search_udcpr) while others are bare nouns (clause, feasibility, towns) or single verbs (search, fetch), so there's no single predictable pattern.
Nine tools is a reasonable, well-scoped set for UDCPR feasibility work and each earns a place. The retrieval layer is slightly redundant (four overlapping lookup tools), which nudges it just below ideal.
Coverage of the UDCPR domain is strong: regulation lookup (search/search_udcpr/fetch/clause), town resolution, feasibility, design checking, use comparison, and plot geometry are all present. Explicitly excluded areas (Greater Mumbai, land prices, building permission) are out of scope by design, leaving only minor gaps.
Use this when someone has a proposed building on a plot in Maharashtra and wants to know whether it meets UDCPR. Checks a proposal's built-up, height and margins (one per side, in side order) against UDCPR, with allowed, proposed and pass or fail per item. Margins need the height or the upper floors with them.
| Name | Required | Description | Default |
|---|---|---|---|
| crz | No | the coastal regulation zone the plot is in: I (between the tide lines), II, or III within its No Development Zone. No TDR in the coastal zone (11.2.8(c)); development as the CRZ Notification allows (1.6(i)) | |
| tod | No | plot inside a TOD zone (14.2): Municipal Corporations, metropolitan authorities and CIDCO; the Nagpur Metro Rail Corridor by Table 14-P | |
| use | Yes | ||
| area | Yes | plot area as the user gave it, in m2 unless area_unit says sqft, guntha, acre or hectare: the least of 7/12, measurement sheet and site | |
| beds | No | beds: for hospitals, parking, water, sanitation and grey water; for hotels, water | |
| road | No | width of the road in front, in m unless road_unit is ft, when there is one road and no sides | |
| town | Yes | Maharashtra town, city or planning authority, e.g. Pune, Kolhapur, Nashik, PMRDA | |
| zone | No | nc non-congested, c congested (gaothan) | |
| areas | No | the three areas of Appendix A item 1, in m2, for the area statement: ownership (the 7/12 or property card), sheet (the measurement sheet of the Land Records) and site (by the measurements); area is the least of those given | |
| flats | No | number of flats; with carpet, a one-type unit mix | |
| green | No | green rating committed (IGBC / GRIHA / LEED tier) for the incentive FSI of 7.10 on basic FSI: 3%, 5% or 7% | |
| rooms | No | guest rooms, for hotel parking and sanitation | |
| seats | No | seats, for assembly parking | |
| sides | No | every side, anticlockwise, starting at a road | |
| stilt | No | ||
| units | No | the unit mix, one entry per type, e.g. [{"type":"2 BHK","count":12,"carpet":60},{"type":"Shop","count":4,"carpet":25}]; parking takes each type in its own Table 8-B row; a count left out is worked out from the building | |
| wings | No | a group housing project as wings, each with its own typical floor and floors; units then gives each type and its carpet only. Returns each wing's height, lifts, special building and the distance between wings (6.2.4), and the built-up the wings need against what the rules allow | |
| carpet | No | carpet area of a flat, m2 | |
| margin | No | margin the developer needs, % of sales value; with the rates, gives what the land carries and the largest share of the flats for the landowner in a joint development | |
| papers | No | the papers the facts were read from, when they were: 712 (the 7/12 extract or property card, for the area), sheet (the measurement sheet, for the sides and area), zone (the zone certificate or DP remark, for the zone, the road width, road widening and reservations), layout (the sanctioned layout or regularisation order). The study marks each fact as read from its paper or as told; no rule reads them | |
| buy_tdr | No | false: the study is drawn without buying TDR, on basic and premium FSI with their ancillary area; default true. Either way, tdr_choice sets both side by side, with the most TDR is worth to this plot when sale_rate and build_cost are given | |
| polygon | No | plot corners [x, y] in m, anticlockwise, one per side, side 1 first; needed for plots that are not rectangles | |
| rc_rate | No | the ASR rate of RCC construction, Rs a m², for the land rate to construction rate ratio of Tables 7-C to 7-E | |
| asr_rate | No | land rate of the plot in the Annual Statement of Rates, Rs a m2; gives premiums in rupees and the DRC to debit | |
| land_use | No | the zone on the development or regional plan: residential, commercial, industrial, public / semi-public, agricultural, transport, green belt, loom industry cum residential (4.9), regional park (4.14), tourism development (4.15), afforestation (4.16), hill top (4.17), green zone 2 (4.18), forest, defence, mines and quarry, public utility, woodland corridor, special economic zone, airport (4.19 to 4.25) | |
| measured | No | true: the polygon is the plot as measured on site (draw_plot gives it so), drawn as it is; area, the least of the areas of Appendix A item 1, may then be smaller than the polygon. Without it the drawing is scaled to area | |
| proposed | Yes | ||
| tdr_rate | No | price of TDR, Rs a sq ft | |
| area_unit | No | unit of area, road_widening and reservation as the user gave them; default m2. Citiwise converts and says so in units | |
| basements | No | levels of basement, for parking and services (9.11) | |
| bathrooms | No | factories: whether bath-rooms are provided, for water (Table 12-A) | |
| jda_offer | No | share of the flats a developer has offered the landowner in a joint development, %; with the rates, gives what the developer keeps at that share beside the share the plot carries | |
| road_unit | No | unit of road and of each road side's width as the user gave them; default m | |
| sale_rate | No | sale rate, Rs a sq ft of carpet area; with build_cost and tdr_rate gives an appraisal: sales value, construction, premiums, TDR and the surplus before land | |
| build_cost | No | construction cost, Rs a sq ft of built-up area | |
| flood_zone | No | the plot lies within the blue flood line (prohibitive: no construction, no TDR) or between the blue and red flood lines (restrictive: plinth above the red flood line) (3.1.3; 11.2.8(b)) | |
| land_price | No | asking price of the land when it is being bought, Rs for the whole plot; with the rates, gives the profit at that price and how far it sits from what the land carries | |
| sprinklers | No | mixed building fully sprinklered with the travel distances kept: under the 1.3(93)(xiv) note it stays out of the special building rules up to 24 m with floors up to 750 m², subject to fire NOC | |
| steep_area | No | m² of the plot steeper than 1 in 5: hill top and hill slope land, not built upon (3.1(iii); 4.0 (XIV)) | |
| use_carpet | No | carpet area of a non-residential use, or of the shops below flats, m2, for its parking and water; default the built-up that fits | |
| buy_premium | No | false: the study is drawn without premium FSI (and without the Table 7-A higher FSI, which is taken on premium), on basic FSI, any TDR and the ancillary area; default true | |
| handed_over | No | ||
| layout_kind | No | the land is laid out into plots, or developed as a group housing scheme; returns layout: the internal road widths of Tables 3A to 3C and what the layout carries (3.3, 3.4, 2.7.2) | |
| other_costs | No | other costs (fees, finance, marketing), % of construction cost | |
| plot_origin | No | layout: sanctioned layout or sub-division; unauthorised: sub-divided after 11.01.1967 without permission; gunthewari: regularised under the Gunthewari Act | |
| prepared_by | No | who is giving the study, as it should appear on its cover, e.g. a broker or developer | |
| reservation | No | ||
| carpet_share | No | carpet area as a share of the built-up, 0.3 to 0.95 or 30 to 95 (default 0.8); sets the unit counts left out and so the sales value | |
| floor_height | No | ||
| gaothan_belt | No | a Regional Plan village plot in the agricultural zone, within the belt around the gaothan or a town where 5.1.1 permits residential development, on a premium of a share of the land's ASR rate | |
| parking_cost | No | construction cost of the stilt floor, Rs a sq ft; the stilt is free of FSI but built; default build_cost | |
| prepared_for | No | who the study is for, as it should appear on its cover, e.g. the landowner or client | |
| step_margins | No | true: step margins on upper floors (6.2.3(c)): each floor keeps the side and rear margin its own height needs, so lower floors are larger; 6 m at the ground for a special building | |
| access_length | No | the plot does not abut a public street: the length of the access way to it, m, measured to the street; 'road' is then the access way's width (3.2.2, 3.3.3) | |
| avoid_special | No | true: keep the building out of the special building rules (1.3(93)(xiv)): no higher than 24 m, and for the uses the floor area reaches, each floor below 500 m² (750 m² for a sprinklered mixed building). Either way, special_choice sets the building kept out beside the special building, with what the special building brings | |
| existing_kind | No | what stands on the plot, for redevelopment (7.4, 7.5, 7.6): a co-operative society's building, a tenanted building, a MHADA scheme building redeveloped by the society or by MHADA, or a bungalow; returns schemes with the figures | |
| ground_height | No | ||
| power_line_kv | No | voltage of an overhead line near the plot, kV, for its clearance | |
| road_widening | No | ||
| allotted_basic | No | for a plot of a plotted layout, the basic FSI area in m² the layout plan allots it (3.9(iii)), up to the most the plot may receive | |
| basement_flush | No | basement top flush with the ground: it may then run into the side and rear margins (9.11.1 proviso i) | |
| slum_tenements | No | eligible hutments on the plot, for slum rehabilitation (14.6, 14.7) | |
| specified_area | No | Kolhapur: the characteristic specified area of Table 10-B (10.9.1) the plot is in, by Sr. No. ('1' for Rajarampuri) or the area's name; where the row has several plot sizes, Sr. No. and the plot row, e.g. '3.2'. Sets the Table 10-B margins and coverage and the Note 1 basic FSI. Pune: 'koregaon_park' (10.1.2). A Regional Plan area: an area of Chapter 5 with rules of its own, one of hill_station, station_near, station_far, tarapur, ratnagiri_pada, sindhudurg_t2, sindhudurg_t4, sindhudurg_t5, mp_buffer_edge, mp_buffer_gaothan, satara_core, satara_buffer, nagothane, wadi, rajpuri_usar, sector_r_lonavala, sector_r_kune, aurangabad_strip, ligo. Chapter 10 city areas, Pune: parvati_chatushrungi, arde, hemrl; Thane: ram_maruti, gokhale, express_highway, chemical_green_belt, chemical_low_density, air_force, defence_buffer, g1_yeur, g3_forest, eco_sensitive, defence_west_orange, defence_west_pink, defence_west_navy_blue, defence_west_yellow, defence_west_violet, defence_west_green, defence_east_orange, defence_east_pink, defence_east_yellow, defence_east_violet, defence_east_sky_blue; Nashik: tps1, gangapur_ambad; Vasai-Virar: low_density, eco_sensitive; Mira-Bhayandar: road_strip, manori_gorai_uttan, eco_sensitive; NMRDA: ring_road, township, gaothan_small, gaothan_large | |
| existing_carpet | No | carpet area of the existing tenements together, m² (7.4.2, 7.6) | |
| reservation_type | No | what the DP reservation on the plot is for; with 'reservation', returns accommodation_reservation: developing it by its owner under 11.1, Table 11-A | |
| existing_built_up | No | authorised built-up of the existing building, m², with its TDR and premium FSI (7.5, 7.6) | |
| existing_tenements | No | tenements in the existing building (7.4.2, 7.6) | |
| road_widening_side | No | side number (1-based) that the road widening strip comes off; default the first road side | |
| tdr_generating_rate | No | ASR land rate of the TDR's generating plot, Rs a m2 (11.2.6) | |
| internal_road_length | No | with layout_kind, the length of the longest internal road, m, from the farthest plot or building to the public street (3.3.3) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description only needs added context. It supplies real behavioral detail: the per-item allowed/proposed/pass-fail output and the dependency that margins require height or upper_floors to be meaningful.
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, front-loaded with the trigger, then the check performed and its output shape, then the one hard prerequisite. No sentence is redundant and nothing is buried.
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 70-parameter tool with nested objects and no output schema, the description is substantial: it names the trigger, the checks, the output shape and a key parameter dependency. It could say more about how results are framed or what other factors (CRZ, flood, TDR) affect the verdict, but the essentials for calling it correctly are present.
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 89%, so the schema does most of the work and the baseline is 3. The description adds genuine semantics beyond it: margins are one per side in side order, and margins must be accompanied by height or upper_floors. Only the remaining ~11% of uncovered params are left entirely to 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?
States a specific verb ('Checks') and resource (a proposal's built-up, height and margins) against a named standard (UDCPR), and enumerates what the result contains (allowed, proposed, pass/fail per item). That is enough to separate it from siblings like feasibility, compare_uses or draw_plot 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?
The opening clause gives an explicit when-to-use trigger: a proposed building on a Maharashtra plot needing a UDCPR compliance answer. It does not name any alternative sibling or state exclusions, so it falls short of a full routing statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks what a specific UDCPR regulation or table says. Returns the UDCPR text of a regulation or table by its number, such as '6.2.6', '11.2.4' or 'Table 6-G'.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds only that the output is the verbatim clause text, with no note on lookup failure behavior for invalid references or coverage gaps.
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 trigger condition followed by the return contract and format examples. No filler.
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 one-parameter read-only lookup with rich annotations and no output schema, the description covers the essential trigger, action, and input format. Only the invalid-reference behavior remains 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 coverage is 0% — the single 'ref' parameter is entirely undocumented in the schema, so the description carries the burden. It does so reasonably by giving the expected format types ('6.2.6', '11.2.4', 'Table 6-G'), though it doesn't state whether the number must be quoted, normalized, or exact.
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 ('Returns the UDCPR text of a regulation or table by its number') and anchors it with concrete example references. It implicitly contrasts with the sibling search_udcpr (direct lookup by number vs. search), though it never names that sibling.
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?
'Use this when someone asks what a specific UDCPR regulation or table says' gives a clear triggering condition. It does not explicitly state when NOT to use it or name search_udcpr as the fallback for fuzzy/topic queries, so exclusions are left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone wants to know which uses are allowed on a plot in Maharashtra, or how built-up differs between uses on the same land. Returns every use on the same land in a fixed order: allowed or the reason not, conditions, clause, and built-up with and without TDR.
| Name | Required | Description | Default |
|---|---|---|---|
| crz | No | the coastal regulation zone the plot is in: I (between the tide lines), II, or III within its No Development Zone. No TDR in the coastal zone (11.2.8(c)); development as the CRZ Notification allows (1.6(i)) | |
| tod | No | plot inside a TOD zone (14.2): Municipal Corporations, metropolitan authorities and CIDCO; the Nagpur Metro Rail Corridor by Table 14-P | |
| area | Yes | plot area as the user gave it, in m2 unless area_unit says sqft, guntha, acre or hectare: the least of 7/12, measurement sheet and site | |
| beds | No | beds: for hospitals, parking, water, sanitation and grey water; for hotels, water | |
| road | No | width of the road in front, in m unless road_unit is ft, when there is one road and no sides | |
| town | Yes | Maharashtra town, city or planning authority, e.g. Pune, Kolhapur, Nashik, PMRDA | |
| zone | No | nc non-congested, c congested (gaothan) | |
| areas | No | the three areas of Appendix A item 1, in m2, for the area statement: ownership (the 7/12 or property card), sheet (the measurement sheet of the Land Records) and site (by the measurements); area is the least of those given | |
| flats | No | number of flats; with carpet, a one-type unit mix | |
| green | No | green rating committed (IGBC / GRIHA / LEED tier) for the incentive FSI of 7.10 on basic FSI: 3%, 5% or 7% | |
| rooms | No | guest rooms, for hotel parking and sanitation | |
| seats | No | seats, for assembly parking | |
| sides | No | every side, anticlockwise, starting at a road | |
| stilt | No | ||
| units | No | the unit mix, one entry per type, e.g. [{"type":"2 BHK","count":12,"carpet":60},{"type":"Shop","count":4,"carpet":25}]; parking takes each type in its own Table 8-B row; a count left out is worked out from the building | |
| wings | No | a group housing project as wings, each with its own typical floor and floors; units then gives each type and its carpet only. Returns each wing's height, lifts, special building and the distance between wings (6.2.4), and the built-up the wings need against what the rules allow | |
| carpet | No | carpet area of a flat, m2 | |
| margin | No | margin the developer needs, % of sales value; with the rates, gives what the land carries and the largest share of the flats for the landowner in a joint development | |
| papers | No | the papers the facts were read from, when they were: 712 (the 7/12 extract or property card, for the area), sheet (the measurement sheet, for the sides and area), zone (the zone certificate or DP remark, for the zone, the road width, road widening and reservations), layout (the sanctioned layout or regularisation order). The study marks each fact as read from its paper or as told; no rule reads them | |
| buy_tdr | No | false: the study is drawn without buying TDR, on basic and premium FSI with their ancillary area; default true. Either way, tdr_choice sets both side by side, with the most TDR is worth to this plot when sale_rate and build_cost are given | |
| polygon | No | plot corners [x, y] in m, anticlockwise, one per side, side 1 first; needed for plots that are not rectangles | |
| rc_rate | No | the ASR rate of RCC construction, Rs a m², for the land rate to construction rate ratio of Tables 7-C to 7-E | |
| asr_rate | No | land rate of the plot in the Annual Statement of Rates, Rs a m2; gives premiums in rupees and the DRC to debit | |
| land_use | No | the zone on the development or regional plan: residential, commercial, industrial, public / semi-public, agricultural, transport, green belt, loom industry cum residential (4.9), regional park (4.14), tourism development (4.15), afforestation (4.16), hill top (4.17), green zone 2 (4.18), forest, defence, mines and quarry, public utility, woodland corridor, special economic zone, airport (4.19 to 4.25) | |
| measured | No | true: the polygon is the plot as measured on site (draw_plot gives it so), drawn as it is; area, the least of the areas of Appendix A item 1, may then be smaller than the polygon. Without it the drawing is scaled to area | |
| tdr_rate | No | price of TDR, Rs a sq ft | |
| area_unit | No | unit of area, road_widening and reservation as the user gave them; default m2. Citiwise converts and says so in units | |
| basements | No | levels of basement, for parking and services (9.11) | |
| bathrooms | No | factories: whether bath-rooms are provided, for water (Table 12-A) | |
| jda_offer | No | share of the flats a developer has offered the landowner in a joint development, %; with the rates, gives what the developer keeps at that share beside the share the plot carries | |
| road_unit | No | unit of road and of each road side's width as the user gave them; default m | |
| sale_rate | No | sale rate, Rs a sq ft of carpet area; with build_cost and tdr_rate gives an appraisal: sales value, construction, premiums, TDR and the surplus before land | |
| build_cost | No | construction cost, Rs a sq ft of built-up area | |
| flood_zone | No | the plot lies within the blue flood line (prohibitive: no construction, no TDR) or between the blue and red flood lines (restrictive: plinth above the red flood line) (3.1.3; 11.2.8(b)) | |
| land_price | No | asking price of the land when it is being bought, Rs for the whole plot; with the rates, gives the profit at that price and how far it sits from what the land carries | |
| sprinklers | No | mixed building fully sprinklered with the travel distances kept: under the 1.3(93)(xiv) note it stays out of the special building rules up to 24 m with floors up to 750 m², subject to fire NOC | |
| steep_area | No | m² of the plot steeper than 1 in 5: hill top and hill slope land, not built upon (3.1(iii); 4.0 (XIV)) | |
| use_carpet | No | carpet area of a non-residential use, or of the shops below flats, m2, for its parking and water; default the built-up that fits | |
| buy_premium | No | false: the study is drawn without premium FSI (and without the Table 7-A higher FSI, which is taken on premium), on basic FSI, any TDR and the ancillary area; default true | |
| handed_over | No | ||
| layout_kind | No | the land is laid out into plots, or developed as a group housing scheme; returns layout: the internal road widths of Tables 3A to 3C and what the layout carries (3.3, 3.4, 2.7.2) | |
| other_costs | No | other costs (fees, finance, marketing), % of construction cost | |
| plot_origin | No | layout: sanctioned layout or sub-division; unauthorised: sub-divided after 11.01.1967 without permission; gunthewari: regularised under the Gunthewari Act | |
| prepared_by | No | who is giving the study, as it should appear on its cover, e.g. a broker or developer | |
| reservation | No | ||
| carpet_share | No | carpet area as a share of the built-up, 0.3 to 0.95 or 30 to 95 (default 0.8); sets the unit counts left out and so the sales value | |
| floor_height | No | ||
| gaothan_belt | No | a Regional Plan village plot in the agricultural zone, within the belt around the gaothan or a town where 5.1.1 permits residential development, on a premium of a share of the land's ASR rate | |
| parking_cost | No | construction cost of the stilt floor, Rs a sq ft; the stilt is free of FSI but built; default build_cost | |
| prepared_for | No | who the study is for, as it should appear on its cover, e.g. the landowner or client | |
| step_margins | No | true: step margins on upper floors (6.2.3(c)): each floor keeps the side and rear margin its own height needs, so lower floors are larger; 6 m at the ground for a special building | |
| access_length | No | the plot does not abut a public street: the length of the access way to it, m, measured to the street; 'road' is then the access way's width (3.2.2, 3.3.3) | |
| avoid_special | No | true: keep the building out of the special building rules (1.3(93)(xiv)): no higher than 24 m, and for the uses the floor area reaches, each floor below 500 m² (750 m² for a sprinklered mixed building). Either way, special_choice sets the building kept out beside the special building, with what the special building brings | |
| existing_kind | No | what stands on the plot, for redevelopment (7.4, 7.5, 7.6): a co-operative society's building, a tenanted building, a MHADA scheme building redeveloped by the society or by MHADA, or a bungalow; returns schemes with the figures | |
| ground_height | No | ||
| power_line_kv | No | voltage of an overhead line near the plot, kV, for its clearance | |
| road_widening | No | ||
| allotted_basic | No | for a plot of a plotted layout, the basic FSI area in m² the layout plan allots it (3.9(iii)), up to the most the plot may receive | |
| basement_flush | No | basement top flush with the ground: it may then run into the side and rear margins (9.11.1 proviso i) | |
| slum_tenements | No | eligible hutments on the plot, for slum rehabilitation (14.6, 14.7) | |
| specified_area | No | Kolhapur: the characteristic specified area of Table 10-B (10.9.1) the plot is in, by Sr. No. ('1' for Rajarampuri) or the area's name; where the row has several plot sizes, Sr. No. and the plot row, e.g. '3.2'. Sets the Table 10-B margins and coverage and the Note 1 basic FSI. Pune: 'koregaon_park' (10.1.2). A Regional Plan area: an area of Chapter 5 with rules of its own, one of hill_station, station_near, station_far, tarapur, ratnagiri_pada, sindhudurg_t2, sindhudurg_t4, sindhudurg_t5, mp_buffer_edge, mp_buffer_gaothan, satara_core, satara_buffer, nagothane, wadi, rajpuri_usar, sector_r_lonavala, sector_r_kune, aurangabad_strip, ligo. Chapter 10 city areas, Pune: parvati_chatushrungi, arde, hemrl; Thane: ram_maruti, gokhale, express_highway, chemical_green_belt, chemical_low_density, air_force, defence_buffer, g1_yeur, g3_forest, eco_sensitive, defence_west_orange, defence_west_pink, defence_west_navy_blue, defence_west_yellow, defence_west_violet, defence_west_green, defence_east_orange, defence_east_pink, defence_east_yellow, defence_east_violet, defence_east_sky_blue; Nashik: tps1, gangapur_ambad; Vasai-Virar: low_density, eco_sensitive; Mira-Bhayandar: road_strip, manori_gorai_uttan, eco_sensitive; NMRDA: ring_road, township, gaothan_small, gaothan_large | |
| existing_carpet | No | carpet area of the existing tenements together, m² (7.4.2, 7.6) | |
| reservation_type | No | what the DP reservation on the plot is for; with 'reservation', returns accommodation_reservation: developing it by its owner under 11.1, Table 11-A | |
| existing_built_up | No | authorised built-up of the existing building, m², with its TDR and premium FSI (7.5, 7.6) | |
| existing_tenements | No | tenements in the existing building (7.4.2, 7.6) | |
| road_widening_side | No | side number (1-based) that the road widening strip comes off; default the first road side | |
| tdr_generating_rate | No | ASR land rate of the TDR's generating plot, Rs a m2 (11.2.6) | |
| internal_road_length | No | with layout_kind, the length of the longest internal road, m, from the farthest plot or building to the public street (3.3.3) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered by structured data. The description then adds the one thing annotations cannot: the shape of the return, "every use on the same land in a fixed order: allowed or the reason not, conditions, clause, and built-up with and without TDR." With no output schema present, this output disclosure is genuinely valuable.
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 tightly written sentences: the first front-loads the invocation trigger, the second enumerates the return contents in order. Every clause earns its place and there is no filler, restatement of the title, or vague throat-clearing.
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 compensates for the absent output schema by describing the return fields, which is important for a tool this complex. But against 68 parameters, 11 enums and nested objects, it says nothing about the huge optional surface (TDR, premiums, appraisals, redevelopment, layout) or how it relates to the overlapping feasibility sibling, leaving the agent to infer the tool's true scope from the name alone.
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 91% across 68 parameters, with rich per-field descriptions, enums and documented defaults, so the schema carries the semantic load. The description adds no parameter-level meaning (no mention of town, area, or the large optional surface). A baseline 3 is appropriate when the schema already documents nearly everything.
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 specific verb and resource: it answers which uses are permitted on a Maharashtra plot and how built-up differs between those uses on the same land. That is far more than a restatement of the name. It stops short of a 5 because it never distinguishes itself from close siblings such as feasibility or check_design, which an agent could easily confuse with this output.
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 trigger is explicit: "Use this when someone wants to know which uses are allowed on a plot in Maharashtra, or how built-up differs between uses on the same land." That is a clear when-to-invoke condition. However, there are no exclusions and no routing to the plausibly overlapping alternatives (feasibility, check_design), so it does not reach the 5 bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when a plot's shape is given as measurements rather than as one area: side lengths with the angles at the corners, or with diagonals, or both, as on a hand-drawn sketch, a measurement sheet, a survey or a photo of any of them; or the corners themselves. Read the figures as written (feet and inches such as 40'6", the area as on the 7/12 in guntha, acre or H.R.); a side left unmeasured may be null where the rest fix it. Works out the exact corners, fitting every figure by least squares when more are given than needed, reports how far each sits from the plot (closing side, angle sum, spare diagonals, stated area), refuses a misfit no tape makes, and returns the polygon and sides to pass to feasibility, the statement of area by the triangulation method (UDCPR 2.2.3(iii): lettered triangles, each by Heron from its sides as printed, the polygon rebuilt from the same lengths), a link that opens the plot drawn in Citiwise, and, when town and use are given, the feasibility with its report. Do not use for a plot described only by its area and road width; call feasibility directly.
| Name | Required | Description | Default |
|---|---|---|---|
| use | No | ||
| town | No | with use: also run the feasibility | |
| unit | No | unit of every bare number among the lengths and road widths; default m | |
| zone | No | ||
| sides | Yes | every side in order round the plot, either direction; at least one is a road | |
| angles | No | interior angle in degrees at each corner; corner i is where side i begins; null where not measured | |
| polygon | No | the corners [x, y] instead of lengths and angles, one per side | |
| area_unit | No | unit of stated_area when it is a bare number; default m2 (sq ft with unit ft); hr is hectare-are as on a 7/12 | |
| diagonals | No | corner-to-corner distances; a plot of n sides needs n - 3, e.g. from corner 1 to each corner it does not touch | |
| stated_area | No | the area on the 7/12, property card or measurement sheet, to check against, as written: 5 guntha, 0.12.50 H.R., 5400 sq ft | |
| right_angles | No | true when every corner of a four-sided plot is square |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety profile (readOnly, idempotent, non-destructive); the description adds substantial beyond-schema behavior: least-squares fitting of surplus figures, a stated tolerance policy that refuses an impossible misfit, and concrete outputs (polygon + sides for feasibility, triangulation statement of area per UDCPR 2.2.3(iii), a Citiwise link, and the feasibility run when town and use are supplied).
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 usage condition, which is good, but the middle span is a single run-on chain of clauses ('Read the figures...; Works out... reports... refuses... and returns...') that piles domain detail without breakpoints. The content mostly earns its place, but the structure makes it harder to scan than it needs to be.
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 11 parameters, no output schema, and heavy domain jargon, the description compensates fully: it explains input conventions, the fitting/refusal policy, and every returned artifact. An agent has everything needed to call and interpret 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 already 82%, so the schema carries most parameter meaning. The description nonetheless adds parsing conventions the schema does not state clearly: figures are read as written (40'6", 7/12 guntha, acre, H.R.), and an unmeasured side may be null when the remaining figures fix it.
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: reconstruct a plot's shape (polygon and sides) from measurements — side lengths, corner angles, diagonals, or explicit corners. It also distinguishes itself from siblings by naming the case where it should not be used and routing that case to feasibility.
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?
Explicit when-to-use ('when a plot's shape is given as measurements rather than as one area') and explicit when-not-to-use ('Do not use for a plot described only by its area and road width; call feasibility directly'), with the alternative tool named. This is the strongest dimension of the definition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks what they can build on a plot or piece of land anywhere in Maharashtra outside Greater Mumbai: FSI or FAR, built-up area, setbacks (margins), height, how many floors, parking or approvals under UDCPR 2020, the building rules for every town in the state. People often ask in Marathi or Hindi, or mix them with English: जागा, प्लॉट, गुंठा, चटई क्षेत्र निर्देशांक (FSI), बांधकाम क्षेत्र (built-up), सामासिक अंतर (margins), किती मजले (how many floors), पार्किंग; give the area and road as they said them with area_unit and road_unit. Do not use for Greater Mumbai, for land prices or for building permission itself. Returns the UDCPR feasibility of one plot for one use: area statement, FSI, height limits, the margin on every side, the building that fits, parking, water, sanitary fixtures, stairs and lifts, fire tanks, refuge area, open space and amenity space, and the NOCs the plot and building trigger; the floor counts around the fitted one (options) and the heights that change the rules (thresholds); the Proforma I area statement; premiums as shares of the ASR land rate, scrutiny fee and payment options; TDR loading; what applies (rainwater, solar, grey water, inclusive housing, open space, amenity, refuge, fire NOC); corner rounding; plot-origin options; power line clearance and TOD FSI when those inputs are given. Each value carries its UDCPR clause.
| Name | Required | Description | Default |
|---|---|---|---|
| crz | No | the coastal regulation zone the plot is in: I (between the tide lines), II, or III within its No Development Zone. No TDR in the coastal zone (11.2.8(c)); development as the CRZ Notification allows (1.6(i)) | |
| tod | No | plot inside a TOD zone (14.2): Municipal Corporations, metropolitan authorities and CIDCO; the Nagpur Metro Rail Corridor by Table 14-P | |
| use | Yes | ||
| area | Yes | plot area as the user gave it, in m2 unless area_unit says sqft, guntha, acre or hectare: the least of 7/12, measurement sheet and site | |
| beds | No | beds: for hospitals, parking, water, sanitation and grey water; for hotels, water | |
| road | No | width of the road in front, in m unless road_unit is ft, when there is one road and no sides | |
| town | Yes | Maharashtra town, city or planning authority, e.g. Pune, Kolhapur, Nashik, PMRDA | |
| zone | No | nc non-congested, c congested (gaothan) | |
| areas | No | the three areas of Appendix A item 1, in m2, for the area statement: ownership (the 7/12 or property card), sheet (the measurement sheet of the Land Records) and site (by the measurements); area is the least of those given | |
| flats | No | number of flats; with carpet, a one-type unit mix | |
| green | No | green rating committed (IGBC / GRIHA / LEED tier) for the incentive FSI of 7.10 on basic FSI: 3%, 5% or 7% | |
| rooms | No | guest rooms, for hotel parking and sanitation | |
| seats | No | seats, for assembly parking | |
| sides | No | every side, anticlockwise, starting at a road | |
| stilt | No | ||
| units | No | the unit mix, one entry per type, e.g. [{"type":"2 BHK","count":12,"carpet":60},{"type":"Shop","count":4,"carpet":25}]; parking takes each type in its own Table 8-B row; a count left out is worked out from the building | |
| wings | No | a group housing project as wings, each with its own typical floor and floors; units then gives each type and its carpet only. Returns each wing's height, lifts, special building and the distance between wings (6.2.4), and the built-up the wings need against what the rules allow | |
| carpet | No | carpet area of a flat, m2 | |
| margin | No | margin the developer needs, % of sales value; with the rates, gives what the land carries and the largest share of the flats for the landowner in a joint development | |
| papers | No | the papers the facts were read from, when they were: 712 (the 7/12 extract or property card, for the area), sheet (the measurement sheet, for the sides and area), zone (the zone certificate or DP remark, for the zone, the road width, road widening and reservations), layout (the sanctioned layout or regularisation order). The study marks each fact as read from its paper or as told; no rule reads them | |
| buy_tdr | No | false: the study is drawn without buying TDR, on basic and premium FSI with their ancillary area; default true. Either way, tdr_choice sets both side by side, with the most TDR is worth to this plot when sale_rate and build_cost are given | |
| polygon | No | plot corners [x, y] in m, anticlockwise, one per side, side 1 first; needed for plots that are not rectangles | |
| rc_rate | No | the ASR rate of RCC construction, Rs a m², for the land rate to construction rate ratio of Tables 7-C to 7-E | |
| asr_rate | No | land rate of the plot in the Annual Statement of Rates, Rs a m2; gives premiums in rupees and the DRC to debit | |
| land_use | No | the zone on the development or regional plan: residential, commercial, industrial, public / semi-public, agricultural, transport, green belt, loom industry cum residential (4.9), regional park (4.14), tourism development (4.15), afforestation (4.16), hill top (4.17), green zone 2 (4.18), forest, defence, mines and quarry, public utility, woodland corridor, special economic zone, airport (4.19 to 4.25) | |
| measured | No | true: the polygon is the plot as measured on site (draw_plot gives it so), drawn as it is; area, the least of the areas of Appendix A item 1, may then be smaller than the polygon. Without it the drawing is scaled to area | |
| tdr_rate | No | price of TDR, Rs a sq ft | |
| area_unit | No | unit of area, road_widening and reservation as the user gave them; default m2. Citiwise converts and says so in units | |
| basements | No | levels of basement, for parking and services (9.11) | |
| bathrooms | No | factories: whether bath-rooms are provided, for water (Table 12-A) | |
| jda_offer | No | share of the flats a developer has offered the landowner in a joint development, %; with the rates, gives what the developer keeps at that share beside the share the plot carries | |
| road_unit | No | unit of road and of each road side's width as the user gave them; default m | |
| sale_rate | No | sale rate, Rs a sq ft of carpet area; with build_cost and tdr_rate gives an appraisal: sales value, construction, premiums, TDR and the surplus before land | |
| build_cost | No | construction cost, Rs a sq ft of built-up area | |
| flood_zone | No | the plot lies within the blue flood line (prohibitive: no construction, no TDR) or between the blue and red flood lines (restrictive: plinth above the red flood line) (3.1.3; 11.2.8(b)) | |
| land_price | No | asking price of the land when it is being bought, Rs for the whole plot; with the rates, gives the profit at that price and how far it sits from what the land carries | |
| sprinklers | No | mixed building fully sprinklered with the travel distances kept: under the 1.3(93)(xiv) note it stays out of the special building rules up to 24 m with floors up to 750 m², subject to fire NOC | |
| steep_area | No | m² of the plot steeper than 1 in 5: hill top and hill slope land, not built upon (3.1(iii); 4.0 (XIV)) | |
| use_carpet | No | carpet area of a non-residential use, or of the shops below flats, m2, for its parking and water; default the built-up that fits | |
| buy_premium | No | false: the study is drawn without premium FSI (and without the Table 7-A higher FSI, which is taken on premium), on basic FSI, any TDR and the ancillary area; default true | |
| handed_over | No | ||
| layout_kind | No | the land is laid out into plots, or developed as a group housing scheme; returns layout: the internal road widths of Tables 3A to 3C and what the layout carries (3.3, 3.4, 2.7.2) | |
| other_costs | No | other costs (fees, finance, marketing), % of construction cost | |
| plot_origin | No | layout: sanctioned layout or sub-division; unauthorised: sub-divided after 11.01.1967 without permission; gunthewari: regularised under the Gunthewari Act | |
| prepared_by | No | who is giving the study, as it should appear on its cover, e.g. a broker or developer | |
| reservation | No | ||
| carpet_share | No | carpet area as a share of the built-up, 0.3 to 0.95 or 30 to 95 (default 0.8); sets the unit counts left out and so the sales value | |
| floor_height | No | ||
| gaothan_belt | No | a Regional Plan village plot in the agricultural zone, within the belt around the gaothan or a town where 5.1.1 permits residential development, on a premium of a share of the land's ASR rate | |
| parking_cost | No | construction cost of the stilt floor, Rs a sq ft; the stilt is free of FSI but built; default build_cost | |
| prepared_for | No | who the study is for, as it should appear on its cover, e.g. the landowner or client | |
| step_margins | No | true: step margins on upper floors (6.2.3(c)): each floor keeps the side and rear margin its own height needs, so lower floors are larger; 6 m at the ground for a special building | |
| upper_floors | No | floors above ground or stilt (G+3 is 3); omit to fit | |
| access_length | No | the plot does not abut a public street: the length of the access way to it, m, measured to the street; 'road' is then the access way's width (3.2.2, 3.3.3) | |
| avoid_special | No | true: keep the building out of the special building rules (1.3(93)(xiv)): no higher than 24 m, and for the uses the floor area reaches, each floor below 500 m² (750 m² for a sprinklered mixed building). Either way, special_choice sets the building kept out beside the special building, with what the special building brings | |
| existing_kind | No | what stands on the plot, for redevelopment (7.4, 7.5, 7.6): a co-operative society's building, a tenanted building, a MHADA scheme building redeveloped by the society or by MHADA, or a bungalow; returns schemes with the figures | |
| ground_height | No | ||
| power_line_kv | No | voltage of an overhead line near the plot, kV, for its clearance | |
| road_widening | No | ||
| allotted_basic | No | for a plot of a plotted layout, the basic FSI area in m² the layout plan allots it (3.9(iii)), up to the most the plot may receive | |
| basement_flush | No | basement top flush with the ground: it may then run into the side and rear margins (9.11.1 proviso i) | |
| slum_tenements | No | eligible hutments on the plot, for slum rehabilitation (14.6, 14.7) | |
| specified_area | No | Kolhapur: the characteristic specified area of Table 10-B (10.9.1) the plot is in, by Sr. No. ('1' for Rajarampuri) or the area's name; where the row has several plot sizes, Sr. No. and the plot row, e.g. '3.2'. Sets the Table 10-B margins and coverage and the Note 1 basic FSI. Pune: 'koregaon_park' (10.1.2). A Regional Plan area: an area of Chapter 5 with rules of its own, one of hill_station, station_near, station_far, tarapur, ratnagiri_pada, sindhudurg_t2, sindhudurg_t4, sindhudurg_t5, mp_buffer_edge, mp_buffer_gaothan, satara_core, satara_buffer, nagothane, wadi, rajpuri_usar, sector_r_lonavala, sector_r_kune, aurangabad_strip, ligo. Chapter 10 city areas, Pune: parvati_chatushrungi, arde, hemrl; Thane: ram_maruti, gokhale, express_highway, chemical_green_belt, chemical_low_density, air_force, defence_buffer, g1_yeur, g3_forest, eco_sensitive, defence_west_orange, defence_west_pink, defence_west_navy_blue, defence_west_yellow, defence_west_violet, defence_west_green, defence_east_orange, defence_east_pink, defence_east_yellow, defence_east_violet, defence_east_sky_blue; Nashik: tps1, gangapur_ambad; Vasai-Virar: low_density, eco_sensitive; Mira-Bhayandar: road_strip, manori_gorai_uttan, eco_sensitive; NMRDA: ring_road, township, gaothan_small, gaothan_large | |
| existing_carpet | No | carpet area of the existing tenements together, m² (7.4.2, 7.6) | |
| reservation_type | No | what the DP reservation on the plot is for; with 'reservation', returns accommodation_reservation: developing it by its owner under 11.1, Table 11-A | |
| existing_built_up | No | authorised built-up of the existing building, m², with its TDR and premium FSI (7.5, 7.6) | |
| existing_tenements | No | tenements in the existing building (7.4.2, 7.6) | |
| road_widening_side | No | side number (1-based) that the road widening strip comes off; default the first road side | |
| tdr_generating_rate | No | ASR land rate of the TDR's generating plot, Rs a m2 (11.2.6) | |
| internal_road_length | No | with layout_kind, the length of the longest internal road, m, from the farthest plot or building to the public street (3.3.3) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/openWorldHint=false, so the safety profile is covered; the description adds substantial value by disclosing what the tool returns (area statement, margins per side, NOCs, options, thresholds, Proforma I, premiums, TDR loading) and that each value carries its UDCPR clause. It does not discuss failure modes or validation behavior, keeping it short of 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?
The description is front-loaded well, leading with the use case and exclusions, but the returns enumeration is one enormous run-on sentence listing dozens of outputs. That detail is partly justified by the absence of an output schema, yet the density and length hurt scanability.
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 70 parameters, the description steps up to describe return contents, defaults, and conditional behaviors in depth, and it scopes the tool against Greater Mumbai and non-feasibility questions. It is nearly complete for an agent, with only sibling routing and error behavior left unaddressed.
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 90% across 70 parameters, so the schema carries nearly all parameter meaning and the baseline is 3. The description only adds cross-parameter guidance ('give the area and road as they said them with area_unit and road_unit') and language-term mapping, which is marginal against the volume of schema-documented params.
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 precise verb-and-resource scope: computing what can be built on a plot anywhere in Maharashtra outside Greater Mumbai, enumerating the specific outputs (FSI/FAR, setbacks, height, floors, parking) under UDCPR 2020. It also bounds the domain against siblings by ruling out Greater Mumbai, land prices and building permission itself, so an agent can place it 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?
It gives explicit when-to-use (someone asks what they can build on a plot) and when-not-to-use conditions (Greater Mumbai, land prices, building permission), plus handling guidance for Marathi/Hindi queries and unit passing. It does not name a specific sibling (check_design, compare_uses) as the alternative, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this to read one result of search in full: a UDCPR regulation or table in its own words as notified, what a town is under UDCPR with the figures for a common plot there, or a term in plain language with UDCPR's own definition. Returns id, title, text, url to cite, and metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | an id from search, such as udcpr/6-2-6, udcpr/table-6-g, towns/kolhapur or glossary/carpet |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety/idempotency profile is covered. The description adds that returned text is verbatim/as-notified and lists the returned fields, which is modestly useful context but no permission, rate-limit, or error 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?
The instruction is front-loaded ('Use this to read...') and the three content cases are packed into one efficient sentence, followed by a compact return-field list. Minor redundancy in spelling out three content types, but nothing extraneous.
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 a single required parameter, full schema coverage, and no output schema, the description compensates by enumerating the returned fields (id, title, text, url, metadata). An agent has enough to invoke and interpret the result; only edge behavior (missing/invalid id) is unaddressed.
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 is a single parameter at 100% schema coverage, and the schema already provides id examples (udcpr/6-2-6, towns/kolhapur, glossary/carpet). The description only loosely adds that the id originates from search, so 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 concrete operation (read one search result in full) and enumerates the three content shapes it can return: a UDCPR regulation/table, a town with plot figures, or a glossary term. This distinguishes it from sibling search tools, which return lists rather than a single full record. It stops short of a crisp verb+resource framing, but the purpose is unmistakable.
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 names the condition for use: reading one result of a search in full, which implies the caller already holds an id from search — a clear precondition. No explicit exclusions are given (e.g., when to prefer clause, towns, or search_udcpr instead), which is the only gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this to find UDCPR regulations and tables, a town's page, or what a term means, on any topic: refuge area, marginal distance on a 12 m road, Table 6-G, parking for flats, Kolhapur, what carpet area or TDR is. Returns results, each with an id to pass to fetch, a title and a url to cite.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | words, a regulation number such as 6.2.6, a table such as Table 8-B, or a town |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful behavior beyond that: it describes the result fields (id, title, url) and the workflow of passing the id to fetch and using the url for citation.
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 purpose and then moves to return details, with no filler sentences. The long list of examples is useful for a search tool, though it makes the description somewhat dense.
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 one-parameter search tool with full schema coverage, annotations, and no output schema, the description covers purpose and result shape adequately. It is incomplete for disambiguating from the sibling search_udcpr and does not mention result ranking, pagination, or retrieval limits.
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 the single query parameter and gives examples like '6.2.6' and 'Table 8-B'. The description reinforces this with more examples such as 'Table 6-G', 'Kolhapur', and 'TDR', but does not add syntax or constraints 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 clear verb ('find') and specific resources (UDCPR regulations and tables, a town's page, term meanings). It also clarifies the return shape and next step with fetch. However, it never distinguishes this tool from the close sibling search_udcpr, so it falls short of a top 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 says 'Use this to find...' and gives many illustrative query types, which implies when to use it. But it offers no explicit when-not-to-use guidance and never names alternatives such as search_udcpr, clause, or towns, leaving the agent to infer routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks where UDCPR deals with a topic, such as refuge areas or rainwater harvesting. Returns lines of UDCPR that contain all the given words, with their chapter; a regulation's own heading first.
| Name | Required | Description | Default |
|---|---|---|---|
| words | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is to add beyond that, and it does: matching requires ALL given words and results are grouped by chapter with the regulation heading first. It omits limits, case handling, and pagination 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 tight sentences, front-loaded with the usage trigger followed by the return contract; no filler. Slightly dense in the second clause, but every part carries 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?
With no output schema, the description correctly explains what comes back (lines with chapter, heading first), and it covers the trigger condition and query semantics. Minor gaps around result limits and query syntax keep it from being fully complete.
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?
With 0% schema description coverage and a bare `words` string, the description must carry the parameter burden. It adds the key semantic that the query is a multi-word AND match ("contain all the given words"), but leaves unresolved how multiple words are delimited or whether the string is a phrase.
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 specific verb and resource: search UDCPR for lines containing the given words, and it states the return shape (lines + chapter, heading first). It is clearly distinct from a generic `search`, though it never names the sibling it is not (e.g. `clause`, `fetch`) to sharpen differentiation.
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?
"Use this when someone asks where UDCPR deals with a topic" gives a concrete triggering condition with examples (refuge areas, rainwater harvesting), which is strong context. It stops short of stating when NOT to use it or which sibling to prefer for clause-level or fetch-style lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the town or planning authority of a plot is unclear or spelt differently. Returns Maharashtra towns and authorities with their kind and class; every one when no query is given.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is low. The description still adds real behavior: spelling-tolerant matching implied by 'spelt differently', and the fact that omitting the query returns the full list. It doesn't state result size or paging for the full-list case.
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?
One compact sentence that leads with the usage trigger and closes with the return behavior. Nothing superfluous, though the trailing clause 'every one when no query is given' is slightly awkwardly phrased.
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 single-parameter, read-only reference lookup with no output schema, the description covers intent, return content, and the empty-query behavior. Only the shape/size of the full-list response is left unstated, which is a minor gap.
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 0%, so the description must carry the parameter burden, and it largely does: the single 'query' parameter is optional and, when absent, the tool returns every town. It also implies fuzzy/spelling-insensitive matching. It never states the expected input form (town name string) explicitly, which keeps it from 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?
The description names a concrete resource and return payload: 'Returns Maharashtra towns and authorities with their kind and class.' That is specific enough for an agent to know this is a reference/lookup tool. It does not explicitly distinguish itself from the closest-looking siblings (search, search_udcpr), so it falls short of 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?
It gives a clear trigger condition: 'Use this when the town or planning authority of a plot is unclear or spelt differently.' This tells the agent when the tool is appropriate. It stops short of naming alternatives or when-not-to-use cases (e.g. when a precise authority id is already known), so no 5.
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.
check_design1 field changedInput schema / properties / sides / items / properties / type / enumPrevious value: -[
- "road",
- "plot",
- "open",
- "nallah",
- "river",
- "rail"
-]New value: +[
+ "road",
+ "plot",
+ "open",
+ "nallah",
+ "river",
+ "rail",
+ "shared"
+]compare_uses1 field changedInput schema / properties / sides / items / properties / type / enumPrevious value: -[
- "road",
- "plot",
- "open",
- "nallah",
- "river",
- "rail"
-]New value: +[
+ "road",
+ "plot",
+ "open",
+ "nallah",
+ "river",
+ "rail",
+ "shared"
+]draw_plot2 fields changedInput schema / properties / sides / items / properties / beyond / descriptionPrevious value: -"what lies beyond the side; plot for a neighbour"New value: +"what lies beyond the side; plot for a neighbour; shared for the common wall of a semi-detached house or row houses (Table 6-D note 4, Sr. 6)"Input schema / properties / sides / items / properties / beyond / enumPrevious value: -[
- "road",
- "plot",
- "open",
- "nallah",
- "river",
- "rail"
-]New value: +[
+ "road",
+ "plot",
+ "open",
+ "nallah",
+ "river",
+ "rail",
+ "shared"
+]feasibility1 field changedInput schema / properties / sides / items / properties / type / enumPrevious value: -[
- "road",
- "plot",
- "open",
- "nallah",
- "river",
- "rail"
-]New value: +[
+ "road",
+ "plot",
+ "open",
+ "nallah",
+ "river",
+ "rail",
+ "shared"
+]check_design4 fields changedInput schema / properties / allotted_basicAdded value: +{
+ "description": "for a plot of a plotted layout, the basic FSI area in m² the layout plan allots it (3.9(iii)), up to the most the plot may receive",
+ "type": "number"
+}Input schema / properties / greenAdded value: +{
+ "description": "green rating committed (IGBC / GRIHA / LEED tier) for the incentive FSI of 7.10 on basic FSI: 3%, 5% or 7%",
+ "enum": [
+ "silver",
+ "gold",
+ "platinum"
+ ],
+ "type": "string"
+}Input schema / properties / steep_areaAdded value: +{
+ "description": "m² of the plot steeper than 1 in 5: hill top and hill slope land, not built upon (3.1(iii); 4.0 (XIV))",
+ "type": "number"
+}Input schema / properties / step_marginsAdded value: +{
+ "description": "true: step margins on upper floors (6.2.3(c)): each floor keeps the side and rear margin its own height needs, so lower floors are larger; 6 m at the ground for a special building",
+ "type": "boolean"
+}compare_uses4 fields changedInput schema / properties / allotted_basicAdded value: +{
+ "description": "for a plot of a plotted layout, the basic FSI area in m² the layout plan allots it (3.9(iii)), up to the most the plot may receive",
+ "type": "number"
+}Input schema / properties / greenAdded value: +{
+ "description": "green rating committed (IGBC / GRIHA / LEED tier) for the incentive FSI of 7.10 on basic FSI: 3%, 5% or 7%",
+ "enum": [
+ "silver",
+ "gold",
+ "platinum"
+ ],
+ "type": "string"
+}Input schema / properties / steep_areaAdded value: +{
+ "description": "m² of the plot steeper than 1 in 5: hill top and hill slope land, not built upon (3.1(iii); 4.0 (XIV))",
+ "type": "number"
+}Input schema / properties / step_marginsAdded value: +{
+ "description": "true: step margins on upper floors (6.2.3(c)): each floor keeps the side and rear margin its own height needs, so lower floors are larger; 6 m at the ground for a special building",
+ "type": "boolean"
+}feasibility4 fields changedInput schema / properties / allotted_basicAdded value: +{
+ "description": "for a plot of a plotted layout, the basic FSI area in m² the layout plan allots it (3.9(iii)), up to the most the plot may receive",
+ "type": "number"
+}Input schema / properties / greenAdded value: +{
+ "description": "green rating committed (IGBC / GRIHA / LEED tier) for the incentive FSI of 7.10 on basic FSI: 3%, 5% or 7%",
+ "enum": [
+ "silver",
+ "gold",
+ "platinum"
+ ],
+ "type": "string"
+}Input schema / properties / steep_areaAdded value: +{
+ "description": "m² of the plot steeper than 1 in 5: hill top and hill slope land, not built upon (3.1(iii); 4.0 (XIV))",
+ "type": "number"
+}Input schema / properties / step_marginsAdded value: +{
+ "description": "true: step margins on upper floors (6.2.3(c)): each floor keeps the side and rear margin its own height needs, so lower floors are larger; 6 m at the ground for a special building",
+ "type": "boolean"
+}check_design1 field changedInput schema / properties / buy_premiumAdded value: +{
+ "description": "false: the study is drawn without premium FSI (and without the Table 7-A higher FSI, which is taken on premium), on basic FSI, any TDR and the ancillary area; default true",
+ "type": "boolean"
+}compare_uses1 field changedInput schema / properties / buy_premiumAdded value: +{
+ "description": "false: the study is drawn without premium FSI (and without the Table 7-A higher FSI, which is taken on premium), on basic FSI, any TDR and the ancillary area; default true",
+ "type": "boolean"
+}draw_plot12 fields changedInput schema / properties / angles / descriptionPrevious value: -"interior angle in degrees at each corner; corner i is where side i begins"New value: +"interior angle in degrees at each corner; corner i is where side i begins; null where not measured"Input schema / properties / angles / items / typePrevious value: -"number"New value: +[
+ "number",
+ "string",
+ "null"
+]Input schema / properties / area_unitAdded value: +{
+ "description": "unit of stated_area when it is a bare number; default m2 (sq ft with unit ft); hr is hectare-are as on a 7/12",
+ "enum": [
+ "m2",
+ "sqft",
+ "guntha",
+ "acre",
+ "hectare",
+ "hr"
+ ],
+ "type": "string"
+}Input schema / properties / diagonals / items / properties / length / typePrevious value: -"number"New value: +[
+ "number",
+ "string"
+]Input schema / properties / sides / items / properties / length / descriptionPrevious value: -"length of the side, in the unit given"New value: +"length of the side as written: a number in the unit given, or text such as 40'6\" or 12.20 m; null for a side not measured, where angles or diagonals fix it"Input schema / properties / sides / items / properties / length / typePrevious value: -"number"New value: +[
+ "number",
+ "string",
+ "null"
+]Input schema / properties / sides / items / properties / width / descriptionPrevious value: -"for a road: its width, in the unit given"New value: +"for a road: its width, in the unit given or as text such as 30' or 9 m"Input schema / properties / sides / items / properties / width / typePrevious value: -"number"New value: +[
+ "number",
+ "string"
+]Input schema / properties / sides / items / requiredRemoved value: -[
- "length"
-]Input schema / properties / stated_area / descriptionPrevious value: -"the area on the 7/12 or measurement sheet, in m2 (or sq ft with unit ft), to check against"New value: +"the area on the 7/12, property card or measurement sheet, to check against, as written: 5 guntha, 0.12.50 H.R., 5400 sq ft"Input schema / properties / stated_area / typePrevious value: -"number"New value: +[
+ "number",
+ "string"
+]Input schema / properties / unit / descriptionPrevious value: -"unit of every length and road width; default m"New value: +"unit of every bare number among the lengths and road widths; default m"feasibility1 field changedInput schema / properties / buy_premiumAdded value: +{
+ "description": "false: the study is drawn without premium FSI (and without the Table 7-A higher FSI, which is taken on premium), on basic FSI, any TDR and the ancillary area; default true",
+ "type": "boolean"
+}check_design2 fields changedInput schema / properties / avoid_specialAdded value: +{
+ "description": "true: keep the building out of the special building rules (1.3(93)(xiv)): no higher than 24 m, and for the uses the floor area reaches, each floor below 500 m² (750 m² for a sprinklered mixed building). Either way, special_choice sets the building kept out beside the special building, with what the special building brings",
+ "type": "boolean"
+}Input schema / properties / sprinklers / descriptionPrevious value: -"mixed building fully sprinklered (1.3(93)(xiv) note)"New value: +"mixed building fully sprinklered with the travel distances kept: under the 1.3(93)(xiv) note it stays out of the special building rules up to 24 m with floors up to 750 m², subject to fire NOC"compare_uses2 fields changedInput schema / properties / avoid_specialAdded value: +{
+ "description": "true: keep the building out of the special building rules (1.3(93)(xiv)): no higher than 24 m, and for the uses the floor area reaches, each floor below 500 m² (750 m² for a sprinklered mixed building). Either way, special_choice sets the building kept out beside the special building, with what the special building brings",
+ "type": "boolean"
+}Input schema / properties / sprinklers / descriptionPrevious value: -"mixed building fully sprinklered (1.3(93)(xiv) note)"New value: +"mixed building fully sprinklered with the travel distances kept: under the 1.3(93)(xiv) note it stays out of the special building rules up to 24 m with floors up to 750 m², subject to fire NOC"feasibility2 fields changedInput schema / properties / avoid_specialAdded value: +{
+ "description": "true: keep the building out of the special building rules (1.3(93)(xiv)): no higher than 24 m, and for the uses the floor area reaches, each floor below 500 m² (750 m² for a sprinklered mixed building). Either way, special_choice sets the building kept out beside the special building, with what the special building brings",
+ "type": "boolean"
+}Input schema / properties / sprinklers / descriptionPrevious value: -"mixed building fully sprinklered (1.3(93)(xiv) note)"New value: +"mixed building fully sprinklered with the travel distances kept: under the 1.3(93)(xiv) note it stays out of the special building rules up to 24 m with floors up to 750 m², subject to fire NOC"check_design2 fields changedInput schema / properties / areasAdded value: +{
+ "description": "the three areas of Appendix A item 1, in m2, for the area statement: ownership (the 7/12 or property card), sheet (the measurement sheet of the Land Records) and site (by the measurements); area is the least of those given",
+ "properties": {
+ "ownership": {
+ "type": "number"
+ },
+ "sheet": {
+ "type": "number"
+ },
+ "site": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+}Input schema / properties / measuredAdded value: +{
+ "description": "true: the polygon is the plot as measured on site (draw_plot gives it so), drawn as it is; area, the least of the areas of Appendix A item 1, may then be smaller than the polygon. Without it the drawing is scaled to area",
+ "type": "boolean"
+}compare_uses2 fields changedInput schema / properties / areasAdded value: +{
+ "description": "the three areas of Appendix A item 1, in m2, for the area statement: ownership (the 7/12 or property card), sheet (the measurement sheet of the Land Records) and site (by the measurements); area is the least of those given",
+ "properties": {
+ "ownership": {
+ "type": "number"
+ },
+ "sheet": {
+ "type": "number"
+ },
+ "site": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+}Input schema / properties / measuredAdded value: +{
+ "description": "true: the polygon is the plot as measured on site (draw_plot gives it so), drawn as it is; area, the least of the areas of Appendix A item 1, may then be smaller than the polygon. Without it the drawing is scaled to area",
+ "type": "boolean"
+}feasibility2 fields changedInput schema / properties / areasAdded value: +{
+ "description": "the three areas of Appendix A item 1, in m2, for the area statement: ownership (the 7/12 or property card), sheet (the measurement sheet of the Land Records) and site (by the measurements); area is the least of those given",
+ "properties": {
+ "ownership": {
+ "type": "number"
+ },
+ "sheet": {
+ "type": "number"
+ },
+ "site": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+}Input schema / properties / measuredAdded value: +{
+ "description": "true: the polygon is the plot as measured on site (draw_plot gives it so), drawn as it is; area, the least of the areas of Appendix A item 1, may then be smaller than the polygon. Without it the drawing is scaled to area",
+ "type": "boolean"
+}check_design2 fields changedInput schema / properties / land_price / descriptionPrevious value: -"asking price of the land when it is being bought, Rs for the whole plot; with the rates, gives the profit at that price and how far it sits from the most to pay for the land"New value: +"asking price of the land when it is being bought, Rs for the whole plot; with the rates, gives the profit at that price and how far it sits from what the land carries"Input schema / properties / margin / descriptionPrevious value: -"margin the developer needs, % of sales value; with the rates, gives the most to pay for the land and the largest share of the flats for the landowner in a joint development"New value: +"margin the developer needs, % of sales value; with the rates, gives what the land carries and the largest share of the flats for the landowner in a joint development"compare_uses2 fields changedInput schema / properties / land_price / descriptionPrevious value: -"asking price of the land when it is being bought, Rs for the whole plot; with the rates, gives the profit at that price and how far it sits from the most to pay for the land"New value: +"asking price of the land when it is being bought, Rs for the whole plot; with the rates, gives the profit at that price and how far it sits from what the land carries"Input schema / properties / margin / descriptionPrevious value: -"margin the developer needs, % of sales value; with the rates, gives the most to pay for the land and the largest share of the flats for the landowner in a joint development"New value: +"margin the developer needs, % of sales value; with the rates, gives what the land carries and the largest share of the flats for the landowner in a joint development"feasibility2 fields changedInput schema / properties / land_price / descriptionPrevious value: -"asking price of the land when it is being bought, Rs for the whole plot; with the rates, gives the profit at that price and how far it sits from the most to pay for the land"New value: +"asking price of the land when it is being bought, Rs for the whole plot; with the rates, gives the profit at that price and how far it sits from what the land carries"Input schema / properties / margin / descriptionPrevious value: -"margin the developer needs, % of sales value; with the rates, gives the most to pay for the land and the largest share of the flats for the landowner in a joint development"New value: +"margin the developer needs, % of sales value; with the rates, gives what the land carries and the largest share of the flats for the landowner in a joint development"check_design1 field changedInput schema / properties / buy_tdrAdded value: +{
+ "description": "false: the study is drawn without buying TDR, on basic and premium FSI with their ancillary area; default true. Either way, tdr_choice sets both side by side, with the most TDR is worth to this plot when sale_rate and build_cost are given",
+ "type": "boolean"
+}compare_uses1 field changedInput schema / properties / buy_tdrAdded value: +{
+ "description": "false: the study is drawn without buying TDR, on basic and premium FSI with their ancillary area; default true. Either way, tdr_choice sets both side by side, with the most TDR is worth to this plot when sale_rate and build_cost are given",
+ "type": "boolean"
+}feasibility1 field changedInput schema / properties / buy_tdrAdded value: +{
+ "description": "false: the study is drawn without buying TDR, on basic and premium FSI with their ancillary area; default true. Either way, tdr_choice sets both side by side, with the most TDR is worth to this plot when sale_rate and build_cost are given",
+ "type": "boolean"
+}check_design1 field changedInput schema / properties / slum_tenementsAdded value: +{
+ "description": "eligible hutments on the plot, for slum rehabilitation (14.6, 14.7)",
+ "type": "integer"
+}compare_uses1 field changedInput schema / properties / slum_tenementsAdded value: +{
+ "description": "eligible hutments on the plot, for slum rehabilitation (14.6, 14.7)",
+ "type": "integer"
+}feasibility1 field changedInput schema / properties / slum_tenementsAdded value: +{
+ "description": "eligible hutments on the plot, for slum rehabilitation (14.6, 14.7)",
+ "type": "integer"
+}check_design6 fields changedInput schema / properties / existing_built_upAdded value: +{
+ "description": "authorised built-up of the existing building, m², with its TDR and premium FSI (7.5, 7.6)",
+ "type": "number"
+}Input schema / properties / existing_carpetAdded value: +{
+ "description": "carpet area of the existing tenements together, m² (7.4.2, 7.6)",
+ "type": "number"
+}Input schema / properties / existing_kindAdded value: +{
+ "description": "what stands on the plot, for redevelopment (7.4, 7.5, 7.6): a co-operative society's building, a tenanted building, a MHADA scheme building redeveloped by the society or by MHADA, or a bungalow; returns schemes with the figures",
+ "enum": [
+ "society",
+ "tenanted",
+ "mhada_society",
+ "mhada",
+ "bungalow"
+ ],
+ "type": "string"
+}Input schema / properties / existing_tenementsAdded value: +{
+ "description": "tenements in the existing building (7.4.2, 7.6)",
+ "type": "integer"
+}Input schema / properties / rc_rateAdded value: +{
+ "description": "the ASR rate of RCC construction, Rs a m², for the land rate to construction rate ratio of Tables 7-C to 7-E",
+ "type": "number"
+}Input schema / properties / specified_area / descriptionPrevious value: -"Kolhapur: the characteristic specified area of Table 10-B (10.9.1) the plot is in, by Sr. No. ('1' for Rajarampuri) or the area's name; where the row has several plot sizes, Sr. No. and the plot row, e.g. '3.2'. Sets the Table 10-B margins and coverage and the Note 1 basic FSI. Pune: 'koregaon_park' (10.1.2). A Regional Plan area: an area of Chapter 5 with rules of its own, one of hill_station, station_near, station_far, tarapur, ratnagiri_pada, sindhudurg_t2, sindhudurg_t4, sindhudurg_t5, mp_buffer_edge, mp_buffer_gaothan, satara_core, satara_buffer, nagothane, wadi, rajpuri_usar, sector_r_lonavala, sector_r_kune, aurangabad_strip, ligo"New value: +"Kolhapur: the characteristic specified area of Table 10-B (10.9.1) the plot is in, by Sr. No. ('1' for Rajarampuri) or the area's name; where the row has several plot sizes, Sr. No. and the plot row, e.g. '3.2'. Sets the Table 10-B margins and coverage and the Note 1 basic FSI. Pune: 'koregaon_park' (10.1.2). A Regional Plan area: an area of Chapter 5 with rules of its own, one of hill_station, station_near, station_far, tarapur, ratnagiri_pada, sindhudurg_t2, sindhudurg_t4, sindhudurg_t5, mp_buffer_edge, mp_buffer_gaothan, satara_core, satara_buffer, nagothane, wadi, rajpuri_usar, sector_r_lonavala, sector_r_kune, aurangabad_strip, ligo. Chapter 10 city areas, Pune: parvati_chatushrungi, arde, hemrl; Thane: ram_maruti, gokhale, express_highway, chemical_green_belt, chemical_low_density, air_force, defence_buffer, g1_yeur, g3_forest, eco_sensitive, defence_west_orange, defence_west_pink, defence_west_navy_blue, defence_west_yellow, defence_west_violet, defence_west_green, defence_east_orange, defence_east_pink, defence_east_yellow, defence_east_violet, defence_east_sky_blue; Nashik: tps1, gangapur_ambad; Vasai-Virar: low_density, eco_sensitive; Mira-Bhayandar: road_strip, manori_gorai_uttan, eco_sensitive; NMRDA: ring_road, township, gaothan_small, gaothan_large"compare_uses6 fields changedInput schema / properties / existing_built_upAdded value: +{
+ "description": "authorised built-up of the existing building, m², with its TDR and premium FSI (7.5, 7.6)",
+ "type": "number"
+}Input schema / properties / existing_carpetAdded value: +{
+ "description": "carpet area of the existing tenements together, m² (7.4.2, 7.6)",
+ "type": "number"
+}Input schema / properties / existing_kindAdded value: +{
+ "description": "what stands on the plot, for redevelopment (7.4, 7.5, 7.6): a co-operative society's building, a tenanted building, a MHADA scheme building redeveloped by the society or by MHADA, or a bungalow; returns schemes with the figures",
+ "enum": [
+ "society",
+ "tenanted",
+ "mhada_society",
+ "mhada",
+ "bungalow"
+ ],
+ "type": "string"
+}Input schema / properties / existing_tenementsAdded value: +{
+ "description": "tenements in the existing building (7.4.2, 7.6)",
+ "type": "integer"
+}Input schema / properties / rc_rateAdded value: +{
+ "description": "the ASR rate of RCC construction, Rs a m², for the land rate to construction rate ratio of Tables 7-C to 7-E",
+ "type": "number"
+}Input schema / properties / specified_area / descriptionPrevious value: -"Kolhapur: the characteristic specified area of Table 10-B (10.9.1) the plot is in, by Sr. No. ('1' for Rajarampuri) or the area's name; where the row has several plot sizes, Sr. No. and the plot row, e.g. '3.2'. Sets the Table 10-B margins and coverage and the Note 1 basic FSI. Pune: 'koregaon_park' (10.1.2). A Regional Plan area: an area of Chapter 5 with rules of its own, one of hill_station, station_near, station_far, tarapur, ratnagiri_pada, sindhudurg_t2, sindhudurg_t4, sindhudurg_t5, mp_buffer_edge, mp_buffer_gaothan, satara_core, satara_buffer, nagothane, wadi, rajpuri_usar, sector_r_lonavala, sector_r_kune, aurangabad_strip, ligo"New value: +"Kolhapur: the characteristic specified area of Table 10-B (10.9.1) the plot is in, by Sr. No. ('1' for Rajarampuri) or the area's name; where the row has several plot sizes, Sr. No. and the plot row, e.g. '3.2'. Sets the Table 10-B margins and coverage and the Note 1 basic FSI. Pune: 'koregaon_park' (10.1.2). A Regional Plan area: an area of Chapter 5 with rules of its own, one of hill_station, station_near, station_far, tarapur, ratnagiri_pada, sindhudurg_t2, sindhudurg_t4, sindhudurg_t5, mp_buffer_edge, mp_buffer_gaothan, satara_core, satara_buffer, nagothane, wadi, rajpuri_usar, sector_r_lonavala, sector_r_kune, aurangabad_strip, ligo. Chapter 10 city areas, Pune: parvati_chatushrungi, arde, hemrl; Thane: ram_maruti, gokhale, express_highway, chemical_green_belt, chemical_low_density, air_force, defence_buffer, g1_yeur, g3_forest, eco_sensitive, defence_west_orange, defence_west_pink, defence_west_navy_blue, defence_west_yellow, defence_west_violet, defence_west_green, defence_east_orange, defence_east_pink, defence_east_yellow, defence_east_violet, defence_east_sky_blue; Nashik: tps1, gangapur_ambad; Vasai-Virar: low_density, eco_sensitive; Mira-Bhayandar: road_strip, manori_gorai_uttan, eco_sensitive; NMRDA: ring_road, township, gaothan_small, gaothan_large"feasibility6 fields changedInput schema / properties / existing_built_upAdded value: +{
+ "description": "authorised built-up of the existing building, m², with its TDR and premium FSI (7.5, 7.6)",
+ "type": "number"
+}Input schema / properties / existing_carpetAdded value: +{
+ "description": "carpet area of the existing tenements together, m² (7.4.2, 7.6)",
+ "type": "number"
+}Input schema / properties / existing_kindAdded value: +{
+ "description": "what stands on the plot, for redevelopment (7.4, 7.5, 7.6): a co-operative society's building, a tenanted building, a MHADA scheme building redeveloped by the society or by MHADA, or a bungalow; returns schemes with the figures",
+ "enum": [
+ "society",
+ "tenanted",
+ "mhada_society",
+ "mhada",
+ "bungalow"
+ ],
+ "type": "string"
+}Input schema / properties / existing_tenementsAdded value: +{
+ "description": "tenements in the existing building (7.4.2, 7.6)",
+ "type": "integer"
+}Input schema / properties / rc_rateAdded value: +{
+ "description": "the ASR rate of RCC construction, Rs a m², for the land rate to construction rate ratio of Tables 7-C to 7-E",
+ "type": "number"
+}Input schema / properties / specified_area / descriptionPrevious value: -"Kolhapur: the characteristic specified area of Table 10-B (10.9.1) the plot is in, by Sr. No. ('1' for Rajarampuri) or the area's name; where the row has several plot sizes, Sr. No. and the plot row, e.g. '3.2'. Sets the Table 10-B margins and coverage and the Note 1 basic FSI. Pune: 'koregaon_park' (10.1.2). A Regional Plan area: an area of Chapter 5 with rules of its own, one of hill_station, station_near, station_far, tarapur, ratnagiri_pada, sindhudurg_t2, sindhudurg_t4, sindhudurg_t5, mp_buffer_edge, mp_buffer_gaothan, satara_core, satara_buffer, nagothane, wadi, rajpuri_usar, sector_r_lonavala, sector_r_kune, aurangabad_strip, ligo"New value: +"Kolhapur: the characteristic specified area of Table 10-B (10.9.1) the plot is in, by Sr. No. ('1' for Rajarampuri) or the area's name; where the row has several plot sizes, Sr. No. and the plot row, e.g. '3.2'. Sets the Table 10-B margins and coverage and the Note 1 basic FSI. Pune: 'koregaon_park' (10.1.2). A Regional Plan area: an area of Chapter 5 with rules of its own, one of hill_station, station_near, station_far, tarapur, ratnagiri_pada, sindhudurg_t2, sindhudurg_t4, sindhudurg_t5, mp_buffer_edge, mp_buffer_gaothan, satara_core, satara_buffer, nagothane, wadi, rajpuri_usar, sector_r_lonavala, sector_r_kune, aurangabad_strip, ligo. Chapter 10 city areas, Pune: parvati_chatushrungi, arde, hemrl; Thane: ram_maruti, gokhale, express_highway, chemical_green_belt, chemical_low_density, air_force, defence_buffer, g1_yeur, g3_forest, eco_sensitive, defence_west_orange, defence_west_pink, defence_west_navy_blue, defence_west_yellow, defence_west_violet, defence_west_green, defence_east_orange, defence_east_pink, defence_east_yellow, defence_east_violet, defence_east_sky_blue; Nashik: tps1, gangapur_ambad; Vasai-Virar: low_density, eco_sensitive; Mira-Bhayandar: road_strip, manori_gorai_uttan, eco_sensitive; NMRDA: ring_road, township, gaothan_small, gaothan_large"check_design4 fields changedInput schema / properties / access_lengthAdded value: +{
+ "description": "the plot does not abut a public street: the length of the access way to it, m, measured to the street; 'road' is then the access way's width (3.2.2, 3.3.3)",
+ "type": "number"
+}Input schema / properties / internal_road_lengthAdded value: +{
+ "description": "with layout_kind, the length of the longest internal road, m, from the farthest plot or building to the public street (3.3.3)",
+ "type": "number"
+}Input schema / properties / layout_kindAdded value: +{
+ "description": "the land is laid out into plots, or developed as a group housing scheme; returns layout: the internal road widths of Tables 3A to 3C and what the layout carries (3.3, 3.4, 2.7.2)",
+ "enum": [
+ "plots",
+ "group_housing"
+ ],
+ "type": "string"
+}Input schema / properties / specified_area / descriptionPrevious value: -"Kolhapur: the characteristic specified area of Table 10-B (10.9.1) the plot is in, by Sr. No. ('1' for Rajarampuri) or the area's name; where the row has several plot sizes, Sr. No. and the plot row, e.g. '3.2'. Sets the Table 10-B margins and coverage and the Note 1 basic FSI. Pune: 'koregaon_park' (10.1.2)"New value: +"Kolhapur: the characteristic specified area of Table 10-B (10.9.1) the plot is in, by Sr. No. ('1' for Rajarampuri) or the area's name; where the row has several plot sizes, Sr. No. and the plot row, e.g. '3.2'. Sets the Table 10-B margins and coverage and the Note 1 basic FSI. Pune: 'koregaon_park' (10.1.2). A Regional Plan area: an area of Chapter 5 with rules of its own, one of hill_station, station_near, station_far, tarapur, ratnagiri_pada, sindhudurg_t2, sindhudurg_t4, sindhudurg_t5, mp_buffer_edge, mp_buffer_gaothan, satara_core, satara_buffer, nagothane, wadi, rajpuri_usar, sector_r_lonavala, sector_r_kune, aurangabad_strip, ligo"compare_uses4 fields changedInput schema / properties / access_lengthAdded value: +{
+ "description": "the plot does not abut a public street: the length of the access way to it, m, measured to the street; 'road' is then the access way's width (3.2.2, 3.3.3)",
+ "type": "number"
+}Input schema / properties / internal_road_lengthAdded value: +{
+ "description": "with layout_kind, the length of the longest internal road, m, from the farthest plot or building to the public street (3.3.3)",
+ "type": "number"
+}Input schema / properties / layout_kindAdded value: +{
+ "description": "the land is laid out into plots, or developed as a group housing scheme; returns layout: the internal road widths of Tables 3A to 3C and what the layout carries (3.3, 3.4, 2.7.2)",
+ "enum": [
+ "plots",
+ "group_housing"
+ ],
+ "type": "string"
+}Input schema / properties / specified_area / descriptionPrevious value: -"Kolhapur: the characteristic specified area of Table 10-B (10.9.1) the plot is in, by Sr. No. ('1' for Rajarampuri) or the area's name; where the row has several plot sizes, Sr. No. and the plot row, e.g. '3.2'. Sets the Table 10-B margins and coverage and the Note 1 basic FSI. Pune: 'koregaon_park' (10.1.2)"New value: +"Kolhapur: the characteristic specified area of Table 10-B (10.9.1) the plot is in, by Sr. No. ('1' for Rajarampuri) or the area's name; where the row has several plot sizes, Sr. No. and the plot row, e.g. '3.2'. Sets the Table 10-B margins and coverage and the Note 1 basic FSI. Pune: 'koregaon_park' (10.1.2). A Regional Plan area: an area of Chapter 5 with rules of its own, one of hill_station, station_near, station_far, tarapur, ratnagiri_pada, sindhudurg_t2, sindhudurg_t4, sindhudurg_t5, mp_buffer_edge, mp_buffer_gaothan, satara_core, satara_buffer, nagothane, wadi, rajpuri_usar, sector_r_lonavala, sector_r_kune, aurangabad_strip, ligo"feasibility4 fields changedInput schema / properties / access_lengthAdded value: +{
+ "description": "the plot does not abut a public street: the length of the access way to it, m, measured to the street; 'road' is then the access way's width (3.2.2, 3.3.3)",
+ "type": "number"
+}Input schema / properties / internal_road_lengthAdded value: +{
+ "description": "with layout_kind, the length of the longest internal road, m, from the farthest plot or building to the public street (3.3.3)",
+ "type": "number"
+}Input schema / properties / layout_kindAdded value: +{
+ "description": "the land is laid out into plots, or developed as a group housing scheme; returns layout: the internal road widths of Tables 3A to 3C and what the layout carries (3.3, 3.4, 2.7.2)",
+ "enum": [
+ "plots",
+ "group_housing"
+ ],
+ "type": "string"
+}Input schema / properties / specified_area / descriptionPrevious value: -"Kolhapur: the characteristic specified area of Table 10-B (10.9.1) the plot is in, by Sr. No. ('1' for Rajarampuri) or the area's name; where the row has several plot sizes, Sr. No. and the plot row, e.g. '3.2'. Sets the Table 10-B margins and coverage and the Note 1 basic FSI. Pune: 'koregaon_park' (10.1.2)"New value: +"Kolhapur: the characteristic specified area of Table 10-B (10.9.1) the plot is in, by Sr. No. ('1' for Rajarampuri) or the area's name; where the row has several plot sizes, Sr. No. and the plot row, e.g. '3.2'. Sets the Table 10-B margins and coverage and the Note 1 basic FSI. Pune: 'koregaon_park' (10.1.2). A Regional Plan area: an area of Chapter 5 with rules of its own, one of hill_station, station_near, station_far, tarapur, ratnagiri_pada, sindhudurg_t2, sindhudurg_t4, sindhudurg_t5, mp_buffer_edge, mp_buffer_gaothan, satara_core, satara_buffer, nagothane, wadi, rajpuri_usar, sector_r_lonavala, sector_r_kune, aurangabad_strip, ligo"check_design2 fields changedInput schema / properties / land_use / descriptionAdded value: +"the zone on the development or regional plan: residential, commercial, industrial, public / semi-public, agricultural, transport, green belt, loom industry cum residential (4.9), regional park (4.14), tourism development (4.15), afforestation (4.16), hill top (4.17), green zone 2 (4.18), forest, defence, mines and quarry, public utility, woodland corridor, special economic zone, airport (4.19 to 4.25)"Input schema / properties / land_use / enumPrevious value: -[
- "res",
- "com",
- "ind",
- "psp",
- "agr",
- "tt",
- "gb"
-]New value: +[
+ "res",
+ "com",
+ "ind",
+ "psp",
+ "agr",
+ "tt",
+ "gb",
+ "loom",
+ "park",
+ "tourism",
+ "afforest",
+ "hilltop",
+ "green2",
+ "forest",
+ "defence",
+ "mines",
+ "utility",
+ "woodland",
+ "sez",
+ "airport"
+]compare_uses2 fields changedInput schema / properties / land_use / descriptionAdded value: +"the zone on the development or regional plan: residential, commercial, industrial, public / semi-public, agricultural, transport, green belt, loom industry cum residential (4.9), regional park (4.14), tourism development (4.15), afforestation (4.16), hill top (4.17), green zone 2 (4.18), forest, defence, mines and quarry, public utility, woodland corridor, special economic zone, airport (4.19 to 4.25)"Input schema / properties / land_use / enumPrevious value: -[
- "res",
- "com",
- "ind",
- "psp",
- "agr",
- "tt",
- "gb"
-]New value: +[
+ "res",
+ "com",
+ "ind",
+ "psp",
+ "agr",
+ "tt",
+ "gb",
+ "loom",
+ "park",
+ "tourism",
+ "afforest",
+ "hilltop",
+ "green2",
+ "forest",
+ "defence",
+ "mines",
+ "utility",
+ "woodland",
+ "sez",
+ "airport"
+]feasibility2 fields changedInput schema / properties / land_use / descriptionAdded value: +"the zone on the development or regional plan: residential, commercial, industrial, public / semi-public, agricultural, transport, green belt, loom industry cum residential (4.9), regional park (4.14), tourism development (4.15), afforestation (4.16), hill top (4.17), green zone 2 (4.18), forest, defence, mines and quarry, public utility, woodland corridor, special economic zone, airport (4.19 to 4.25)"Input schema / properties / land_use / enumPrevious value: -[
- "res",
- "com",
- "ind",
- "psp",
- "agr",
- "tt",
- "gb"
-]New value: +[
+ "res",
+ "com",
+ "ind",
+ "psp",
+ "agr",
+ "tt",
+ "gb",
+ "loom",
+ "park",
+ "tourism",
+ "afforest",
+ "hilltop",
+ "green2",
+ "forest",
+ "defence",
+ "mines",
+ "utility",
+ "woodland",
+ "sez",
+ "airport"
+]check_design12 fields changedInput schema / properties / crzAdded value: +{
+ "description": "the coastal regulation zone the plot is in: I (between the tide lines), II, or III within its No Development Zone. No TDR in the coastal zone (11.2.8(c)); development as the CRZ Notification allows (1.6(i))",
+ "enum": [
+ "I",
+ "II",
+ "III"
+ ],
+ "type": "string"
+}Input schema / properties / flood_zoneAdded value: +{
+ "description": "the plot lies within the blue flood line (prohibitive: no construction, no TDR) or between the blue and red flood lines (restrictive: plinth above the red flood line) (3.1.3; 11.2.8(b))",
+ "enum": [
+ "prohibitive",
+ "restrictive"
+ ],
+ "type": "string"
+}Input schema / properties / gaothan_beltAdded value: +{
+ "description": "a Regional Plan village plot in the agricultural zone, within the belt around the gaothan or a town where 5.1.1 permits residential development, on a premium of a share of the land's ASR rate",
+ "type": "boolean"
+}Input schema / properties / jda_offerAdded value: +{
+ "description": "share of the flats a developer has offered the landowner in a joint development, %; with the rates, gives what the developer keeps at that share beside the share the plot carries",
+ "type": "number"
+}Input schema / properties / land_priceAdded value: +{
+ "description": "asking price of the land when it is being bought, Rs for the whole plot; with the rates, gives the profit at that price and how far it sits from the most to pay for the land",
+ "type": "number"
+}Input schema / properties / papersAdded value: +{
+ "description": "the papers the facts were read from, when they were: 712 (the 7/12 extract or property card, for the area), sheet (the measurement sheet, for the sides and area), zone (the zone certificate or DP remark, for the zone, the road width, road widening and reservations), layout (the sanctioned layout or regularisation order). The study marks each fact as read from its paper or as told; no rule reads them",
+ "items": {
+ "enum": [
+ "712",
+ "sheet",
+ "zone",
+ "layout"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / reservation_typeAdded value: +{
+ "description": "what the DP reservation on the plot is for; with 'reservation', returns accommodation_reservation: developing it by its owner under 11.1, Table 11-A",
+ "enum": [
+ "recreational",
+ "education",
+ "commercial",
+ "health",
+ "transport",
+ "bus_stand",
+ "truck_terminus",
+ "residential",
+ "assembly",
+ "psp",
+ "other"
+ ],
+ "type": "string"
+}Input schema / properties / specified_areaAdded value: +{
+ "description": "Kolhapur: the characteristic specified area of Table 10-B (10.9.1) the plot is in, by Sr. No. ('1' for Rajarampuri) or the area's name; where the row has several plot sizes, Sr. No. and the plot row, e.g. '3.2'. Sets the Table 10-B margins and coverage and the Note 1 basic FSI. Pune: 'koregaon_park' (10.1.2)",
+ "type": "string"
+}Input schema / properties / tod / descriptionPrevious value: -"plot inside a TOD zone (14.2.1)"New value: +"plot inside a TOD zone (14.2): Municipal Corporations, metropolitan authorities and CIDCO; the Nagpur Metro Rail Corridor by Table 14-P"Input schema / properties / units / items / properties / per_floorAdded value: +{
+ "description": "instead of count: units of this type on each typical floor, 0 to 200, repeated on every floor that carries units",
+ "type": "integer"
+}Input schema / properties / units / items / properties / share_of_unitsAdded value: +{
+ "description": "with count left out: this type's share of the units, as a developer gives a mix (60 for 60% 2 BHK), 0 to 1 or a percentage; the number of units is worked out from the building",
+ "type": "number"
+}Input schema / properties / wingsAdded value: +{
+ "description": "a group housing project as wings, each with its own typical floor and floors; units then gives each type and its carpet only. Returns each wing's height, lifts, special building and the distance between wings (6.2.4), and the built-up the wings need against what the rules allow",
+ "items": {
+ "properties": {
+ "floors": {
+ "description": "floors of this wing that carry units, 1 to 60; left out, those of the building that fits",
+ "type": "integer"
+ },
+ "name": {
+ "description": "the wing's name, up to 12 characters: A, B, Tower 1",
+ "type": "string"
+ },
+ "units": {
+ "items": {
+ "properties": {
+ "per_floor": {
+ "description": "units of that type on this wing's typical floor, 0 to 200",
+ "type": "integer"
+ },
+ "type": {
+ "description": "one of the types in units",
+ "type": "string"
+ }
+ },
+ "required": [
+ "type",
+ "per_floor"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "name",
+ "units"
+ ],
+ "type": "object"
+ },
+ "maxItems": 12,
+ "type": "array"
+}compare_uses12 fields changedInput schema / properties / crzAdded value: +{
+ "description": "the coastal regulation zone the plot is in: I (between the tide lines), II, or III within its No Development Zone. No TDR in the coastal zone (11.2.8(c)); development as the CRZ Notification allows (1.6(i))",
+ "enum": [
+ "I",
+ "II",
+ "III"
+ ],
+ "type": "string"
+}Input schema / properties / flood_zoneAdded value: +{
+ "description": "the plot lies within the blue flood line (prohibitive: no construction, no TDR) or between the blue and red flood lines (restrictive: plinth above the red flood line) (3.1.3; 11.2.8(b))",
+ "enum": [
+ "prohibitive",
+ "restrictive"
+ ],
+ "type": "string"
+}Input schema / properties / gaothan_beltAdded value: +{
+ "description": "a Regional Plan village plot in the agricultural zone, within the belt around the gaothan or a town where 5.1.1 permits residential development, on a premium of a share of the land's ASR rate",
+ "type": "boolean"
+}Input schema / properties / jda_offerAdded value: +{
+ "description": "share of the flats a developer has offered the landowner in a joint development, %; with the rates, gives what the developer keeps at that share beside the share the plot carries",
+ "type": "number"
+}Input schema / properties / land_priceAdded value: +{
+ "description": "asking price of the land when it is being bought, Rs for the whole plot; with the rates, gives the profit at that price and how far it sits from the most to pay for the land",
+ "type": "number"
+}Input schema / properties / papersAdded value: +{
+ "description": "the papers the facts were read from, when they were: 712 (the 7/12 extract or property card, for the area), sheet (the measurement sheet, for the sides and area), zone (the zone certificate or DP remark, for the zone, the road width, road widening and reservations), layout (the sanctioned layout or regularisation order). The study marks each fact as read from its paper or as told; no rule reads them",
+ "items": {
+ "enum": [
+ "712",
+ "sheet",
+ "zone",
+ "layout"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / reservation_typeAdded value: +{
+ "description": "what the DP reservation on the plot is for; with 'reservation', returns accommodation_reservation: developing it by its owner under 11.1, Table 11-A",
+ "enum": [
+ "recreational",
+ "education",
+ "commercial",
+ "health",
+ "transport",
+ "bus_stand",
+ "truck_terminus",
+ "residential",
+ "assembly",
+ "psp",
+ "other"
+ ],
+ "type": "string"
+}Input schema / properties / specified_areaAdded value: +{
+ "description": "Kolhapur: the characteristic specified area of Table 10-B (10.9.1) the plot is in, by Sr. No. ('1' for Rajarampuri) or the area's name; where the row has several plot sizes, Sr. No. and the plot row, e.g. '3.2'. Sets the Table 10-B margins and coverage and the Note 1 basic FSI. Pune: 'koregaon_park' (10.1.2)",
+ "type": "string"
+}Input schema / properties / tod / descriptionPrevious value: -"plot inside a TOD zone (14.2.1)"New value: +"plot inside a TOD zone (14.2): Municipal Corporations, metropolitan authorities and CIDCO; the Nagpur Metro Rail Corridor by Table 14-P"Input schema / properties / units / items / properties / per_floorAdded value: +{
+ "description": "instead of count: units of this type on each typical floor, 0 to 200, repeated on every floor that carries units",
+ "type": "integer"
+}Input schema / properties / units / items / properties / share_of_unitsAdded value: +{
+ "description": "with count left out: this type's share of the units, as a developer gives a mix (60 for 60% 2 BHK), 0 to 1 or a percentage; the number of units is worked out from the building",
+ "type": "number"
+}Input schema / properties / wingsAdded value: +{
+ "description": "a group housing project as wings, each with its own typical floor and floors; units then gives each type and its carpet only. Returns each wing's height, lifts, special building and the distance between wings (6.2.4), and the built-up the wings need against what the rules allow",
+ "items": {
+ "properties": {
+ "floors": {
+ "description": "floors of this wing that carry units, 1 to 60; left out, those of the building that fits",
+ "type": "integer"
+ },
+ "name": {
+ "description": "the wing's name, up to 12 characters: A, B, Tower 1",
+ "type": "string"
+ },
+ "units": {
+ "items": {
+ "properties": {
+ "per_floor": {
+ "description": "units of that type on this wing's typical floor, 0 to 200",
+ "type": "integer"
+ },
+ "type": {
+ "description": "one of the types in units",
+ "type": "string"
+ }
+ },
+ "required": [
+ "type",
+ "per_floor"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "name",
+ "units"
+ ],
+ "type": "object"
+ },
+ "maxItems": 12,
+ "type": "array"
+}feasibility12 fields changedInput schema / properties / crzAdded value: +{
+ "description": "the coastal regulation zone the plot is in: I (between the tide lines), II, or III within its No Development Zone. No TDR in the coastal zone (11.2.8(c)); development as the CRZ Notification allows (1.6(i))",
+ "enum": [
+ "I",
+ "II",
+ "III"
+ ],
+ "type": "string"
+}Input schema / properties / flood_zoneAdded value: +{
+ "description": "the plot lies within the blue flood line (prohibitive: no construction, no TDR) or between the blue and red flood lines (restrictive: plinth above the red flood line) (3.1.3; 11.2.8(b))",
+ "enum": [
+ "prohibitive",
+ "restrictive"
+ ],
+ "type": "string"
+}Input schema / properties / gaothan_beltAdded value: +{
+ "description": "a Regional Plan village plot in the agricultural zone, within the belt around the gaothan or a town where 5.1.1 permits residential development, on a premium of a share of the land's ASR rate",
+ "type": "boolean"
+}Input schema / properties / jda_offerAdded value: +{
+ "description": "share of the flats a developer has offered the landowner in a joint development, %; with the rates, gives what the developer keeps at that share beside the share the plot carries",
+ "type": "number"
+}Input schema / properties / land_priceAdded value: +{
+ "description": "asking price of the land when it is being bought, Rs for the whole plot; with the rates, gives the profit at that price and how far it sits from the most to pay for the land",
+ "type": "number"
+}Input schema / properties / papersAdded value: +{
+ "description": "the papers the facts were read from, when they were: 712 (the 7/12 extract or property card, for the area), sheet (the measurement sheet, for the sides and area), zone (the zone certificate or DP remark, for the zone, the road width, road widening and reservations), layout (the sanctioned layout or regularisation order). The study marks each fact as read from its paper or as told; no rule reads them",
+ "items": {
+ "enum": [
+ "712",
+ "sheet",
+ "zone",
+ "layout"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / reservation_typeAdded value: +{
+ "description": "what the DP reservation on the plot is for; with 'reservation', returns accommodation_reservation: developing it by its owner under 11.1, Table 11-A",
+ "enum": [
+ "recreational",
+ "education",
+ "commercial",
+ "health",
+ "transport",
+ "bus_stand",
+ "truck_terminus",
+ "residential",
+ "assembly",
+ "psp",
+ "other"
+ ],
+ "type": "string"
+}Input schema / properties / specified_areaAdded value: +{
+ "description": "Kolhapur: the characteristic specified area of Table 10-B (10.9.1) the plot is in, by Sr. No. ('1' for Rajarampuri) or the area's name; where the row has several plot sizes, Sr. No. and the plot row, e.g. '3.2'. Sets the Table 10-B margins and coverage and the Note 1 basic FSI. Pune: 'koregaon_park' (10.1.2)",
+ "type": "string"
+}Input schema / properties / tod / descriptionPrevious value: -"plot inside a TOD zone (14.2.1)"New value: +"plot inside a TOD zone (14.2): Municipal Corporations, metropolitan authorities and CIDCO; the Nagpur Metro Rail Corridor by Table 14-P"Input schema / properties / units / items / properties / per_floorAdded value: +{
+ "description": "instead of count: units of this type on each typical floor, 0 to 200, repeated on every floor that carries units",
+ "type": "integer"
+}Input schema / properties / units / items / properties / share_of_unitsAdded value: +{
+ "description": "with count left out: this type's share of the units, as a developer gives a mix (60 for 60% 2 BHK), 0 to 1 or a percentage; the number of units is worked out from the building",
+ "type": "number"
+}Input schema / properties / wingsAdded value: +{
+ "description": "a group housing project as wings, each with its own typical floor and floors; units then gives each type and its carpet only. Returns each wing's height, lifts, special building and the distance between wings (6.2.4), and the built-up the wings need against what the rules allow",
+ "items": {
+ "properties": {
+ "floors": {
+ "description": "floors of this wing that carry units, 1 to 60; left out, those of the building that fits",
+ "type": "integer"
+ },
+ "name": {
+ "description": "the wing's name, up to 12 characters: A, B, Tower 1",
+ "type": "string"
+ },
+ "units": {
+ "items": {
+ "properties": {
+ "per_floor": {
+ "description": "units of that type on this wing's typical floor, 0 to 200",
+ "type": "integer"
+ },
+ "type": {
+ "description": "one of the types in units",
+ "type": "string"
+ }
+ },
+ "required": [
+ "type",
+ "per_floor"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "name",
+ "units"
+ ],
+ "type": "object"
+ },
+ "maxItems": 12,
+ "type": "array"
+}fetch1 field changedInput schema / properties / id / descriptionPrevious value: -"an id from search, such as udcpr/6-2-6, udcpr/table-6-g or towns/kolhapur"New value: +"an id from search, such as udcpr/6-2-6, udcpr/table-6-g, towns/kolhapur or glossary/carpet"check_design4 fields changedInput schema / properties / area / descriptionPrevious value: -"plot area in m2: the least of 7/12, measurement sheet and site (1 sq ft = 0.0929 m2; 1 guntha = 101.17 m2; 1 acre = 4,046.86 m2)"New value: +"plot area as the user gave it, in m2 unless area_unit says sqft, guntha, acre or hectare: the least of 7/12, measurement sheet and site"Input schema / properties / area_unitAdded value: +{
+ "description": "unit of area, road_widening and reservation as the user gave them; default m2. Citiwise converts and says so in units",
+ "enum": [
+ "m2",
+ "sqft",
+ "guntha",
+ "acre",
+ "hectare"
+ ],
+ "type": "string"
+}Input schema / properties / road / descriptionPrevious value: -"width of the road in front in m, when there is one road and no sides (1 ft = 0.3048 m)"New value: +"width of the road in front, in m unless road_unit is ft, when there is one road and no sides"Input schema / properties / road_unitAdded value: +{
+ "description": "unit of road and of each road side's width as the user gave them; default m",
+ "enum": [
+ "m",
+ "ft"
+ ],
+ "type": "string"
+}compare_uses4 fields changedInput schema / properties / area / descriptionPrevious value: -"plot area in m2: the least of 7/12, measurement sheet and site (1 sq ft = 0.0929 m2; 1 guntha = 101.17 m2; 1 acre = 4,046.86 m2)"New value: +"plot area as the user gave it, in m2 unless area_unit says sqft, guntha, acre or hectare: the least of 7/12, measurement sheet and site"Input schema / properties / area_unitAdded value: +{
+ "description": "unit of area, road_widening and reservation as the user gave them; default m2. Citiwise converts and says so in units",
+ "enum": [
+ "m2",
+ "sqft",
+ "guntha",
+ "acre",
+ "hectare"
+ ],
+ "type": "string"
+}Input schema / properties / road / descriptionPrevious value: -"width of the road in front in m, when there is one road and no sides (1 ft = 0.3048 m)"New value: +"width of the road in front, in m unless road_unit is ft, when there is one road and no sides"Input schema / properties / road_unitAdded value: +{
+ "description": "unit of road and of each road side's width as the user gave them; default m",
+ "enum": [
+ "m",
+ "ft"
+ ],
+ "type": "string"
+}feasibility4 fields changedInput schema / properties / area / descriptionPrevious value: -"plot area in m2: the least of 7/12, measurement sheet and site (1 sq ft = 0.0929 m2; 1 guntha = 101.17 m2; 1 acre = 4,046.86 m2)"New value: +"plot area as the user gave it, in m2 unless area_unit says sqft, guntha, acre or hectare: the least of 7/12, measurement sheet and site"Input schema / properties / area_unitAdded value: +{
+ "description": "unit of area, road_widening and reservation as the user gave them; default m2. Citiwise converts and says so in units",
+ "enum": [
+ "m2",
+ "sqft",
+ "guntha",
+ "acre",
+ "hectare"
+ ],
+ "type": "string"
+}Input schema / properties / road / descriptionPrevious value: -"width of the road in front in m, when there is one road and no sides (1 ft = 0.3048 m)"New value: +"width of the road in front, in m unless road_unit is ft, when there is one road and no sides"Input schema / properties / road_unitAdded value: +{
+ "description": "unit of road and of each road side's width as the user gave them; default m",
+ "enum": [
+ "m",
+ "ft"
+ ],
+ "type": "string"
+}check_design2 fields changedInput schema / properties / basement_flushAdded value: +{
+ "description": "basement top flush with the ground: it may then run into the side and rear margins (9.11.1 proviso i)",
+ "type": "boolean"
+}Input schema / properties / basementsAdded value: +{
+ "description": "levels of basement, for parking and services (9.11)",
+ "maximum": 5,
+ "minimum": 0,
+ "type": "integer"
+}compare_uses2 fields changedInput schema / properties / basement_flushAdded value: +{
+ "description": "basement top flush with the ground: it may then run into the side and rear margins (9.11.1 proviso i)",
+ "type": "boolean"
+}Input schema / properties / basementsAdded value: +{
+ "description": "levels of basement, for parking and services (9.11)",
+ "maximum": 5,
+ "minimum": 0,
+ "type": "integer"
+}feasibility2 fields changedInput schema / properties / basement_flushAdded value: +{
+ "description": "basement top flush with the ground: it may then run into the side and rear margins (9.11.1 proviso i)",
+ "type": "boolean"
+}Input schema / properties / basementsAdded value: +{
+ "description": "levels of basement, for parking and services (9.11)",
+ "maximum": 5,
+ "minimum": 0,
+ "type": "integer"
+}check_design1 field changedInput schema / properties / sides / items / properties / cornerAdded value: +{
+ "description": "true for the rounding or cut where two roads meet (3.3.12): margins run from it, but it is not a road of its own",
+ "type": "boolean"
+}compare_uses1 field changedInput schema / properties / sides / items / properties / cornerAdded value: +{
+ "description": "true for the rounding or cut where two roads meet (3.3.12): margins run from it, but it is not a road of its own",
+ "type": "boolean"
+}feasibility1 field changedInput schema / properties / sides / items / properties / cornerAdded value: +{
+ "description": "true for the rounding or cut where two roads meet (3.3.12): margins run from it, but it is not a road of its own",
+ "type": "boolean"
+}check_design9 fields changedInput schema / properties / build_costAdded value: +{
+ "description": "construction cost, Rs a sq ft of built-up area",
+ "type": "number"
+}Input schema / properties / carpet_shareAdded value: +{
+ "description": "carpet area as a share of the built-up, 0.3 to 0.95 or 30 to 95 (default 0.8); sets the unit counts left out and so the sales value",
+ "type": "number"
+}Input schema / properties / marginAdded value: +{
+ "description": "margin the developer needs, % of sales value; with the rates, gives the most to pay for the land and the largest share of the flats for the landowner in a joint development",
+ "type": "number"
+}Input schema / properties / other_costsAdded value: +{
+ "description": "other costs (fees, finance, marketing), % of construction cost",
+ "type": "number"
+}Input schema / properties / parking_costAdded value: +{
+ "description": "construction cost of the stilt floor, Rs a sq ft; the stilt is free of FSI but built; default build_cost",
+ "type": "number"
+}Input schema / properties / prepared_byAdded value: +{
+ "description": "who is giving the study, as it should appear on its cover, e.g. a broker or developer",
+ "maxLength": 80,
+ "type": "string"
+}Input schema / properties / prepared_forAdded value: +{
+ "description": "who the study is for, as it should appear on its cover, e.g. the landowner or client",
+ "maxLength": 80,
+ "type": "string"
+}Input schema / properties / sale_rateAdded value: +{
+ "description": "sale rate, Rs a sq ft of carpet area; with build_cost and tdr_rate gives an appraisal: sales value, construction, premiums, TDR and the surplus before land",
+ "type": "number"
+}Input schema / properties / tdr_rateAdded value: +{
+ "description": "price of TDR, Rs a sq ft",
+ "type": "number"
+}compare_uses9 fields changedInput schema / properties / build_costAdded value: +{
+ "description": "construction cost, Rs a sq ft of built-up area",
+ "type": "number"
+}Input schema / properties / carpet_shareAdded value: +{
+ "description": "carpet area as a share of the built-up, 0.3 to 0.95 or 30 to 95 (default 0.8); sets the unit counts left out and so the sales value",
+ "type": "number"
+}Input schema / properties / marginAdded value: +{
+ "description": "margin the developer needs, % of sales value; with the rates, gives the most to pay for the land and the largest share of the flats for the landowner in a joint development",
+ "type": "number"
+}Input schema / properties / other_costsAdded value: +{
+ "description": "other costs (fees, finance, marketing), % of construction cost",
+ "type": "number"
+}Input schema / properties / parking_costAdded value: +{
+ "description": "construction cost of the stilt floor, Rs a sq ft; the stilt is free of FSI but built; default build_cost",
+ "type": "number"
+}Input schema / properties / prepared_byAdded value: +{
+ "description": "who is giving the study, as it should appear on its cover, e.g. a broker or developer",
+ "maxLength": 80,
+ "type": "string"
+}Input schema / properties / prepared_forAdded value: +{
+ "description": "who the study is for, as it should appear on its cover, e.g. the landowner or client",
+ "maxLength": 80,
+ "type": "string"
+}Input schema / properties / sale_rateAdded value: +{
+ "description": "sale rate, Rs a sq ft of carpet area; with build_cost and tdr_rate gives an appraisal: sales value, construction, premiums, TDR and the surplus before land",
+ "type": "number"
+}Input schema / properties / tdr_rateAdded value: +{
+ "description": "price of TDR, Rs a sq ft",
+ "type": "number"
+}feasibility9 fields changedInput schema / properties / build_costAdded value: +{
+ "description": "construction cost, Rs a sq ft of built-up area",
+ "type": "number"
+}Input schema / properties / carpet_shareAdded value: +{
+ "description": "carpet area as a share of the built-up, 0.3 to 0.95 or 30 to 95 (default 0.8); sets the unit counts left out and so the sales value",
+ "type": "number"
+}Input schema / properties / marginAdded value: +{
+ "description": "margin the developer needs, % of sales value; with the rates, gives the most to pay for the land and the largest share of the flats for the landowner in a joint development",
+ "type": "number"
+}Input schema / properties / other_costsAdded value: +{
+ "description": "other costs (fees, finance, marketing), % of construction cost",
+ "type": "number"
+}Input schema / properties / parking_costAdded value: +{
+ "description": "construction cost of the stilt floor, Rs a sq ft; the stilt is free of FSI but built; default build_cost",
+ "type": "number"
+}Input schema / properties / prepared_byAdded value: +{
+ "description": "who is giving the study, as it should appear on its cover, e.g. a broker or developer",
+ "maxLength": 80,
+ "type": "string"
+}Input schema / properties / prepared_forAdded value: +{
+ "description": "who the study is for, as it should appear on its cover, e.g. the landowner or client",
+ "maxLength": 80,
+ "type": "string"
+}Input schema / properties / sale_rateAdded value: +{
+ "description": "sale rate, Rs a sq ft of carpet area; with build_cost and tdr_rate gives an appraisal: sales value, construction, premiums, TDR and the surplus before land",
+ "type": "number"
+}Input schema / properties / tdr_rateAdded value: +{
+ "description": "price of TDR, Rs a sq ft",
+ "type": "number"
+}fetchsearchZoning, ADU eligibility, flood zone, setbacks, and buildability intelligence for U.S. parcels.
Indonesian OSS RDTR zoning: zone and sub-zone at a point, special provisions, area summaries.
Zoning, parcel, and development feasibility for a street address in Canada and the US.
US municipal development cost: aggregated impact + water/sewer tap fees per jurisdiction
Add one secure layer between your agents and this server.
