Vastu Shastra MCP Server by RoxyAPI

Calculate entrance pada - Vastu main door direction API

post_vastu_entrance

Read-only

Vastu entrance analysis for a main door: send the plot and where the door sits, and the API returns which of the 32 perimeter padas it falls on, the devata of that square, the effect the classical chapter gives that pada, and the favourable padas on the same side to move toward. Every verdict carries the chapter and verse it comes from as a typed field, and the reading holds on either the 81 pada or the 64 pada division. Built for property and interior design tools, practitioner reports, and any product that has to say whether a front door is well placed.

Input Schema

Name	Required	Description	Default
`door`	No	Where the main door sits, in plot coordinates. The point is snapped to the nearest boundary of the plot, so a coordinate read off a drawing that lands slightly inside or outside still resolves. Send this or doorPosition, never both.
`grid`	No	Which division of the ground to read: 81-pada is the Paramasayika of Brihat Samhita 53.42, the grid the chapter numbers and names every devata on, and 64-pada is the Manduka of 53.55, for which the chapter gives structure only and no devata names. Defaults to 81-pada.	81-pada
`lang`	No	Response language (BCP 47). Supported: en, tr, de, es, hi, pt, fr, ru, zh-Hans, zh-Hant. Defaults to en. Coverage varies by domain, and a field with no translation in the requested language returns English.	en
`plot`	Yes	The ground the mandala is projected over. Send width and depth for a compass-aligned rectangle, or polygon for anything else. The x axis runs east and the y axis north, and the mandala is aligned to the compass rather than to the building.
`facing`	No	Direction the front of the house looks out toward, one of the eight compass sectors. Case and punctuation are folded, so north-east, northeast and NorthEast all resolve. Send this or facingDegrees, never both.
`compact`	No	Set true for the same data in a compact shape: arrays of same-shaped objects arrive columnar as {"__cols":[names],"__rows":[[values]]}. Lossless, typically 40 to 52 percent fewer tokens.
`doorPosition`	No	Where the main door sits along the facing side, as a fraction from 0 to 1 measured from the corner the chapter starts that side at: the north-east for an east facing, the south-east for a south facing, the south-west for a west facing and the north-west for a north facing. The side carries 8 padas, so to aim at pada n of 8 send its midpoint, (n - 0.5) / 8: 0.0625 for the first pada, 0.4375 for the fourth, 0.9375 for the eighth. The response names the pada the fraction resolved to in ordinalOnSide. Requires a cardinal facing, since an intercardinal facing names no single side. Send this or door, never both.
`facingDegrees`	No	Direction the front of the house looks out toward, as a compass bearing in degrees clockwise from true north, measured looking OUT from the building. The same convention the feng shui facing endpoints use, so a bearing works unchanged across the two domains. Send this or facing, never both.

Output Schema

Name	Required	Description	Default
`cell`	Yes
`pada`	Yes
`side`	Yes
`devata`	No
`effect`	Yes
`source`	Yes
`square`	Yes
`reading`	Yes
`conventions`	Yes
`startCorner`	Yes
`ordinalOnSide`	Yes
`auspiciousness`	Yes
`recommendedPadas`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 23, 2026
- addedInput schema / properties / plot / x-required-any-of
```
Added value: +[
+  [
+    "width",
+    "depth"
+  ],
+  [
+    "polygon"
+  ]
+]
```

Changed2 schema fields changedSep 20, 2026

addedInput schema / examples

Added value: +[
+  {
+    "plot": {
+      "depth": 40,
+      "unit": "feet",
+      "width": 30
+    }
+  }
+]

addedInput schema / properties / plot / example

Added value: +{
+  "depth": 40,
+  "unit": "feet",
+  "width": 30
+}

Changed1 schema field changedSep 20, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "auspiciousness": {
+      "type": "string"
+    },
+    "cell": {
+      "properties": {
+        "columnFromWest": {
+          "type": "number"
+        },
+        "rowFromNorth": {
+          "type": "number"
+        }
+      },
+      "required": [
+        "rowFromNorth",
+        "columnFromWest"
+      ],
+      "type": "object"
+    },
+    "conventions": {
+      "properties": {
+        "grid": {
+          "type": "string"
+        },
+        "unit": {
+          "enum": [
+            "feet",
+            "metres"
+          ],
+          "type": "string"
+        }
+      },
+      "required": [
+        "grid",
+        "unit"
+      ],
+      "type": "object"
+    },
+    "devata": {
+      "properties": {
+        "id": {
+          "type": "string"
+        },
+        "name": {
+          "type": "string"
+        },
+        "padaCount": {
+          "type": "number"
+        }
+      },
+      "required": [
+        "id",
+        "name",
+        "padaCount"
+      ],
+      "type": "object"
+    },
+    "effect": {
+      "type": "string"
+    },
+    "ordinalOnSide": {
+      "type": "number"
+    },
+    "pada": {
+      "type": "number"
+    },
+    "reading": {
+      "type": "string"
+    },
+    "recommendedPadas": {
+      "items": {
+        "type": "number"
+      },
+      "type": "array"
+    },
+    "side": {
+      "type": "string"
+    },
+    "source": {
+      "properties": {
+        "basis": {
+          "type": "string"
+        },
+        "chapter": {
+          "type": "number"
+        },
+        "publicDomain": {
+          "type": "boolean"
+        },
+        "text": {
+          "type": "string"
+        },
+        "translation": {
+          "type": "string"
+        },
+        "verse": {
+          "type": "string"
+        },
+        "year": {
+          "type": "number"
+        }
+      },
+      "required": [
+        "text"
+      ],
+      "type": "object"
+    },
+    "square": {
+      "type": "number"
+    },
+    "startCorner": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "pada",
+    "side",
+    "startCorner",
+    "ordinalOnSide",
+    "square",
+    "cell",
+    "effect",
+    "auspiciousness",
+    "reading",
+    "recommendedPadas",
+    "source",
+    "conventions"
+  ],
+  "type": "object"
+}

First observedSep 6, 2026

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds useful scope context — every verdict carries chapter and verse as a typed field, and the reading holds on both the 81 and 64 pada divisions — but nothing about latency, limits, or failure modes. Adequate rather than rich against a partly-covered bar.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action and return payload in the first sentence; the sourcing and grid notes follow in a logical order. The closing 'Built for property and interior design tools…' sentence is partly marketing and only weakly functional, but it's a minor tax on an otherwise tight description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description needn't explain return values, and it doesn't need to — the schema fully documents the 8 nested/enum parameters. The description completes the picture by explaining what domain the analysis operates in (32 perimeter padas, both grid divisions) and its intended audience, though it could do more to route between the ten sibling Vastu endpoints.

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 description coverage is 100% across 8 params, so baseline is 3; the description still adds meaning by sourcing the grid option to Brihat Samhita 53.42/53.55 and clarifying that the reading is valid under either division. It also frames the input at a high level ('send the plot and where the door sits') without duplicating the exhaustive door/doorPosition/facing alternates that the schema already documents.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource — 'Vastu entrance analysis for a main door' — and enumerates exactly what the API returns (32-pada placement, devata, classical effect, favourable padas on the side). It's clearly a door/entrance tool, not a plot or mandala tool, but it never names any of its many siblings (post_vastu_plot, post_vastu_mandala, get_vastu_directions) to distinguish which one to use for what.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: 'Built for property and interior design tools, practitioner reports, and any product that has to say whether a front door is well placed' tells you the audience but not when to call this versus the sibling Vastu endpoints. There are no when-not conditions and no explicit alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Vastu Shastra MCP Server by RoxyAPI tools Inspect

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

Need Help?