Vastu entrance padas, the 81 pada mandala, plot and room analysis, Ayadi and griha pravesh timing.
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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint/destructiveHint annotations, the description discloses a notable behavioral trait: when source texts disagree, the response says so rather than silently choosing a side. It also labels the endpoint 'pure reference,' reinforcing that no side effects or calculations occur.
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 dense sentences: the first defines data content, the second frames the use case and safety posture, and the third communicates a data-quality caveat. No filler or redundancy; the important scope 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 is complete for a read-only reference list: it names the payload fields, explains the use cases, warns about contradictions, and leaves parameter details to the fully described schema. No output schema exists, but the stated row fields give an agent enough to interpret the result.
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?
Input schema covers 100% of parameters with descriptions, so the baseline is 3. The tool description itself adds nothing about lang, limit, offset, or compact, but it does not need to because the schema already documents them adequately.
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 title and description state a specific action and resource: list all 45 devatas in the Vastu Purusha Mandala. It enumerates the exact fields in each row (grid squares, ring, side, pada count, source verses), and 'pure reference endpoint with no plot required' plus the list scope separates it from single-resource getters and plot/post siblings.
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 explicit use cases ('for building a mandala diagram or a glossary') and characterizes the endpoint as a pure reference, implying it should be chosen for lookups rather than plot generation. It does not explicitly name alternatives such as post_vastu_plot or get_vastu_devatas_id, so the exclusion is clear but not exhaustive.
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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description is consistent with those. It adds value by disclosing id normalization ('Case and punctuation in the id are folded...') and the specific fields returned.
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?
Two sentences with no filler: the first sentence captures the action and the returned data, and the second adds the id-matching behavior. Dense but scannable.
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?
Because there is no output schema, the description compensates by summarizing the returned fields (squares, ring/side, pada count, entrance pada, verses). It is complete enough for selection and invocation, though it does not describe response format or not-found behavior.
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 itself already documents id, lang, and compact fully. The description's id-folding note is useful but repeats what the id parameter description already states, so it adds no significant new parameter semantics.
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 specific verb and resource: 'Look up one devata of the Vastu Purusha Mandala', and enumerates the exact data returned. The singular 'one devata' distinguishes it from the plural sibling 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?
The singular scope ('Look up one devata') makes the primary use case clear and implicitly separates it from the collection-style sibling get_vastu_devatas. It does not explicitly state when-not-to-use or name alternatives, 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. |
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 useful behavioral detail beyond annotations: it is a pure reference endpoint, requires no plot, cites verses per row, and labels elements as a later convention. This helps an agent know what kind of response and content to expect 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 three sentences and front-loads the core purpose and content of the endpoint. Each sentence contributes meaningful information: content, intended use, and provenance labeling. It is slightly dense but remains appropriately sized for the richness of the reference data it describes.
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 is complete for a simple read-only reference endpoint: it explains what fields rows contain, confirms no plot is needed, and provides the intended use case. The input schema covers pagination and localization, and annotations cover safety. With no output schema, the description partially compensates by listing the meaningful data elements, though it does not describe exact response shape.
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 four parameters are fully documented in the input schema itself. The description does not add parameter-level detail, but it does not need to because the schema already explains lang, limit, offset, and compact with defaults and examples.
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 defines the tool as a reference table of the eight Vastu directions and enumerates exactly what each row contains: dikpala, mandala squares, devatas, chapter placement, and water effects. It also separates this from plot-related endpoints by calling it a 'pure reference endpoint with no plot required.' This makes its purpose and scope unambiguous.
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 picker or a directions guide.' It also implies when not to use it by saying 'no plot required,' distinguishing it from the post_vastu_plot family. It does not explicitly name alternatives or list exclusion conditions, but the context is sufficient for an agent to choose effectively.
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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true and destructiveHint=false, and the description reinforces a non-mutating lookup. It adds behavior not in annotations: id case/punctuation folding with examples, and that the id namespace is shared with feng shui/I Ching endpoints. This is useful operational context 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?
Two sentences, both meaningful: the first itemizes what the lookup returns, the second gives id-normalization behavior and namespace consistency. Information is front-loaded and there is no filler. Minor opacity in 'what the chapter places there' keeps it from a top score.
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-id lookup with three well-schema'd params and no output schema, the description covers what is returned and key invocation quirks. It does not describe the response shape, but the absence of an output schema is mitigated by listing the content categories. The invocable details (enums, lang fallback, compact) are already in the schema, so nothing critical 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 schema already documents id, lang, and compact in detail. The description repeats the id folding already in the schema but adds the cross-endpoint id-space consistency. No further parameter explanation is necessary.
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 Vastu direction') and itemizes the returned content: dikpala, mandala squares and devatas, chapter placement, and standing water meaning. The word 'one' plus the id suffix distinguishes it from the plural list endpoint get_vastu_directions. No ambiguity about what it does.
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 clearly conveys single-entry lookup ('one direction'), which implies use when a specific direction's details are needed rather than a list. It does not explicitly name get_vastu_directions as the alternative or state when-not-to-use, so it falls short of the strongest guidance. The shared-id-space note helps an agent know it is consistent with feng shui and I Ching endpoints, but is not a full routing rule.
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. |
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 meaningful behavioral context beyond that: it discloses that the three text families genuinely disagree, that every remainder is unit sensitive, and that feet/metres are converted using hastaInches and rounded to whole cubits. It also states that the response shows remainders, member names, and two verdict rules, and that utpala falls back to the perimeter family. This is rich behavioral disclosure that helps an agent predict output shape and edge cases.
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: the first states the core function and return contents, the second gives selection guidance for text families and cubit length. Every clause earns its place, and the most decision-relevant information (text families disagree, unit sensitivity) is front-loaded. It is detailed without being bloated, and it does not repeat schema content verbatim.
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 10-parameter calculator with no output schema, this description is remarkably complete. It tells the agent what inputs matter, why they matter, what the output will contain (all six formulas, multiplier, divisor, remainder, member names, two verdict rules), and how to choose among the natural options. The absence of an output schema is mitigated by the description's explicit statement of return contents. There is no obvious missing context that would prevent correct invocation.
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 already 3, and the schema descriptions are unusually thorough: they explain which formulas each parameter feeds, default conventions, unit conversion behavior, and ignored cases. The tool description adds additional semantic context by highlighting unit sensitivity and the fact that the three text families disagree, which helps an agent understand why parameters like ayadiText and hastaInches matter. Minor deduction because the description itself doesn't enumerate parameters, but the schema already carries that weight, so a 4 is fair.
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: 'Ayadi shadvarga calculator for a building or a room: send the dimensions and the API returns all six proportional formulas.' It also distinguishes this tool from the sibling vastu tools by focusing on Ayadi proportions, yoni, and shadvarga rather than devatas, directions, entrances, mandalas, plots, rooms, or timing. It is unambiguous about what the tool computes and for whom.
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 explicitly states when to use this tool: for practitioner tools, plan checking software, and anyone justifying a dimension. It includes a clear decision about choosing among three text families because they genuinely disagree, and choosing a cubit length because remainders are unit sensitive. It names two alternatives (ayadiText families, perimeter vs. Manasara) and explains when each is appropriate. This is far beyond a typical vague 'use this for Ayadi calculations' and gives an agent actionable routing.
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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and non-destructive, so safety is covered. The description adds meaningful behavioral context: verdicts carry chapter and verse as typed fields, the analysis works on both the 81-pada and 64-pada grids, and the result includes favourable padas to move toward. This goes beyond what the schema or annotations alone state.
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, front-loaded with the core function and return value, followed by the scholarly sourcing guarantee and target use cases. Every sentence earns its place and adds a distinct piece of information without padding.
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 domain tool with no output schema, the description covers the essential outputs, the supported grid systems, the sourcing of verdicts, and the intended use cases. It does not enumerate response field names, but it gives enough conceptual detail for an agent to select and invoke the tool correctly with the schema filling in the rest.
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 schema already explains every parameter in detail, including coordinate conventions, units, exclusivity rules, and defaults. The tool description adds little parameter-level meaning, which is acceptable because the schema carries the full 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 verb and resource: it analyzes a main door and returns the 32-pada it falls on, its devata, the classical effect, and favourable alternative padas. This clearly separates it from sibling Vastu tools, which cover devatas, directions, mandalas, and rooms rather than entrance pada analysis.
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 application context: property tools, interior design products, practitioner reports, and any product that must judge whether a front door is well placed. It does not explicitly contrast this tool with siblings such as post_vastu_rooms or get_vastu_directions, so it stops short of a full when-not-to-use statement.
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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds meaningful behavioral detail: it lists what the response contains, including polygons, points, diagonals, crossings, and verse references. It accurately portrays a read-only projection operation 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 dense but well-structured, front-loading the core action and returning value before enumerating outputs and use cases. Every sentence earns its place, and the length is appropriate for the tool's 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?
With no output schema, the description does a good job explaining what the response contains and what the tool is for. It covers the main variants (81-pada vs 64-pada) and the practical use cases, though it avoids details like error conditions or unit behavior, which are partially covered by 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 description coverage is 100%, so the schema already documents every parameter thoroughly. The description reinforces the grid choice and output nature but does not add new parameter semantics beyond 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 clearly states what the tool does: it projects the Vastu Purusha Mandala over a real plot and returns devata-assigned squares, brahmasthan polygon, marma points, vamsa diagonals, and atimarma crossings. It is specific about the resource and outputs, though it does not explicitly contrast itself with sibling tools like get_vastu_devatas or post_vastu_rooms.
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 application context: 'Built for floor plan overlays, practitioner reports and any tool that has to place rooms against the classical grid.' It implies when to use this tool but does not explicitly state when not to use it or name alternatives.
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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only and non-destructive; the description adds valuable behavioral detail beyond that: every verdict either cites chapter and verse or explicitly labels itself convention, and the genuine disagreement between the verse-based ground-level reading and the modern rule is surfaced. This tells the agent what kind of epistemic output to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three front-loaded sentences cover purpose, output behavior, and intended use cases without bloating. The chapter-and-verse note earns its place because it explains a non-obvious output property that matters for interpreting results.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 11-parameter tool with no output schema, the description gives enough for an agent to select it and understand what comes back: verdict topics, sourcing behavior, and the two-school ground-level treatment. Remaining details like enum values, coordinate conventions, and compact mode are fully covered by the input schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters, including units, defaults, mutual exclusions, enums, and the width/depth vs polygon distinction. The top-level description only summarizes input categories and does not add parameter-level meaning beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Vastu plot analysis from typed geometry' and enumerates both inputs (outline, facing, ground fall, water) and outputs (shape, proportion, ground level under two schools, corner extension/cut, road, water). It clearly positions this as a whole-plot assessment tool, distinct from more specialized Vastu sibling tools like entrance, rooms, or mandala analyses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear intended contexts—'listing and land assessment tools, practitioner site reports and buyer facing checks'—which tells an agent when this tool is relevant. It does not explicitly name alternatives or state when not to use it, so it provides clear context without full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only and non-destructive, and the description adds substantial behavioral detail: per-room verdicts, quarters to avoid, remedies, weighted composite scores, and the classical-vs-convention split across room types. This goes well beyond what the annotations alone convey.
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 the core purpose, then describes the return payload, then adds the classical-vs-convention nuance and target use cases. Every sentence earns its place and there is no filler or repetition of the schema.
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 six-parameter tool with nested objects and no output schema, the description covers the main inputs, return fields, and use cases, while the schema covers parameter details. It lacks explicit sibling differentiation, but an agent has enough to select and invoke 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%, with detailed descriptions for lang, plot, rooms, facing, compact, and facingDegrees, so the baseline is 3. The description restates the high-level input pattern (plot plus a list of rooms, by quarter or outline) but adds no parameter-specific semantics beyond the rich 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 names a specific verb and resource: 'Vastu room direction check for a whole floor plan', and details the output: a verdict per room, acceptable and prohibited quarters, a remedy, and a composite score. This clearly separates it from sibling tools covering devatas, directions, mandala, entrance, ayadi, plot, and timing.
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 clearly conveys the intended context: send a plot plus rooms, and get compliance checks; it even names target use cases ('floor plan tools, listing checks and practitioner reports'). It does not explicitly name sibling alternatives or exclusion conditions, so it stops short of full usage routing.
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 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. | |
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true and destructiveHint=false in annotations, the description adds genuinely useful behavioral context beyond them: the two Muhurta texts disagree and the caller chooses which leads, and 'the rules a date search cannot settle are published rather than dropped.' These are non-obvious behaviors an agent needs to know. No contradiction with 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 earning its place: the first front-loads the core operation and output shape, the second explains the muhurtaText behavioral quirk, and the third states the audience. The first sentence is dense but information-packed rather than padded.
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?
Despite having no output schema, the description compensates by spelling out the return contents (nakshatra, tithi, weekday, solar position, rule ids). Together with fully documented parameters and a clear use case, an agent has what it needs to invoke the tool correctly. Minor gaps remain: no statement about the empty-result case or error behavior beyond the timezone 400 note 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 description coverage is 100%, so the baseline of 3 applies — the schema already documents all 8 parameters in detail, including the muhurta-chintamani vs kalaprakasika divergence (8 vs 12 nakshatras, 7 overlap). The description adds only the high-level 'send the window and the place' framing, which is helpful but not substantial beyond 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 names a specific verb and resource — 'Griha pravesh muhurta search over a date window' — and enumerates exactly what is returned (qualified days with nakshatra, tithi, weekday, solar position, rule ids). The tool's timing/muhurta focus clearly sets it apart from sibling tools about devatas, directions, ayadi, mandala, plot, entrance, and rooms.
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 explicit use contexts: 'Built for house warming date pickers, practitioner scheduling and agent assistants that have to answer when a family should move in.' This is clear when-to-use guidance, though it stops short of naming alternatives or stating when-not-to-use conditions relative to the sibling vastu tools.
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. Dates show when Glama detected each change.
get_vastu_devatasget_vastu_devatas_idget_vastu_directionsget_vastu_directions_idpost_vastu_ayadipost_vastu_entrancepost_vastu_mandalapost_vastu_plotpost_vastu_roomspost_vastu_timing_griha_praveshClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Vedic 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.
Each tool targets a distinct resource or analytical step: reference lookups (devatas, directions) are cleanly separated from computations (ayadi, entrance, mandala, plot, rooms, timing), and the list endpoints are distinguished from their _id counterparts by an explicit suffix. Although three post_ tools accept plot geometry, their outputs are mutually exclusive (grid overlay vs. property verdict vs. room-by-room check), and the descriptions state each purpose with enough precision to prevent misselection.
All ten tools follow a uniform lowercase snake_case pattern with a get_ or post_ prefix and the vastu domain token consistently in second position. The get_ prefix is reserved for read-only reference data while post_ marks computational endpoints, and the _id suffix uniformly marks single-item lookups, creating a highly predictable scheme.
Ten tools is a well-scoped count for a domain-specific server covering reference data, analysis, and timing. Each tool earns its place: the two list/detail pairs follow standard API practice without redundancy, and the six computational tools each address a distinct stage of Vastu analysis.
The tool surface covers the full Vastu consulting workflow: reference data (devatas, directions), land assessment (plot), grid projection (mandala), entrance validation, room placement, dimensional proportion checks (ayadi), and housewarming date selection (griha pravesh). The only notable gap is that timing is restricted to griha pravesh, leaving other Vastu-related muhurta events like construction commencement uncovered.
