Vastu entrance padas, the 81 pada mandala, plot and room analysis, Ayadi and griha pravesh timing.
Scored across 10 tools
Each tool maps to a distinct output: devata table vs. single devata, direction table vs. single direction, and six distinct analyzers (ayadi, entrance, mandala, plot, rooms, timing). Minor overlap remains between post_vastu_plot and post_vastu_entrance, since both consume plot geometry and relate to front-door/facing assessment, and between plot and mandala which both project over a plot.
A clear verb_resource pattern holds throughout: get_vastu_* for reference lookups and post_vastu_* for computation. The '-_id' suffix on the single-item lookups is a minor deviation rather than a clean get_vastu_devata singular form, and the get/post split is predictable.
Ten tools is well within the ideal range, and each earns its place as a distinct analyzer or reference lookup. There is no redundant filler or thin one-tool surface.
The surface covers reference data (devatas, directions) plus the core analytical lifecycle: plot, mandala, entrance, rooms, ayadi proportions, and timing. Gaps are minor — remedies only appear embedded inside post_vastu_rooms, and there is no standalone verse/glossary search or composite 'full report' aggregation tool.
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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds useful scope context — every verdict carries chapter and verse as a typed field, and the reading holds on both the 81 and 64 pada divisions — but nothing about latency, limits, or failure modes. Adequate rather than rich against a partly-covered bar.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and return payload in the first sentence; the sourcing and grid notes follow in a logical order. The closing 'Built for property and interior design tools…' sentence is partly marketing and only weakly functional, but it's a minor tax on an otherwise tight description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description needn't explain return values, and it doesn't need to — the schema fully documents the 8 nested/enum parameters. The description completes the picture by explaining what domain the analysis operates in (32 perimeter padas, both grid divisions) and its intended audience, though it could do more to route between the ten sibling Vastu endpoints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% across 8 params, so baseline is 3; the description still adds meaning by sourcing the grid option to Brihat Samhita 53.42/53.55 and clarifying that the reading is valid under either division. It also frames the input at a high level ('send the plot and where the door sits') without duplicating the exhaustive door/doorPosition/facing alternates that the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource — 'Vastu entrance analysis for a main door' — and enumerates exactly what the API returns (32-pada placement, devata, classical effect, favourable padas on the side). It's clearly a door/entrance tool, not a plot or mandala tool, but it never names any of its many siblings (post_vastu_plot, post_vastu_mandala, get_vastu_directions) to distinguish which one to use for what.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: 'Built for property and interior design tools, practitioner reports, and any product that has to say whether a front door is well placed' tells you the audience but not when to call this versus the sibling Vastu endpoints. There are no when-not conditions and no explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered; the description adds genuine substance about what gets computed and returned (devata assignments, brahmasthan polygon, verse citations). It says nothing about scale limits, irregular-plot handling, or latency, but those are secondary for a read-only generator.
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?
Front-loaded with the core action, then the payload, then the grid choice, then use cases — a sensible ordering. The second and third clauses are dense noun lists that border on run-on, but 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?
With an output schema present and annotations covering safety, the description's job is domain framing, which it does well — the concepts returned are named so an agent knows what the response means. The only gap is the lack of relative positioning among the several post_vastu_* siblings.
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% and the parameter docs are unusually rich (grid enum explained with Brihat Samhita verse numbers, plot geometry with axis conventions). The description restates the grid choice with framing but adds little the schema does not already carry; 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?
States a concrete verb and resource ("projected over a real plot: send the ground and the API returns...") and enumerates the return payload — devata per square, brahmasthan polygon, marma points, vamsa diagonals, atimarma crossings. That specificity separates it cleanly from siblings like post_vastu_plot (plot analysis) and post_vastu_rooms (room placement).
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?
Gives clear application contexts ("floor plan overlays, practitioner reports, any tool that has to place rooms against the classical grid") and notes the 81-pada vs 64-pada choice. It never explicitly says when to prefer it over post_vastu_plot or post_vastu_ayadi, so routing is implied rather than stated.
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?
Beyond the read-only annotations, the description discloses important behavior: verdicts cite chapter and verse or explicitly say they are convention, and the two ground-level schools genuinely disagree while both readings are returned. It also surfaces useful side details such as lossless compact output and English fallback for untranslated fields.
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 front-loaded with purpose and return behavior, then moves to sourcing caveats and usage context. It is dense but appropriately sized for a complex 11-parameter tool, with no clearly wasted sentences.
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 rich schema, output schema, and annotations, the description supplies enough context to call the tool correctly: it explains the input domain, the verdict scope, and the sourced-vs-convention distinction. The remaining gap is sibling routing and explicit alternative selection guidance.
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 schema already carries detailed parameter semantics for plot geometry, facing, slope, water, road, language, and compact mode. The description adds a useful high-level input summary but no additional meaning beyond what the structured schema 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 names a specific verb and resource: 'Vastu plot analysis from typed geometry,' then enumerates the core inputs and the verdicts returned. It clearly scopes the tool to land/site assessment, but does not explicitly distinguish it from sibling Vastu endpoints such as post_vastu_mandala or post_vastu_entrance.
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 usage context: 'Built for listing and land assessment tools, practitioner site reports and buyer facing checks.' This tells an agent when the tool is relevant, but it does not state when to choose it over sibling tools or mention any exclusions.
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 a safe read operation, so the bar is lower, and the description still adds substantive nuance: per-room verdicts, keep-out quarters, remedies, a weighted composite score, and the classical-vs-convention labelling split. It omits any mention of size limits, costs, or rate behaviour, keeping it short of a 5.
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 core action and its inputs are front-loaded and the sentences are dense with real information. The closing audience sentence ('Built for floor plan tools, listing checks and practitioner reports') is the weakest part, but the description is overall efficiently sized for a six-parameter nested tool.
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 covering return values and annotations covering safety, the description supplies the input shape, the quarter-vs-polygon choice, and the scoring/citation nuance an agent needs. Only the lack of routing relative to the nine sibling endpoints leaves a visible 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 phrase 'by quarter or by outline' restates the schema's direction-vs-polygon either/or but adds no syntax, unit, or edge-case detail beyond what the field descriptions 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 names a specific verb and resource ('Vastu room direction check for a whole floor plan') and states the inputs and return shape, which distinguishes it from the single-element siblings like post_vastu_entrance and post_vastu_plot without opening a 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?
'Built for floor plan tools, listing checks and practitioner reports' implies the audience and scenario, but there is no explicit when-to-use vs. when-to-use-a-sibling guidance — nothing tells the agent to prefer post_vastu_entrance for a single doorway check or post_vastu_mandala for the grid itself.
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.
post_vastu_entrance1 field changedInput schema / properties / plot / x-required-any-ofAdded value: +[
+ [
+ "width",
+ "depth"
+ ],
+ [
+ "polygon"
+ ]
+]post_vastu_mandala1 field changedInput schema / properties / plot / x-required-any-ofAdded value: +[
+ [
+ "width",
+ "depth"
+ ],
+ [
+ "polygon"
+ ]
+]post_vastu_plot1 field changedInput schema / properties / plot / x-required-any-ofAdded value: +[
+ [
+ "width",
+ "depth"
+ ],
+ [
+ "polygon"
+ ]
+]post_vastu_rooms2 fields changedInput schema / properties / plot / x-required-any-ofAdded value: +[
+ [
+ "width",
+ "depth"
+ ],
+ [
+ "polygon"
+ ]
+]Input schema / properties / rooms / items / x-required-any-ofAdded value: +[
+ [
+ "direction"
+ ],
+ [
+ "polygon"
+ ]
+]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_praveshVargas, dashas, panchang, shadbala, yogas, doshas, Jaimini, KP and Vastu Shastra.
Vedic astrology: birth charts, dashas, compatibility, transits and personal timing
Vedic astrology MCP: panchanga, kundli matching, muhurta, dashas.
Vedic astrology (Jyotish): birth charts, divisional charts, dashas, yogas, transits, panchang
Add one secure layer between your agents and this server.
