Vastu entrance padas, the 81 pada mandala, plot and room analysis, Ayadi and griha pravesh timing.
Scored across 10 tools
Each tool targets a distinct resource or action: reference lookups for devatas and directions, and analysis tools for ayadi, entrance, mandala, plot, rooms, and timing. There is no overlap between tools; get_vastu_devatas vs get_vastu_devatas_id is a clear list vs single-item pattern, same for directions.
Naming follows a consistent verb_noun pattern: get_vastu_* for reference endpoints and post_vastu_* for analysis endpoints. The _id suffix consistently indicates single-item lookups, and all names use snake_case with a clear domain prefix. This is a model of consistency.
10 tools is well within the ideal 3-15 range. The set covers both reference data and computational analysis for the Vastu Shastra domain without bloat. Each tool earns its place, offering a complete toolkit for practitioners and integrators.
The tool surface covers the core domain comprehensively: reference tables for devatas and directions, and analysis tools for ayadi calculations, entrance placement, mandala projection, plot analysis, room checks, and timing (griha pravesh). It handles both 81 and 64 pada divisions and includes classical verses vs convention distinctions, leaving no obvious gaps.
Reference table of the 45 devatas of the Vastu Purusha Mandala: which squares of the 81 pada grid each one holds, which ring and which side, how many padas, and the verses that place it. A pure reference endpoint with no plot required, for building a mandala diagram or a glossary. Where the sources contradict each other, and they do on several rows, the row says so instead of quietly picking a side.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 |
| limit | No | Maximum items to return per page. Range: 1-45, default 45. | |
| offset | No | Number of items to skip for pagination. Default 0. | |
| 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. |
| Name | Required | Description |
|---|---|---|
| limit | Yes | |
| total | Yes | |
| offset | Yes | |
| devatas | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description reinforces a safe read-only reference behavior with 'pure reference endpoint. It adds valuable behavioral context beyond annotations by explaining that contradictory sources are disclosed in the rows instead of being silently resolved.
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 with no waste: the first states the resource and fields, the second gives the use case and the non-plot constraint, and the third discloses contradiction behavior. Each sentence earns its place and the key scoping detail is front-loaded.
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, combined with full schema documentation, read-only annotations, and an output schema, gives an agent everything needed to select and invoke the tool correctly. It explains content depth, the no-plot requirement, and even edge-case handling around source contradictions.
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%, with detailed descriptions for lang, limit, offset, and compact, so the schema carries the parameter semantics. The description does not add meaning about how parameters behave, but given full schema coverage, the 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 names a specific resource (the 45 devatas of the Vastu Purusha Mandala) and states precisely what is included: grid squares, ring, side, pada count, and verses. It also differentiates the tool from plotting-related siblings by calling it a 'pure reference endpoint with no plot required.'
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 description gives clear use cases: 'for building a mandala diagram or a glossary' and a clear exclusion: 'no plot required. It does not explicitly name alternative sibling tools such as get_vastu_devatas_id for single-record lookups, but the context is strong enough for an agent to choose this tool correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up one devata of the Vastu Purusha Mandala: the squares it holds, its ring and side, its pada count, the entrance pada it governs where it sits on the perimeter, and the verses that place it. Case and punctuation in the id are folded, so indra-outer, Indra_Outer and INDRA OUTER all resolve.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Devata id, lower case transliteration. The two Indras are indra-outer for the east perimeter square and indra-inner for the inner ring one. Case and punctuation are folded. | |
| 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 |
| 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. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| name | Yes | |
| note | No | |
| role | Yes | |
| side | No | |
| cells | Yes | |
| class | Yes | |
| group | No | |
| source | Yes | |
| verses | Yes | |
| squares | Yes | |
| quadrant | No | |
| padaCount | Yes | |
| entrancePada | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal readOnlyHint and non-destructive behavior. The description adds genuinely useful behavioral context: id case/punctuation folding ('indra-outer, Indra_Outer and INDRA OUTER all resolve') and the specific semantic fields returned. It does not discuss error behavior, but the schema enum and read-only annotation reduce that burden.
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 compact, front-loaded, and information-dense. The first clause states the action and resource, the field list specifies the return scope, and the second sentence covers id normalization with concrete examples. No sentence is wasted.
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?
Given the read-only annotations, a fully described input schema, and an output schema, the description provides everything needed to invoke the tool correctly: what it returns, how id matching works, and how it differs from sibling lookups. Nothing essential is missing.
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 baseline is 3. The description reinforces the id folding behavior already stated in the schema but adds no new parameter-level meaning; lang and compact behavior are left entirely to the schema. This is acceptable but not additive.
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 opens with a specific verb and resource: 'Look up one devata of the Vastu Purusha Mandala.' It then enumerates exactly what data is returned, which clearly distinguishes this single-item lookup from the plural-list sibling get_vastu_devatas and from direction lookups.
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 'one devata' phrasing makes the single-record context clear, and the sibling list reinforces the distinction from get_vastu_devatas. However, it does not explicitly state 'use this instead of get_vastu_devatas when you need one id' or mention exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reference table of the eight Vastu directions: the dikpala who rules each quarter of the horizon, the squares of the mandala it covers with their devatas, what the chapter places on that side, and what standing water there brings. A pure reference endpoint with no plot required, for building a picker or a directions guide. Every row says which verse each part comes from and labels the element as the later convention it is.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 |
| limit | No | Maximum items to return per page. Range: 1-8, default 8. | |
| offset | No | Number of items to skip for pagination. Default 0. | |
| 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. |
| Name | Required | Description |
|---|---|---|
| limit | Yes | |
| total | Yes | |
| offset | Yes | |
| directions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description reinforces this with 'pure reference endpoint' and adds useful behavioral detail: every row cites its source verse and labels the element as the later convention. This goes beyond the annotations without contradicting them.
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: the first packs the content list, the second gives the use case, and the third explains row provenance. There is no filler, though 'reference' appears twice; overall it is efficient and front-loaded.
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 simple list endpoint with full schema coverage and an output schema, the description covers purpose, content, use case, and a key behavioral distinction (no plot required). Everything an agent needs to call it correctly is 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 description coverage is 100%, with lang, limit, offset, and compact each fully described. The description adds no parameter-specific detail, so it appropriately relies on the schema; baseline 3 applies.
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 explicitly states 'Reference table of the eight Vastu directions' and enumerates the row contents (dikpala, devatas, chapter placements, standing water). The title 'List the eight directions' and the listing behavior clearly distinguish it from get_vastu_directions_id and get_vastu_devatas.
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 clear context: 'A pure reference endpoint with no plot required, for building a picker or a directions guide.' This implies it is for read-only reference rather than plot/post endpoints, though it does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up one Vastu direction: its dikpala, the mandala squares it covers with their devatas, what the chapter places there, and what standing water in that quarter brings. Case and punctuation in the id are folded, so north-east, northeast and NorthEast all resolve to the same entry, and the id space is the one the feng shui and I Ching endpoints use.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Direction id, one of North, Northeast, East, Southeast, South, Southwest, West, Northwest. Case and punctuation are folded. | |
| 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 |
| 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. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| kind | Yes | |
| water | Yes | |
| places | No | |
| devatas | Yes | |
| dikpala | Yes | |
| element | No | |
| sources | Yes | |
| squares | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond those annotations: case and punctuation folding in the id, and the fact that this id space is shared with other endpoints. This enriches the agent's understanding without contradicting 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the primary action and output content, then provides the normalization and cross-API context in the second sentence. Every clause earns its place.
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 read-only single-direction lookup with an output schema and three fully documented parameters, the description is complete. It covers what the tool returns, mentions id normalization behavior, and situates the id in a shared endpoint ecosystem. The lang and compact parameters are fully handled by the schema, so nothing essential is missing.
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 100%, so the baseline is 3. The description goes beyond the schema by explaining that id normalization applies to case and punctuation and that the id space is the same one used by feng shui and I Ching endpoints, which is a meaningful semantic addition for cross-tool use. The other parameters are already fully described in 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 uses a specific verb and resource: 'Look up one Vastu direction' and then enumerates the rich output fields (dikpala, mandala squares and devatas, chapter placement, standing water meaning). It clearly distinguishes itself from the sibling list tool get_vastu_directions by saying 'one' direction, and the id-sharing note ties it into a broader endpoint family.
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 phrase 'Look up one Vastu direction' makes the primary use case obvious)Skip versus get_vastu_directions. It also explains that the id space is shared with feng shui and I Ching endpoints, guiding use across related APIs. It stops short of explicitly naming alternatives or saying when not to use it, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ayadi shadvarga calculator for a building or a room: send the dimensions and the API returns all six proportional formulas with the multiplier, the divisor and the remainder shown, the member each remainder names, and the two verdict rules the texts state. Choose between three text families, which genuinely disagree, and choose your own cubit length, because every remainder is unit sensitive. Built for practitioner tools, plan checking software and anyone who has to justify a dimension rather than assert it.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 |
| unit | No | Unit the Ayadi dimensions are given in. Every remainder is unit sensitive, so this is an input and never assumed: the same building measured in cubits and in feet gives different remainders. hasta is the classical cubit and needs no conversion; feet and metres are converted using hastaInches and rounded to whole cubits, and the rounded figures are returned. Defaults to hasta. | hasta |
| length | Yes | Length of the building or room, in the unit given. Under the Manasara family this is the measure the aya and rksha formulas multiply; under the perimeter family it only feeds the perimeter. | |
| breadth | Yes | Breadth of the building or room, in the unit given. Under the Manasara family this is the measure the vyaya and yoni formulas multiply. | |
| 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. | |
| ayadiText | No | Which family of Ayadi formulas to apply. manasara takes length, breadth and circumference separately and is double sourced. perimeter-texts runs every formula on the perimeter alone and is the family the usual worked example is printed for. utpala supplies a yoni formula from the length times the breadth and nothing else, so the other five vargas fall back to the perimeter family and the response says so. Defaults to manasara. | manasara |
| perimeter | No | Perimeter of the plan, if it is not simply twice the length plus twice the breadth. The perimeter family runs every formula on this one measure, so it is the number that decides all six remainders there. | |
| hastaInches | No | Length of one hasta, the classical cubit, in inches. Defaults to 18, which is 24 angula at three quarters of an inch each and is the value three independent sources agree on. Raise it if your lineage measures the cubit differently; the value used is echoed on the response so a stored reading can be reproduced years later. Only used when unit is feet or metres. | |
| vyayaFormula | No | Which vyaya formula the perimeter family uses. The printed table gives two joined by the word or and states no rule for choosing. p9-10 multiplies by nine and divides by ten, which is the only divisor consistent with the ten member vyaya group, so its remainder can be placed in that group and it is the default. p3-14 multiplies by three and divides by fourteen, and its remainder maps to no group any source enumerates. Ignored when ayadiText is manasara, which has one vyaya formula. | p9-10 |
| circumference | No | Circumference or height, if the Manasara vara and tithi formulas should read something other than the perimeter. Defaults to the perimeter, which is what a rectangular plan supplies. |
| Name | Required | Description |
|---|---|---|
| vayas | Yes | |
| vargas | Yes | |
| verdict | Yes | |
| measures | Yes | |
| conventions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true and destructiveHint=false, the safety profile is already covered by annotations, and the description adds rich behavioral context: six formulas with multiplier, divisor, remainder, member names, two verdict rules, family disagreements, unit-sensitive remainders, and conversion behavior to whole cubits for feet/metres. It also mentions the compact output shape, which is beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tight sentences with no filler. It front-loads the result an agent can expect, then gives the key choices and the intended use case, making every sentence earn its place.
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?
Given that an output schema exists and all 10 parameters are fully documented in the input schema, the description covers the remaining context: what the tool calculates, why the text families matter, unit-sensitivity, and who should use it. Nothing critical for selecting or invoking the tool is missing.
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?
The schema describes every parameter at 100% coverage, so the baseline is 3. The description reinforces the conceptual model behind unit, ayadiText, and hastaInches, but it does not add significant parameter-level meaning beyond what the schema already provides.
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 opens with a specific verb ('returns') and resource ('all six proportional formulas') and immediately names the domain as an 'Ayadi shadvarga calculator for a building or a room'. It clearly distinguishes the tool from the Vastu sibling tools by describing the exact computation and judgment output rather than restating the title.
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 description states the intended contexts: practitioner tools, plan checking software, and anyone who has to justify a dimension. It explains the key choice between three text families and the unit-sensitivity caveat, but it does not explicitly name when not to use it or compare it to sibling tools; the distinct sibling names make the target use unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| 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. |
| Name | Required | Description |
|---|---|---|
| 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 |
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.
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.
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.
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.
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.
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.
Vastu Purusha Mandala projected over a real plot: send the ground and the API returns every square with the devata holding it, the brahmasthan as a polygon you can draw, the marma points, the six vamsa diagonals named by their devatas and the nine atimarma crossings. Choose the 81 pada Paramasayika or the 64 pada Manduka, and the response says which verses each part rests on. Built for floor plan overlays, practitioner reports and any tool that has to place rooms against the classical grid.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. | |
| 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. |
| Name | Required | Description |
|---|---|---|
| grid | Yes | |
| cells | Yes | |
| marma | No | |
| vamsa | No | |
| sources | Yes | |
| atimarma | No | |
| brahmasthan | Yes | |
| conventions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true and destructiveHint=false already covering the safety profile, the description adds behavioral substance: it projects over a real plot, returns per-square devata data, a drawable brahmasthan, marma points, and verse references. There is no contradiction with 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each carrying distinct information: what the API returns, the grid-choice and verse-reference behavior, and intended use cases. It is dense but not bloated; no sentence is 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 complex tool with nested plot input and an output schema, the description covers the essential mental model and practical purpose without having to restate return shapes. The remaining gaps, such as rectangle-versus-polygon selection details, are fully handled by the 100%-covered schema.
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 baseline applies. The description adds conceptual framing ('send the ground', 'Choose the 81 pada Paramasayika or the 64 pada Manduka') but no parameter detail that the schema does not already provide.
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 operation: 'Vastu Purusha Mandala projected over a real plot' and enumerates the returned artifacts (squares with devatas, brahmasthan polygon, marma points, vamsa diagonals, atimarma crossings). It is clear enough to distinguish this mandala-geometry tool from the sibling devata/direction endpoints, though it never names a sibling explicitly.
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 concrete intended contexts: 'Built for floor plan overlays, practitioner reports and any tool that has to place rooms against the classical grid.' It does not, though, state when to prefer this over siblings like post_vastu_plot or get_vastu_devatas, and there are no explicit when-not-to-use caveats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| cuts | No | Quarters where a corner is missing from the rectangle. Every cut verdict is convention, for the same reason as the extensions. | |
| 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. | |
| road | No | Which 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. | |
| water | No | Which 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. | |
| 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. | |
| extensions | No | Quarters 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. | |
| slopeSchool | No | Which 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 |
| 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. | |
| slopeLowDirection | No | Which 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. |
| Name | Required | Description |
|---|---|---|
| cuts | Yes | |
| road | No | |
| ratio | Yes | |
| shape | Yes | |
| slope | No | |
| water | No | |
| sources | Yes | |
| dimensions | Yes | |
| extensions | Yes | |
| conventions | Yes | |
| orientation | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation read-only and non-destructive. The description adds genuine behavioral value on top: every verdict either names the chapter and verse behind it or says plainly that it is convention, and the ground-level analysis is run under two schools whose real disagreement is surfaced rather than hidden. Nothing contradicts the read-onlyHint=true profile.
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, each earning its place: inputs/outputs in sentence one, the citation-and-convention behavior plus the two-school disagreement in sentence two, and target users in sentence three. The purpose is front-loaded in the first clause, and there is zero filler for a tool of this complexity.
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 tool is complex — 11 parameters, a nested plot object, and multiple enums — but the description is complete because the schema and output schema carry the structural weight: 100% parameter coverage, per-field explanations, and a documented return shape. The description covers purpose, key output behavior, and use cases; only an explicit pointer to sibling tools for non-plot analysis is absent, which is a mild 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 100%, so the baseline is 3 — the schema itself documents all 11 parameters in unusual depth (slopeSchool's two-school explanation, facingDegrees' feng shui convention, unit's scale-free mandala note). The tool description only maps high-level input categories ('outline, facing, ground fall, water') and adds no parameter-level meaning beyond the schema, so the baseline correctly holds.
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 opening line names the verb and resource — 'Vastu plot analysis from typed geometry' — then enumerates the exact inputs (outline, facing, ground fall, water) and the verdicts returned (shape, proportion, ground level under two schools, corner extensions/cuts, road, water). The plot/site domain is unmistakably distinct from siblings like post_vastu_rooms and post_vastu_entrance, so an agent can select 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?
The closing sentence gives concrete application contexts — 'listing and land assessment tools, practitioner site reports and buyer facing checks' — which is clear when-to-use guidance. It stops short of explicitly naming sibling exclusions (e.g., 'for room-level checks use post_vastu_rooms'), so cross-tool routing must be inferred from the domain rather than stated; with eight vastu siblings, an explicit pointer would have pushed this to 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Vastu room direction check for a whole floor plan: send the plot and a list of rooms, by quarter or by outline, and the API returns a verdict per room with the quarters it belongs in, the quarters to keep it out of, a remedy when it is misplaced, and a composite score with the weights published. Four of the twelve room types carry a chapter and verse and the other eight are labelled convention, so a report can say which half of it is classical. Built for floor plan tools, listing checks and practitioner reports.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. | |
| rooms | Yes | The rooms to check, 1 to 24 of them. Each carries a type and either the quarter it sits in or its outline. | |
| 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. | |
| 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. |
| Name | Required | Description |
|---|---|---|
| rooms | Yes | |
| score | Yes | |
| facing | Yes | |
| scoring | Yes | |
| sources | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds useful behavioral context about the response: the distinction between four classical room types with verse and eight convention-based, and the composite score with published weights. This goes beyond annotations and helps the agent set expectations.
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 a single dense paragraph but every clause adds value: purpose, inputs, outputs, classical/convention nuance, and use cases. It front-loads the main purpose and stays concise given the tool's complexity. No redundant 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 an output schema present, the description does not need to detail return formats. It covers the required inputs (plot and rooms), the response elements (verdict, quarters, remedy, score), and the unique classical/convention distinction. It is complete enough for an agent to call the tool correctly.
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 all parameters are well-documented in the schema. The description adds a high-level mention of 'by quarter or by outline' which maps to direction and polygon parameters, but it does not add parameter-specific details beyond what the schema already provides. 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 clearly states the action (Vastu room direction check) on a specific resource (a whole floor plan), lists the inputs (plot and list of rooms) and the detailed outputs (verdict, quarters, remedy, composite score). It is distinct from sibling tools like post_vastu_entrance or get_vastu_directions by focusing on room placement compliance.
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 description mentions it is 'built for floor plan tools, listing checks and practitioner reports,' giving a usage context. However, it does not explicitly contrast with alternatives or state when not to use this tool versus siblings like post_vastu_entrance, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Griha pravesh muhurta search over a date window: send the window and the place, and the API returns every day that clears the classical day-level rules, with the nakshatra, tithi, weekday and solar position that qualified it and the rule ids that admitted it. Two Muhurta texts disagree on the admissible nakshatras and you choose which one leads, and the rules a date search cannot settle are published rather than dropped. Built for house warming date pickers, practitioner scheduling and agent assistants that have to answer when a family should move in.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 |
| 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. | |
| endDate | Yes | Last day of the search window, in YYYY-MM-DD, inclusive. The window is capped at 93 days, which is a full season and the same cap the Vedic auspicious day search carries. | |
| latitude | Yes | Latitude of the house, in decimal degrees, positive north. Sunrise decides where one day ends and the next begins, so a nakshatra running out during the morning changes which day it counts for. | |
| timezone | Yes | IANA name (e.g. "America/New_York", "Europe/London", "UTC"), decimal hours (e.g. -5 for EST, 1 for CET), or a fixed UTC offset (e.g. "-05:00", "+01:00"). Prefer the IANA name: it is resolved to the offset in force at the birth date and time, historical daylight-saving rules included, while a fixed offset or decimal is taken literally and will be wrong if it does not match the daylight-saving state at that moment. On a transition day a time in the repeated hour is read as its first occurrence and a time in the skipped hour is moved forward past the gap. Invalid timezones return 400 with a validation error. | |
| longitude | Yes | Longitude of the house, in decimal degrees, positive east. | |
| startDate | Yes | First day of the search window, in YYYY-MM-DD. Every limb is read at sunrise of the local day, because the Hindu day begins at sunrise rather than at midnight. | |
| muhurtaText | No | Which Muhurta text supplies the admissible nakshatras for entering a new house. muhurta-chintamani admits eight and kalaprakasika admits twelve; seven overlap and are the high confidence core, one is unique to the first and five to the second. The two texts are independent witnesses, which is what makes the overlap strong and the difference worth exposing. Defaults to muhurta-chintamani. | muhurta-chintamani |
| Name | Required | Description |
|---|---|---|
| days | Yes | |
| rules | Yes | |
| total | Yes | |
| window | Yes | |
| sources | Yes | |
| conventions | Yes | |
| rejectionsByRule | Yes | |
| leftToTheAstrologer | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's emphasis on returning data without mutation aligns. It adds substantial behavioral context beyond the annotations: the API exposes disagreement between two Muhurta texts (muhurta-chintamani vs kalaprakasika) and the user chooses which leads, and it 'publishes rather than drops' rules a date search cannot settle. This gives an agent a clear model of the tool's decision logic and output philosophy.
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 three sentences, each earning its place: the first defines the search and its outputs, the second explains the text-disagreement and rule-handling behavior, and the third lists use cases. It is front-loaded with the core purpose and avoids redundancy. Slightly verbose but not bloated.
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?
Given the presence of an output schema (not shown but known to exist) and the richly described input schema (100% coverage), the description provides a complete high-level overview. It mentions the return fields, the text-selection mechanism, and the rule-publishing behavior. It does not mention the 93-day window cap or the exact rule lists, but those are in the schema, so the agent can find them. For a tool with 8 parameters and 5 required, this is adequately 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?
Schema description coverage is 100%, so every parameter is already documented in detail (e.g., timezone has a full explanation of IANA vs fixed offsets, latitude explains sunrise-based day boundaries). The tool description itself adds no parameter-specific semantics beyond the high-level mention of 'date window' and 'place,' which the schema already conveys. Baseline 3 is appropriate when the schema does the heavy lifting.
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 clearly states it is a 'Griha pravesh muhurta search over a date window' and explains what it returns: days clearing classical rules with nakshatra, tithi, weekday, solar position, and rule IDs. This distinguishes it from siblings (devatas, directions, ayadi, entrance, etc.), which are unrelated to date search.
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 description names its intended use cases: 'house warming date pickers, practitioner scheduling and agent assistants that have to answer when a family should move in.' It does not explicitly say when not to use it, but the sibling tools are topically distinct, making the appropriate context clear. The phrase 'search over a date window' implies a query for eligible dates rather than a single-date calculation.
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.
get_vastu_devatas2 fields changedInput schema / properties / offset / defaultAdded value: +0Input schema / properties / offset / minimumAdded value: +0get_vastu_directions2 fields changedInput schema / properties / offset / defaultAdded value: +0Input schema / properties / offset / minimumAdded value: +0get_vastu_devatas3 fields changedInput schema / properties / offset / defaultRemoved value: -0Input schema / properties / offset / minimumRemoved value: -0Input schema / properties / offset / typePrevious value: -[
- "integer",
- "null"
-]New value: +"integer"get_vastu_directions3 fields changedInput schema / properties / offset / defaultRemoved value: -0Input schema / properties / offset / minimumRemoved value: -0Input schema / properties / offset / typePrevious value: -[
- "integer",
- "null"
-]New value: +"integer"post_vastu_entrance2 fields changedInput schema / examplesAdded value: +[
+ {
+ "plot": {
+ "depth": 40,
+ "unit": "feet",
+ "width": 30
+ }
+ }
+]Input schema / properties / plot / exampleAdded value: +{
+ "depth": 40,
+ "unit": "feet",
+ "width": 30
+}post_vastu_mandala2 fields changedInput schema / examplesAdded value: +[
+ {
+ "plot": {
+ "depth": 40,
+ "unit": "feet",
+ "width": 30
+ }
+ }
+]Input schema / properties / plot / exampleAdded value: +{
+ "depth": 40,
+ "unit": "feet",
+ "width": 30
+}post_vastu_plot2 fields changedInput schema / examplesAdded value: +[
+ {
+ "plot": {
+ "depth": 40,
+ "unit": "feet",
+ "width": 30
+ }
+ }
+]Input schema / properties / plot / exampleAdded value: +{
+ "depth": 40,
+ "unit": "feet",
+ "width": 30
+}post_vastu_rooms1 field changedInput schema / properties / plot / exampleAdded value: +{
+ "depth": 40,
+ "unit": "feet",
+ "width": 30
+}get_vastu_devatas1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "devatas": {
+ "items": {
+ "properties": {
+ "cells": {
+ "items": {
+ "properties": {
+ "columnFromWest": {
+ "type": "number"
+ },
+ "rowFromNorth": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "rowFromNorth",
+ "columnFromWest"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "class": {
+ "enum": [
+ "perimeter",
+ "innerRing",
+ "innerCorner",
+ "center"
+ ],
+ "type": "string"
+ },
+ "entrancePada": {
+ "type": "number"
+ },
+ "group": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "padaCount": {
+ "type": "number"
+ },
+ "quadrant": {
+ "type": "string"
+ },
+ "role": {
+ "type": "string"
+ },
+ "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"
+ },
+ "squares": {
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ },
+ "verses": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "class",
+ "squares",
+ "cells",
+ "padaCount",
+ "role",
+ "verses",
+ "source"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "limit": {
+ "type": "number"
+ },
+ "offset": {
+ "type": "number"
+ },
+ "total": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "total",
+ "limit",
+ "offset",
+ "devatas"
+ ],
+ "type": "object"
+}get_vastu_devatas_id1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "cells": {
+ "items": {
+ "properties": {
+ "columnFromWest": {
+ "type": "number"
+ },
+ "rowFromNorth": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "rowFromNorth",
+ "columnFromWest"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "class": {
+ "enum": [
+ "perimeter",
+ "innerRing",
+ "innerCorner",
+ "center"
+ ],
+ "type": "string"
+ },
+ "entrancePada": {
+ "type": "number"
+ },
+ "group": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "padaCount": {
+ "type": "number"
+ },
+ "quadrant": {
+ "type": "string"
+ },
+ "role": {
+ "type": "string"
+ },
+ "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"
+ },
+ "squares": {
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ },
+ "verses": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "class",
+ "squares",
+ "cells",
+ "padaCount",
+ "role",
+ "verses",
+ "source"
+ ],
+ "type": "object"
+}get_vastu_directions1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "directions": {
+ "items": {
+ "properties": {
+ "devatas": {
+ "items": {
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "square": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "square",
+ "id",
+ "name"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "dikpala": {
+ "type": "string"
+ },
+ "element": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "kind": {
+ "type": "string"
+ },
+ "places": {
+ "type": "string"
+ },
+ "sources": {
+ "items": {
+ "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"
+ },
+ "type": "array"
+ },
+ "squares": {
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ },
+ "water": {
+ "properties": {
+ "auspiciousness": {
+ "type": "string"
+ },
+ "effect": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "effect",
+ "auspiciousness"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "id",
+ "dikpala",
+ "kind",
+ "squares",
+ "devatas",
+ "water",
+ "sources"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "limit": {
+ "type": "number"
+ },
+ "offset": {
+ "type": "number"
+ },
+ "total": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "total",
+ "limit",
+ "offset",
+ "directions"
+ ],
+ "type": "object"
+}get_vastu_directions_id1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "devatas": {
+ "items": {
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "square": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "square",
+ "id",
+ "name"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "dikpala": {
+ "type": "string"
+ },
+ "element": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "kind": {
+ "type": "string"
+ },
+ "places": {
+ "type": "string"
+ },
+ "sources": {
+ "items": {
+ "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"
+ },
+ "type": "array"
+ },
+ "squares": {
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ },
+ "water": {
+ "properties": {
+ "auspiciousness": {
+ "type": "string"
+ },
+ "effect": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "effect",
+ "auspiciousness"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "id",
+ "dikpala",
+ "kind",
+ "squares",
+ "devatas",
+ "water",
+ "sources"
+ ],
+ "type": "object"
+}post_vastu_ayadi1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "conventions": {
+ "properties": {
+ "ayadiText": {
+ "type": "string"
+ },
+ "hastaInches": {
+ "type": "number"
+ },
+ "unit": {
+ "type": "string"
+ },
+ "vyayaFormula": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "ayadiText",
+ "vyayaFormula",
+ "unit",
+ "hastaInches"
+ ],
+ "type": "object"
+ },
+ "measures": {
+ "properties": {
+ "area": {
+ "type": "number"
+ },
+ "breadth": {
+ "type": "number"
+ },
+ "circumference": {
+ "type": "number"
+ },
+ "length": {
+ "type": "number"
+ },
+ "perimeter": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "length",
+ "breadth",
+ "perimeter",
+ "circumference",
+ "area"
+ ],
+ "type": "object"
+ },
+ "vargas": {
+ "items": {
+ "properties": {
+ "auspicious": {
+ "type": "boolean"
+ },
+ "divisor": {
+ "type": "number"
+ },
+ "firstName": {
+ "type": "string"
+ },
+ "gloss": {
+ "type": "string"
+ },
+ "groupSize": {
+ "type": "number"
+ },
+ "multiplier": {
+ "type": "number"
+ },
+ "name": {
+ "type": "string"
+ },
+ "operand": {
+ "type": "string"
+ },
+ "operandValue": {
+ "type": "number"
+ },
+ "product": {
+ "type": "number"
+ },
+ "remainder": {
+ "type": "number"
+ },
+ "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"
+ },
+ "varga": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "varga",
+ "operand",
+ "operandValue",
+ "multiplier",
+ "divisor",
+ "product",
+ "remainder",
+ "groupSize",
+ "source"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "vayas": {
+ "type": "number"
+ },
+ "verdict": {
+ "properties": {
+ "ayaVyaya": {
+ "type": "string"
+ },
+ "reading": {
+ "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"
+ },
+ "yoniAuspicious": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "yoniAuspicious",
+ "ayaVyaya",
+ "reading",
+ "source"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "measures",
+ "vargas",
+ "vayas",
+ "verdict",
+ "conventions"
+ ],
+ "type": "object"
+}post_vastu_entrance1 field 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"
+}post_vastu_mandala1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "atimarma": {
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ },
+ "brahmasthan": {
+ "properties": {
+ "area": {
+ "type": "number"
+ },
+ "polygon": {
+ "items": {
+ "properties": {
+ "x": {
+ "type": "number"
+ },
+ "y": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "x",
+ "y"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "squares": {
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "squares",
+ "polygon",
+ "area"
+ ],
+ "type": "object"
+ },
+ "cells": {
+ "items": {
+ "properties": {
+ "center": {
+ "properties": {
+ "x": {
+ "type": "number"
+ },
+ "y": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "x",
+ "y"
+ ],
+ "type": "object"
+ },
+ "class": {
+ "enum": [
+ "perimeter",
+ "innerRing",
+ "innerCorner",
+ "center"
+ ],
+ "type": "string"
+ },
+ "columnFromWest": {
+ "type": "number"
+ },
+ "devata": {
+ "type": "string"
+ },
+ "devataName": {
+ "type": "string"
+ },
+ "group": {
+ "type": "string"
+ },
+ "role": {
+ "enum": [
+ "brahma",
+ "halved-inner-corner",
+ "halved-outer-corner",
+ "around-brahma",
+ "dvipada",
+ "outer"
+ ],
+ "type": "string"
+ },
+ "rowFromNorth": {
+ "type": "number"
+ },
+ "square": {
+ "type": "number"
+ },
+ "withinPlot": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "square",
+ "rowFromNorth",
+ "columnFromWest",
+ "center",
+ "withinPlot"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "conventions": {
+ "properties": {
+ "grid": {
+ "type": "string"
+ },
+ "unit": {
+ "enum": [
+ "feet",
+ "metres"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "grid",
+ "unit"
+ ],
+ "type": "object"
+ },
+ "grid": {
+ "type": "string"
+ },
+ "marma": {
+ "properties": {
+ "areaEach": {
+ "type": "number"
+ },
+ "points": {
+ "items": {
+ "properties": {
+ "x": {
+ "type": "number"
+ },
+ "y": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "x",
+ "y"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "points",
+ "areaEach"
+ ],
+ "type": "object"
+ },
+ "sources": {
+ "items": {
+ "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"
+ },
+ "type": "array"
+ },
+ "vamsa": {
+ "items": {
+ "properties": {
+ "axis": {
+ "type": "string"
+ },
+ "from": {
+ "properties": {
+ "x": {
+ "type": "number"
+ },
+ "y": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "x",
+ "y"
+ ],
+ "type": "object"
+ },
+ "fromDevata": {
+ "type": "string"
+ },
+ "fromSquare": {
+ "type": "number"
+ },
+ "isMainDiagonal": {
+ "type": "boolean"
+ },
+ "to": {
+ "properties": {
+ "x": {
+ "type": "number"
+ },
+ "y": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "x",
+ "y"
+ ],
+ "type": "object"
+ },
+ "toDevata": {
+ "type": "string"
+ },
+ "toSquare": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "fromSquare",
+ "fromDevata",
+ "toSquare",
+ "toDevata",
+ "axis",
+ "isMainDiagonal",
+ "from",
+ "to"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "grid",
+ "cells",
+ "brahmasthan",
+ "sources",
+ "conventions"
+ ],
+ "type": "object"
+}post_vastu_plot1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "conventions": {
+ "properties": {
+ "slopeSchool": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slopeSchool"
+ ],
+ "type": "object"
+ },
+ "cuts": {
+ "items": {
+ "properties": {
+ "auspiciousness": {
+ "type": "string"
+ },
+ "direction": {
+ "type": "string"
+ },
+ "effect": {
+ "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"
+ }
+ },
+ "required": [
+ "direction",
+ "auspiciousness",
+ "effect",
+ "source"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "dimensions": {
+ "properties": {
+ "area": {
+ "type": "number"
+ },
+ "breadth": {
+ "type": "number"
+ },
+ "length": {
+ "type": "number"
+ },
+ "ratio": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "length",
+ "breadth",
+ "area",
+ "ratio"
+ ],
+ "type": "object"
+ },
+ "extensions": {
+ "items": {
+ "properties": {
+ "auspiciousness": {
+ "type": "string"
+ },
+ "direction": {
+ "type": "string"
+ },
+ "effect": {
+ "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"
+ }
+ },
+ "required": [
+ "direction",
+ "auspiciousness",
+ "effect",
+ "source"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "orientation": {
+ "properties": {
+ "facing": {
+ "type": "string"
+ },
+ "facingDegrees": {
+ "type": "number"
+ },
+ "mountain": {
+ "type": "string"
+ },
+ "sitting": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "facing",
+ "sitting"
+ ],
+ "type": "object"
+ },
+ "ratio": {
+ "properties": {
+ "effect": {
+ "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"
+ },
+ "verdict": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "verdict",
+ "effect",
+ "source"
+ ],
+ "type": "object"
+ },
+ "road": {
+ "properties": {
+ "auspiciousness": {
+ "type": "string"
+ },
+ "direction": {
+ "type": "string"
+ },
+ "effect": {
+ "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"
+ }
+ },
+ "required": [
+ "direction",
+ "auspiciousness",
+ "effect",
+ "source"
+ ],
+ "type": "object"
+ },
+ "shape": {
+ "properties": {
+ "effect": {
+ "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"
+ },
+ "verdict": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "verdict",
+ "effect",
+ "source"
+ ],
+ "type": "object"
+ },
+ "slope": {
+ "properties": {
+ "chosen": {
+ "type": "string"
+ },
+ "highDirection": {
+ "type": "string"
+ },
+ "lowDirection": {
+ "type": "string"
+ },
+ "reading": {
+ "type": "string"
+ },
+ "schools": {
+ "items": {
+ "properties": {
+ "effect": {
+ "type": "string"
+ },
+ "school": {
+ "type": "string"
+ },
+ "verdict": {
+ "type": "string"
+ },
+ "verse": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "school",
+ "verdict",
+ "verse",
+ "effect"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "lowDirection",
+ "highDirection",
+ "reading",
+ "schools",
+ "chosen"
+ ],
+ "type": "object"
+ },
+ "sources": {
+ "items": {
+ "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"
+ },
+ "type": "array"
+ },
+ "water": {
+ "properties": {
+ "auspiciousness": {
+ "type": "string"
+ },
+ "direction": {
+ "type": "string"
+ },
+ "effect": {
+ "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"
+ }
+ },
+ "required": [
+ "direction",
+ "effect",
+ "auspiciousness",
+ "source"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "orientation",
+ "dimensions",
+ "shape",
+ "ratio",
+ "extensions",
+ "cuts",
+ "sources",
+ "conventions"
+ ],
+ "type": "object"
+}post_vastu_rooms1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "facing": {
+ "type": "string"
+ },
+ "rooms": {
+ "items": {
+ "properties": {
+ "avoidDirections": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "idealDirections": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "reading": {
+ "type": "string"
+ },
+ "remedy": {
+ "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"
+ },
+ "type": {
+ "type": "string"
+ },
+ "verdict": {
+ "type": "string"
+ },
+ "zone": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "type",
+ "zone",
+ "verdict",
+ "idealDirections",
+ "avoidDirections",
+ "reading",
+ "source"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "score": {
+ "type": "number"
+ },
+ "scoring": {
+ "properties": {
+ "avoidPoints": {
+ "type": "number"
+ },
+ "conventionWeight": {
+ "type": "number"
+ },
+ "idealPoints": {
+ "type": "number"
+ },
+ "neutralPoints": {
+ "type": "number"
+ },
+ "sourcedWeight": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "sourcedWeight",
+ "conventionWeight",
+ "idealPoints",
+ "neutralPoints",
+ "avoidPoints"
+ ],
+ "type": "object"
+ },
+ "sources": {
+ "items": {
+ "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"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "rooms",
+ "score",
+ "scoring",
+ "facing",
+ "sources"
+ ],
+ "type": "object"
+}post_vastu_timing_griha_pravesh1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "conventions": {
+ "properties": {
+ "muhurtaText": {
+ "type": "string"
+ },
+ "timezone": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "muhurtaText",
+ "timezone"
+ ],
+ "type": "object"
+ },
+ "days": {
+ "items": {
+ "properties": {
+ "admittedBy": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "ayana": {
+ "type": "string"
+ },
+ "date": {
+ "type": "string"
+ },
+ "karana": {
+ "type": "string"
+ },
+ "nakshatra": {
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "number",
+ "id",
+ "name"
+ ],
+ "type": "object"
+ },
+ "quality": {
+ "type": "string"
+ },
+ "reading": {
+ "type": "string"
+ },
+ "solarLongitude": {
+ "type": "number"
+ },
+ "sunrise": {
+ "type": "string"
+ },
+ "tithi": {
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ },
+ "paksha": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "number",
+ "name",
+ "paksha"
+ ],
+ "type": "object"
+ },
+ "vara": {
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "number",
+ "name"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "date",
+ "nakshatra",
+ "tithi",
+ "vara",
+ "ayana",
+ "solarLongitude",
+ "karana",
+ "quality",
+ "admittedBy",
+ "reading"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "leftToTheAstrologer": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "rejectionsByRule": {
+ "additionalProperties": {
+ "type": "number"
+ },
+ "type": "object"
+ },
+ "rules": {
+ "items": {
+ "properties": {
+ "confidence": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "requirement": {
+ "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"
+ }
+ },
+ "required": [
+ "id",
+ "requirement",
+ "confidence",
+ "source"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "sources": {
+ "items": {
+ "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"
+ },
+ "type": "array"
+ },
+ "total": {
+ "type": "number"
+ },
+ "window": {
+ "properties": {
+ "daysEvaluated": {
+ "type": "number"
+ },
+ "endDate": {
+ "type": "string"
+ },
+ "startDate": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "startDate",
+ "endDate",
+ "daysEvaluated"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "days",
+ "total",
+ "window",
+ "rejectionsByRule",
+ "rules",
+ "leftToTheAstrologer",
+ "sources",
+ "conventions"
+ ],
+ "type": "object"
+}post_vastu_timing_griha_pravesh1 field changedInput schema / properties / timezone / descriptionPrevious value: -"IANA name (e.g. \"America/New_York\", \"Europe/London\", \"UTC\"), decimal hours (e.g. -5 for EST, 1 for CET), or a fixed UTC offset (e.g. \"-05:00\", \"+01:00\"). Prefer the IANA name: it is resolved to the DST-correct offset for the birth date, while a fixed offset or decimal is taken literally and will be wrong if it does not match the daylight-saving state on that date. Invalid timezones return 400 with a validation error."New value: +"IANA name (e.g. \"America/New_York\", \"Europe/London\", \"UTC\"), decimal hours (e.g. -5 for EST, 1 for CET), or a fixed UTC offset (e.g. \"-05:00\", \"+01:00\"). Prefer the IANA name: it is resolved to the offset in force at the birth date and time, historical daylight-saving rules included, while a fixed offset or decimal is taken literally and will be wrong if it does not match the daylight-saving state at that moment. On a transition day a time in the repeated hour is read as its first occurrence and a time in the skipped hour is moved forward past the gap. Invalid timezones return 400 with a validation error."get_vastu_devatasget_vastu_devatas_idget_vastu_directionsget_vastu_directions_idpost_vastu_ayadipost_vastu_entrancepost_vastu_mandalapost_vastu_plotpost_vastu_roomspost_vastu_timing_griha_praveshVedic astrology (Jyotish): birth charts, divisional charts, dashas, yogas, transits, panchang
Free Vedic astrology: panchang, kundali, transits, matching, doshas, eclipses, numerology
30 Vedic Jyotish tools: natal charts, dashas, yogas, nakshatras. Swiss Ephemeris.
Jyotish, Panchang, Hindu festival and Sanatan Dharma knowledge tools with citations.
Add one secure layer between your agents and this server.
