Skip to main content
Glama

Citiwise

by io.github.tejasdgurav
OverviewDiscussionsAdmin

draw_plot

Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
useNo
townNowith use: also run the feasibility
unitNounit of every bare number among the lengths and road widths; default m
zoneNo
sidesYesevery side in order round the plot, either direction; at least one is a road
anglesNointerior angle in degrees at each corner; corner i is where side i begins; null where not measured
polygonNothe corners [x, y] instead of lengths and angles, one per side
area_unitNounit 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
diagonalsNocorner-to-corner distances; a plot of n sides needs n - 3, e.g. from corner 1 to each corner it does not touch
stated_areaNothe 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_anglesNotrue when every corner of a four-sided plot is square

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / sides / items / properties / beyond / description
      Previous 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)"
    • changedInput schema / properties / sides / items / properties / beyond / enum
      Previous value: -[
-  "road",
-  "plot",
-  "open",
-  "nallah",
-  "river",
-  "rail"
-]New value: +[
+  "road",
+  "plot",
+  "open",
+  "nallah",
+  "river",
+  "rail",
+  "shared"
+]
  2. Changed12 schema fields changed
    • changedInput schema / properties / angles / description
      Previous 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"
    • changedInput schema / properties / angles / items / type
      Previous value: -"number"New value: +[
+  "number",
+  "string",
+  "null"
+]
    • addedInput schema / properties / area_unit
      Added 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"
+}
    • changedInput schema / properties / diagonals / items / properties / length / type
      Previous value: -"number"New value: +[
+  "number",
+  "string"
+]
    • changedInput schema / properties / sides / items / properties / length / description
      Previous 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"
    • changedInput schema / properties / sides / items / properties / length / type
      Previous value: -"number"New value: +[
+  "number",
+  "string",
+  "null"
+]
    • changedInput schema / properties / sides / items / properties / width / description
      Previous 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"
    • changedInput schema / properties / sides / items / properties / width / type
      Previous value: -"number"New value: +[
+  "number",
+  "string"
+]
    • removedInput schema / properties / sides / items / required
      Removed value: -[
-  "length"
-]
    • changedInput schema / properties / stated_area / description
      Previous 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"
    • changedInput schema / properties / stated_area / type
      Previous value: -"number"New value: +[
+  "number",
+  "string"
+]
    • changedInput schema / properties / unit / description
      Previous 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"
  3. Added

TDQS

A4.7/5.0
Behavior5/5

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.

Conciseness3/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All Citiwise toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources