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

TableJSON 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

TableJSON 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.

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

A4.3/5.0

Behavior4/5

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

Annotations already cover the read-only and non-destructive safety profile. The description adds useful behavioral context: every verdict carries typed chapter-and-verse provenance, and the reading supports both 81-pada and 64-pada divisions. It does not discuss error cases or limitations, but those are documented in the schema and nothing contradicts the annotations.

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

Conciseness5/5

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

Three focused sentences front-load the core action and output list before the use cases. There is no filler, no repetition of schema details, and every sentence contributes to selection or invocation.

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?

Given the very rich input schema, output schema, and annotations, the description is complete enough: it identifies inputs, outputs, provenance, supported grids, and target use cases. Parameter-level details such as coordinates, units, and exclusive alternatives live where they belong in the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the input schema provides detailed descriptions for every parameter, including units, coordinate axes, snapping behavior, and mutually exclusive alternatives. The prose description only says 'send the plot and where the door sits' and adds no parameter-level meaning, so the schema carries the burden.

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

Purpose5/5

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

The description names a specific resource and action: 'Vastu entrance analysis for a main door' where you send the plot and door position and receive padas, devata, classical effect, and favourable padas. This clearly separates it from the sibling tools about devatas, directions, mandala, rooms, and timing. The title reinforces the same purpose.

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

Usage Guidelines4/5

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

The description gives concrete intended contexts: property and interior design tools, practitioner reports, and any product that must judge whether a front door is well placed. It does not explicitly name alternatives or say when not to use this tool, but the use case is clear enough for an agent to select it for entrance-placement analysis.

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?