Skip to main content
Glama

Vastu Shastra MCP Server by RoxyAPI

by com.roxyapi

Analyse a plot - Vastu land and site assessment API

post_vastu_plot
Read-only

Vastu plot analysis from typed geometry: send the outline, the facing, where the ground falls and where the water is, and the API returns a verdict on the shape, the proportion, the ground level under two schools, each corner extension and cut, the road and the water. Every verdict names the chapter and verse behind it, or says plainly that it is convention, which matters because the ground level verses and the widely taught modern rule genuinely disagree. Built for listing and land assessment tools, practitioner site reports and buyer facing checks.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cutsNoQuarters where a corner is missing from the rectangle. Every cut verdict is convention, for the same reason as the extensions.
langNoResponse 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
plotYesThe 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.
roadNoWhich side a road runs along. The verdict is convention: the chapter states no rule for the side a road is on, only that an obstruction facing the gate brings misery unless it lies beyond twice the height of the house.
waterNoWhich quarter holds standing water, a well, a tank or a sump. This one IS sourced: 53.119 gives a distinct effect for each of the eight directions and calls only the north and the north-east favourable.
facingNoDirection 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.
compactNoSet 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.
extensionsNoQuarters where the plot bulges out beyond a rectangle. Every extension verdict is convention: the chapter states no rule for a named corner and the nearest verses speak of a figure with a limb wanting.
slopeSchoolNoWhich reading of the ground level to lead with. brihat-samhita applies verses 115 to 117 as written, where a higher north-east is a loss, a higher east or north is permitted when level ground is unavoidable and still carries its stated cost, and a higher south or west carries its cost with no allowance. modern applies the widely taught rule that the north-east must be the lowest point, which agrees with verse 115 and contradicts the verse 116 allowance. Both readings are returned whichever you choose, so the disagreement is visible rather than hidden. Defaults to brihat-samhita.brihat-samhita
facingDegreesNoDirection 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.
slopeLowDirectionNoWhich quarter of the plot the ground falls toward, that is where the LOW point is. The chapter states its rules in terms of the side that stands HIGHER, so the opposite of this value is what the verses are read against, and both are returned. Omit it if the ground is level.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare the tool read-only and non-destructive; the description adds valuable behavioral detail beyond that: every verdict either cites chapter and verse or explicitly labels itself convention, and the genuine disagreement between the verse-based ground-level reading and the modern rule is surfaced. This tells the agent what kind of epistemic output to expect.

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 front-loaded sentences cover purpose, output behavior, and intended use cases without bloating. The chapter-and-verse note earns its place because it explains a non-obvious output property that matters for interpreting results.

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?

For a complex 11-parameter tool with no output schema, the description gives enough for an agent to select it and understand what comes back: verdict topics, sourcing behavior, and the two-school ground-level treatment. Remaining details like enum values, coordinate conventions, and compact mode are fully covered by the input 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 description coverage is 100%, so the schema already documents all parameters, including units, defaults, mutual exclusions, enums, and the width/depth vs polygon distinction. The top-level description only summarizes input categories and does not add parameter-level meaning beyond what the schema provides, so the baseline of 3 applies.

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 opens with 'Vastu plot analysis from typed geometry' and enumerates both inputs (outline, facing, ground fall, water) and outputs (shape, proportion, ground level under two schools, corner extension/cut, road, water). It clearly positions this as a whole-plot assessment tool, distinct from more specialized Vastu sibling tools like entrance, rooms, or mandala analyses.

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 clear intended contexts—'listing and land assessment tools, practitioner site reports and buyer facing checks'—which tells an agent when this tool is relevant. It does not explicitly name alternatives or state when not to use it, so it provides clear context without full exclusion guidance.

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 toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool targets a distinct resource or analytical step: reference lookups (devatas, directions) are cleanly separated from computations (ayadi, entrance, mandala, plot, rooms, timing), and the list endpoints are distinguished from their _id counterparts by an explicit suffix. Although three post_ tools accept plot geometry, their outputs are mutually exclusive (grid overlay vs. property verdict vs. room-by-room check), and the descriptions state each purpose with enough precision to prevent misselection.

Naming Consistency5/5

All ten tools follow a uniform lowercase snake_case pattern with a get_ or post_ prefix and the vastu domain token consistently in second position. The get_ prefix is reserved for read-only reference data while post_ marks computational endpoints, and the _id suffix uniformly marks single-item lookups, creating a highly predictable scheme.

Tool Count5/5

Ten tools is a well-scoped count for a domain-specific server covering reference data, analysis, and timing. Each tool earns its place: the two list/detail pairs follow standard API practice without redundancy, and the six computational tools each address a distinct stage of Vastu analysis.

Completeness4/5

The tool surface covers the full Vastu consulting workflow: reference data (devatas, directions), land assessment (plot), grid projection (mandala), entrance validation, room placement, dimensional proportion checks (ayadi), and housewarming date selection (griha pravesh). The only notable gap is that timing is restricted to griha pravesh, leaving other Vastu-related muhurta events like construction commencement uncovered.

Resources