Ayurvedic constitution from a birth chart, dinacharya, ritucharya and dosha catalogues for agents.
Scored across 8 tools
Most tools are clearly distinct: doshas list/detail, qualities, tastes, constitution, dinacharya, and ritucharya each have separate purposes. The main ambiguity is get_ayurveda_daily, which is explicitly a convenience composition of dinacharya and ritucharya, but the descriptions clarify when to use it versus the dedicated routes.
All tool names follow a consistent snake_case get_ayurveda_/post_ayurveda_ prefix pattern, which makes the family identifiable. Minor deviations include the awkward get_ayurveda_doshas_id (plural resource plus _id suffix) and a get/post split that is not always semantically obvious since get_ayurveda_daily is also a computed result.
Eight tools is a well-scoped size for an Ayurveda reference and calculation API. Each tool covers a meaningful area—catalogues, routines, seasons, and constitution—without unnecessary duplication or bloat.
The domain is well covered: doshas have both list and detail endpoints, all three core catalogues (doshas, qualities, tastes) are exposed, and daily, seasonal, and constitution calculations are available. Minor gaps exist, such as no detail endpoints for qualities or tastes, but the full lists allow agents to work around that.
Get one days Ayurveda reading for a place: sunrise, the brahma muhurta window, the six dosha periods cut from the actual day and night, and the season the date falls in with where each dosha stands in its yearly cycle. It composes the routine and the season routes for one location so a widget needs one call rather than two. The default conventions apply throughout and are echoed; call those two routes directly to choose a different season scheme, zodiac, hemisphere or dosha clock.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Reading date in YYYY-MM-DD format. Past and future dates are both supported, for editorial scheduling and backfill. Defaults to the current day in the timezone parameter. | |
| 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. | |
| latitude | Yes | Latitude in decimal degrees. It sets how long the day and the night actually are, which is what the dosha periods are cut from. | |
| timezone | No | Selects which day counts as current when date is omitted, and which local day sunrise is computed for. Defaults to UTC, so the reading rolls over at 00:00 UTC. Accepts an IANA name (e.g. "Europe/London"), decimal hours (e.g. 5.5 for IST), or a fixed UTC offset (e.g. "-05:00"). | |
| longitude | Yes | Longitude in decimal degrees. It sets the clock time of sunrise at this place. |
| Name | Required | Description |
|---|---|---|
| date | Yes | |
| meta | Yes | |
| ritu | Yes | |
| sunset | Yes | |
| sources | Yes | |
| summary | Yes | |
| sunrise | Yes | |
| doshaCycle | Yes | |
| conventions | Yes | |
| doshaPeriods | Yes | |
| brahmaMuhurta | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal read-only and non-destructive behavior, and the description adds useful context: it composes two endpoints into one response, applies default conventions, and echoes those conventions back. There is no contradiction between the description and annotations. The only minor gap is that 'default conventions' and 'those two routes' are not spelled out explicitly, but the read-only safety profile is well covered.
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, front-loaded sentences: the first states the primary output, the second explains the composition value, and the third gives routing alternatives. There is no filler or repetition of schema content. The minor stylistic issue of 'one days' does not affect clarity.
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 names the main output components, explains the composition behavior, and points to alternatives for customization; the input schema fully covers parameter semantics and the output schema covers return-value details. It is complete enough for correct invocation. The indirect reference to 'those two routes' is the only point left to inference.
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?
All six parameters are fully documented in the input schema, so the description does not need to repeat their semantics. The top-level description adds no parameter-level detail beyond what the schema already provides, such as latitude affecting day/night length or timezone defaults. With 100% schema coverage, the baseline score of 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?
States exactly what the tool returns: one day's Ayurveda reading with sunrise, brahma muhurta, dosha periods, season, and dosha's yearly-cycle position. It also differentiates itself from siblings by explaining that it composes the routine and season routes so a widget needs one call instead of two. This is specific enough to select over get_ayurveda_doshas or the post_* routes.
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?
Explicitly tells the agent when to use this tool: when defaults are acceptable and a single composed response is desired. It also tells the agent when not to use it: call the two route alternatives directly to choose a different season scheme, zodiac, hemisphere, or dosha clock. This is clear, actionable routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return vata, pitta and kapha with the qualities, seats and five sub-doshas each carries, and the three states the seasonal cycle moves them through. Every quality is one of the twenty gunas and every state is described as a position and a quality rather than as a complaint, which is what lets the catalogue join to the tastes and qualities endpoints without a lookup table in between. Each entry carries the verse it comes from, and the second primary text is recorded where it reads the list differently.
| 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-3, default 3. | |
| 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 |
|---|---|---|
| meta | Yes | |
| limit | Yes | |
| total | Yes | |
| doshas | Yes | |
| offset | Yes | |
| sources | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds value by explaining the data model (gunas, states as positions/qualities) and its integration with other endpoints, but it does not describe pagination behavior, rate limits, or response format. It does not contradict 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, with the main purpose front-loaded. Each sentence provides meaningful context: the first states what is returned, the second explains the data structure's design rationale, and the third notes verse provenance. It is efficient with no wasted words.
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 tool's simple list nature, the output schema exists, and all parameters are documented, the description covers the data semantics thoroughly. It explains the content (doshas, gunas, states, verses) and the integration design. The only missing piece is explicit usage guidance, which is covered under that dimension. Overall, it is complete for a catalogue endpoint.
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?
All parameters (lang, limit, offset, compact) have full descriptions in the schema (100% coverage). The description adds nothing about parameters beyond what the schema provides. Baseline 3 applies since the schema carries 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 the tool returns vata, pitta, and kapha with their qualities, seats, sub-doshas, and states. This is a specific verb-resource pairing that distinguishes it from the ID-based sibling (get_ayurveda_doshas_id) by scope. The title 'Dosha catalogue API' reinforces the list nature.
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 does not explicitly say when to use this tool versus alternatives like get_ayurveda_doshas_id. However, it implies the catalogue scope by returning all three doshas, and the sibling names make the distinction obvious. It lacks explicit exclusions or alternative recommendations, but the context is sufficient for a reasonable agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return one dosha with its elements, qualities, seats, five sub-doshas and three states. Use it to render a dosha card or a glossary entry without pulling the whole catalogue, and read qualityGunas to join it to the twenty qualities.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Dosha identifier, case-insensitive. One of vata, pitta or kapha. | |
| 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 |
|---|---|---|
| meta | Yes | |
| dosha | Yes | |
| sources | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds behavioral context beyond annotations by listing exactly what fields the response contains and hinting at the qualityGunas join pattern, which helps an agent predict response structure and downstream use.
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, zero filler. The first sentence states the core behavior and content; the second delivers use cases and a cross-domain join hint. Information is front-loaded and every phrase 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?
With an output schema present and annotations covering safety, the description covers the remaining needs: when to use, what to expect, and how to connect to the qualities catalogue. The tool is simple and nothing needed for correct invocation 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 id, lang, and compact are already fully described with enums, defaults, and additional semantics. The description adds no parameter-specific meaning beyond the schema, so 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 opens with a specific verb-resource pair: "Return one dosha" with listed content (elements, qualities, seats, five sub-doshas, three states). It also distinguishes from siblings by contrasting "without pulling the whole catalogue", which clearly separates it from get_ayurveda_doshas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete use cases: "render a dosha card or a glossary entry" and explains the benefit over fetching all doshas. It implies get_ayurveda_doshas as the alternative but does not name it explicitly or state when not to use it, so it falls 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.
Return the twenty gunas, the qualities of Ayurveda, as the ten opposed pairs the commentaries spell out, each member with the single action word attached to it, and the half-verse that states the like-increases-like rule the whole domain runs on. Each quality carries the doshas that hold it, so the pairs join straight to the dosha catalogue. One pair carries a recorded disagreement between the two commentaries, and the response states it rather than resolving it silently, because the choice decides which dosha that pair joins to.
| 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-10, default 10. | |
| 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 |
|---|---|---|
| meta | Yes | |
| rule | Yes | |
| limit | Yes | |
| pairs | Yes | |
| total | Yes | |
| offset | Yes | |
| sources | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only annotations, the description discloses important non-obvious behavior: one pair carries a recorded disagreement between commentaries and the response 'states it rather than resolving it silently,' because it determines dosha linkage. It also explains that qualities carry doshas and the governing rule, adding real context the annotations do not provide.
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 front-loaded with the core action and all sentences carry substantive information. Some clauses are ornate, but nothing is filler or redundant with 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?
With an output schema present and all parameters documented in the input schema, the description fills the remaining contextual gaps: content structure, paired organization, dosha linkage, and the special handling of a disputed pair. Nothing an agent needs to call this correctly 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 schema fully documents lang, limit, offset, and compact. The description adds no additional parameter-level meaning, making the baseline 3 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 verb and resource: 'Return the twenty gunas' as ten opposed pairs with action words and a half-verse rule. This clearly distinguishes the tool from sibling tools like get_ayurveda_doshas and get_ayurveda_tastes by its unique content and structure.
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 implies the tool is for retrieving the twenty Ayurvedic qualities but never explicitly states when to choose it over alternatives or when not to use it. The domain-level content makes the niche inferable, but there are no exclusions or direct comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the six rasas, the tastes of Ayurveda, with the complete eighteen-cell matrix of which taste lowers and raises which dosha, in both directions. The order is the one the root verse gives, which is also the order of strength it states, and it puts bitter before pungent where most modern lists reverse them. The matrix is returned on each taste and again as a per-dosha index, so a caller can read it either way without deriving one from the other.
| 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-6, default 6. | |
| 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 |
|---|---|---|
| meta | Yes | |
| limit | Yes | |
| rasas | Yes | |
| total | Yes | |
| matrix | Yes | |
| offset | Yes | |
| sources | Yes | |
| strengthOrder | 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 valuable behavioral context: the ordering rationale (root verse, bitter before pungent), the dual representation (per-taste and per-dosha index), and the fact that both are returned without derivation. This goes beyond the annotations and helps the agent understand the response shape.
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 states the core content, the second explains the ordering rationale, the third describes the dual matrix representation. Front-loaded with the primary purpose, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, read-only annotations, and 100% schema coverage for parameters. The description adds the ordering context and dual-representation detail that an agent needs to interpret the response correctly. Nothing essential is missing for a read-only list tool.
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 four parameters thoroughly. The description doesn't add parameter-specific details beyond what the schema provides, but it doesn't need to. Baseline 3 is correct when 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 states a specific verb ('Return') and resource ('the six rasas... with the complete eighteen-cell matrix'), and distinguishes itself from siblings by naming the exact content and ordering. It clearly differentiates from get_ayurveda_doshas and get_ayurveda_qualities by focusing on tastes and the dosha matrix.
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 implies when to use this tool: when a caller needs the rasa-dosha matrix in both directions, with a specific traditional order. It doesn't explicitly name alternatives or exclusions, but the context signals and sibling list make the use case clear. A 4 is appropriate because it provides clear context without explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the Ayurvedic constitution from a sidereal birth chart and return the vata, pitta and kapha shares with a verse behind every factor. Three factors are scored, each one carrying a classical rule that it shows the native humour: the rising sign, the sign the Moon occupies, and the strongest graha by shadbala. The composite that blends them is a RoxyAPI convention rather than a classical one, so its version and its weights ship inside the response, and every response states that this is general wellness and cultural interest only.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Birth date in YYYY-MM-DD format. It sets the sidereal positions the whole reading is built from, so an approximate date gives an approximate constitution. | |
| 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 |
| time | Yes | Birth time in 24-hour HH:MM:SS format. The rising sign turns roughly every two hours and carries the heaviest weight of the three factors, so time is the input a reading is most sensitive to. | |
| 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. | |
| ayanamsa | No | Sidereal frame the chart is cast in. "lahiri" is the traditional Vedic standard used by most software and is the default. "raman" sits about 1.45 degrees below it. "kp-newcomb" and "kp-old" are the two Krishnamurti Paddhati frames. "custom" takes your own value in degrees via ayanamsaValue. The frame rotates the whole zodiac, so a graha within 1.45 degrees of a boundary can change rashi when you switch, which moves both sign factors of the reading. | lahiri |
| latitude | Yes | Birth latitude in decimal degrees. It sets the local sidereal time behind the rising sign, and it feeds the strength of each graha through the sunrise at that place. | |
| timezone | No | Timezone as an IANA name such as "Asia/Kolkata", or as decimal hours from UTC such as 5.5. An IANA name is resolved to the offset in force on the birth date, so a summer-time birth is placed correctly. Defaults to 5.5. | |
| longitude | Yes | Birth longitude in decimal degrees. It sets the local sidereal time behind the rising sign, together with the latitude. | |
| ayanamsaValue | No | Custom sidereal frame value in degrees. Required when ayanamsa is "custom" and ignored otherwise. Use it to reconcile exactly against a specific reference program. | |
| signDoshaScheme | No | Which classical sign table the rising sign and the Moon sign are read through. "satyacharya" is the twelve-sign extract appended to Brihat Jataka 18.20, carried in two independent public-domain translations that agree on all twelve rows, and is the default. "bphs" is the Brihat Parasara Hora Sastra rule by elemental triplicity. The two agree exactly on three signs of twelve, overlap in part on seven, and share no humour at all on Scorpio or Sagittarius, so the choice can change the reading outright and is echoed in the response. | satyacharya |
| Name | Required | Description |
|---|---|---|
| meta | Yes | |
| frame | Yes | |
| factors | Yes | |
| summary | Yes | |
| moonSign | Yes | |
| composite | Yes | |
| lagnaSign | Yes | |
| conventions | Yes | |
| planetDoshas | Yes | |
| strengthRanking | 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 valuable behavioral context beyond that: the composite is a RoxyAPI convention (not classical) and its version/weights are shipped in the response, plus the disclaimer that responses state general wellness/cultural interest only. These are meaningful non-obvious behaviors that an agent benefits from knowing before calling.
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 and gets straight to the point: purpose, factors, and a caveat. It is front-loaded with the core action and output, then elaborates on the composite convention. It is efficient without being overly terse, though it packs several clauses into a single long second sentence, which slightly reduces readability.
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 tool's complexity (10 parameters, 3 enums, multiple configuration options) and the presence of an output schema, the description covers the essential behavioral context: the three scored factors, the non-classical composite, and the disclaimer. It does not mention error conditions or pagination, but for a read-only tool with an output schema, these are minor omissions. The description is complete enough for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents every parameter in detail. The description does not add parameter-specific semantics beyond the schema—for example, the sensitivity of time is already explained in the time parameter's description. The description focuses on the overall algorithm rather than individual parameters, so it adds minimal value on top of the schema, warranting the baseline score of 3.
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 ('Read') and resource ('Ayurvedic constitution from a sidereal birth chart'), and clearly states the output (vata, pitta, kapha shares with a verse). It distinguishes itself from sibling tools like get_ayurveda_doshas by focusing on the birth-chart-derived constitution, making it unambiguous which tool an agent should pick.
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 implies the use case (birth chart analysis) but does not explicitly contrast with siblings such as get_ayurveda_doshas or get_ayurveda_daily. There is no 'use this instead of X' guidance or exclusions. An agent can infer when to use it from the resource type, but the description leaves the alternative-selection logic to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute the dinacharya daily routine for one date and one place: sunrise, sunset, the brahma muhurta window, and the six dosha periods of the day and the night. The default division cuts the actual day and the actual night into thirds, which is what the frame chapter states, and the modern clock grid is returned alongside it under its own label so a caller can show either. The brahma muhurta is a fixed window of 96 to 48 minutes before sunrise rather than a share of the night, which is the reading the classical commentary settles on.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | The local calendar date, in YYYY-MM-DD format. Sunrise and sunset are computed for this date at the given place, and the whole routine follows from them, so the answer changes through the year at any latitude away from the equator. | |
| 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. | |
| latitude | Yes | Latitude in decimal degrees. It sets how long the day and the night actually are, which is the whole difference between this and a printed timetable: at 51 north in June the day runs about sixteen and a half hours and its thirds are five and a half hours each. | |
| timezone | No | Timezone as an IANA name such as "Europe/London", or as decimal hours from UTC such as 5.5. An IANA name is resolved to the offset in force on the requested date. It decides which local day is meant and, on the clock-hour grid, where the blocks fall. Defaults to 0. | |
| longitude | Yes | Longitude in decimal degrees. It sets the clock time of sunrise at this place. | |
| doshaClock | No | How the six dosha periods are cut. "sunrise-anchored" divides the actual day and the actual night at this place into thirds, which is the division the frame chapter states, and is the default. "clock-hours" is the modern grid of six four-hour blocks from six in the morning; no classical text assigns clock hours, and the grid is only exact at an equinox near the equator. Both sets are returned whichever is chosen, so a caller can show one and reconcile against the other. | sunrise-anchored |
| Name | Required | Description |
|---|---|---|
| date | Yes | |
| meta | Yes | |
| sunset | Yes | |
| routine | Yes | |
| sources | Yes | |
| summary | Yes | |
| sunrise | Yes | |
| conventions | Yes | |
| nextSunrise | Yes | |
| doshaPeriods | Yes | |
| brahmaMuhurta | Yes | |
| alternatePeriods | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already declaring readOnlyHint=true and destructiveHint=false, the description adds valuable behavioral context: the default division cuts actual day and night into thirds, the modern clock grid is returned alongside by default so a caller can show either, both sets are returned whichever doshaClock option is chosen, and the brahma muhurta is a fixed 96-to-48-minute pre-sunrise window. 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?
The description is tight and front-loaded; all three sentences add meaningful computation semantics. It is on the slightly dense side, but not redundant, so it remains well-structured rather than maximally concise.
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 this tool's complexity: it explains the core computation, the two division schemes, the brahma muhurta detail, and the fact that both result sets are returned. The output schema covers return structure, and the annotations cover safety, leaving no critical gap for 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 percent, so the baseline of 3 applies. The description adds useful interpretive context about the division method and the brahma muhurta window, but it does not materially supplement the already thorough parameter descriptions 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 states a clear action and resource: compute the dinacharya daily routine for one date and one place, enumerating the exact outputs sunrise, sunset, brahma muhurta, and six dosha periods. It is specific enough to be understood, but it does not explicitly differentiate itself from siblings like get_ayurveda_daily or get_ayurveda_doshas, so it stops short of full sibling distinction.
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 intended use is implied by the first sentence: this is the tool for a date-and-place-specific dinacharya computation. There is no explicit when-to-use or when-not-to-use guidance and no named alternative among the sibling tools, so an agent must infer the selection boundary rather than being told it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve the ritucharya, the Ayurvedic season, for a date from the real solar ingress instants and return the regimen the primary text gives for it. The response carries the season with its exact opening and closing instants, the half of the year the sun is in, where each dosha stands in the seasonal cycle, the taste that grows across the season, and the behaviour items the chapter states. Season boundaries are measured in the tropical zodiac by default, which is what published almanacs use, and the sidereal reading is available as a convention and runs about 24 days later.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | The date to resolve, in YYYY-MM-DD format. The season is read at midday UTC on this date, because a season boundary is an instant and a calendar day has to be reduced to one; on a day that carries a boundary, the half the midday falls in is the answer. | |
| 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. | |
| hemisphere | No | Which half of the world the season names are stated for. Defaults to "northern", which is the half the primary text describes. It is NEVER inferred from a latitude: a silent flip would change the answer without the caller asking, and no classical text handles the southern case at all. Passing "southern" rotates the six season names by three places, following a modern almanac rather than a verse, and the response says so and states what was not rotated with them. | northern |
| rituZodiac | No | Which zodiac the solar-month boundaries are measured in. "sayana" is the tropical reading, which is what published almanacs use for seasons and is the default. "nirayana" is the sidereal reading in the Lahiri frame, which runs about 24 days later. The gap is the size of the ayanamsa, so near a boundary the two answer with different seasons for the same date, which is why the value is echoed in every response. | sayana |
| ritucharyaScheme | No | Which six-season division the year is cut into. "sutrasthana-6" is the standard set of sisira, vasanta, grisma, varsa, sarad and hemanta, and is the default. "vimana-8" is the alternate division in which three seasons of extreme character alternate with three of moderate character and pravrt, the season of the first rains, replaces sisira. The alternate is not a relabelling: five of the six boundaries move, and because its verse gives no solar-month boundaries the month allocation is a RoxyAPI convention, stated in the response. | sutrasthana-6 |
| Name | Required | Description |
|---|---|---|
| date | Yes | |
| meta | Yes | |
| ritu | Yes | |
| ayana | Yes | |
| phase | Yes | |
| regimen | Yes | |
| sources | Yes | |
| summary | Yes | |
| strength | Yes | |
| doshaCycle | Yes | |
| conventions | Yes | |
| tasteIncreasing | Yes |
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 substantial behavioral context: the midday-UTC resolution rule for boundary dates, the refusal to infer hemisphere from latitude, the convention status of the sidereal reading, and the fact that the alternate vimana-8 scheme shifts five boundaries. These details go well beyond what annotations 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 three dense sentences with purpose front-loaded. Every clause carries decision-relevant information: exact season boundaries, midday reduction, almanac convention, sidereal offset, and response contents. There is no filler and no repetition of schema material.
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 calculation API with a rich input schema and an output schema, the description covers boundary-date ambiguity, hemisphere behavior, zodiac convention mismatch, alternate season division, and response structure. Nothing an agent needs to call it correctly appears to be 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?
Input schema coverage is 100%, yet the description still adds non-redundant parameter meaning: tropical vs. sidereal almanac behavior and the 24-day offset, why the zodiac value is echoed, hemisphere rotation mechanics, the lossless compact shape, and the 'not a relabelling' caveat for ritucharyaScheme. This is exactly the added value expected beyond schema fields.
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: 'Resolve the ritucharya, the Ayurvedic season, for a date ... and return the regimen the primary text gives for it.' It clearly states the compute-and-return nature of the tool and is obviously distinct from sibling tools like get_ayurveda_daily or get_ayurveda_dinacharya.
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 trigger condition is clear: given a date, resolve its season and regimen. The description also communicates defaults and conventions (tropical zodiac, northern hemisphere, sutrasthana-6), but it never explicitly names sibling tools or states when not to use this tool, so guidance remains implied rather than comparative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_ayurveda_daily4 fields changedInput schema / properties / latitude / maximumAdded value: +90Input schema / properties / latitude / minimumAdded value: +-90Input schema / properties / longitude / maximumAdded value: +180Input schema / properties / longitude / minimumAdded value: +-180get_ayurveda_doshas2 fields changedInput schema / properties / offset / defaultAdded value: +0Input schema / properties / offset / minimumAdded value: +0get_ayurveda_qualities2 fields changedInput schema / properties / offset / defaultAdded value: +0Input schema / properties / offset / minimumAdded value: +0get_ayurveda_tastes2 fields changedInput schema / properties / offset / defaultAdded value: +0Input schema / properties / offset / minimumAdded value: +0get_ayurveda_doshas3 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_ayurveda_qualities3 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_ayurveda_tastes3 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_ayurveda_daily8 fields changedInput schema / examplesPrevious value: -[
- {}
-]New value: +[
+ {
+ "latitude": 51.5074,
+ "longitude": -0.1278
+ }
+]Input schema / properties / latitude / maximumRemoved value: -90Input schema / properties / latitude / minimumRemoved value: --90Input schema / properties / latitude / typePrevious value: -[
- "number",
- "null"
-]New value: +"number"Input schema / properties / longitude / maximumRemoved value: -180Input schema / properties / longitude / minimumRemoved value: --180Input schema / properties / longitude / typePrevious value: -[
- "number",
- "null"
-]New value: +"number"Input schema / requiredAdded value: +[
+ "latitude",
+ "longitude"
+]get_ayurveda_daily1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "brahmaMuhurta": {
+ "properties": {
+ "end": {
+ "type": "string"
+ },
+ "start": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "start",
+ "end"
+ ],
+ "type": "object"
+ },
+ "conventions": {
+ "properties": {
+ "doshaClock": {
+ "type": "string"
+ },
+ "hemisphere": {
+ "type": "string"
+ },
+ "rituZodiac": {
+ "type": "string"
+ },
+ "ritucharyaScheme": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "doshaClock",
+ "ritucharyaScheme",
+ "rituZodiac",
+ "hemisphere"
+ ],
+ "type": "object"
+ },
+ "date": {
+ "type": "string"
+ },
+ "doshaCycle": {
+ "items": {
+ "properties": {
+ "dosha": {
+ "type": "string"
+ },
+ "state": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "dosha",
+ "state"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "doshaPeriods": {
+ "items": {
+ "properties": {
+ "dosha": {
+ "type": "string"
+ },
+ "end": {
+ "type": "string"
+ },
+ "span": {
+ "type": "string"
+ },
+ "start": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "dosha",
+ "start",
+ "end",
+ "span"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "meta": {
+ "properties": {
+ "disclaimer": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "disclaimer"
+ ],
+ "type": "object"
+ },
+ "ritu": {
+ "properties": {
+ "ayana": {
+ "type": "string"
+ },
+ "end": {
+ "type": "string"
+ },
+ "gloss": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "phase": {
+ "type": "string"
+ },
+ "sanskritName": {
+ "type": "string"
+ },
+ "start": {
+ "type": "string"
+ },
+ "strength": {
+ "type": "string"
+ },
+ "tasteIncreasing": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "sanskritName",
+ "gloss",
+ "start",
+ "end",
+ "ayana",
+ "phase",
+ "strength",
+ "tasteIncreasing"
+ ],
+ "type": "object"
+ },
+ "sources": {
+ "items": {
+ "properties": {
+ "chapter": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "publicDomain": {
+ "type": "boolean"
+ },
+ "text": {
+ "type": "string"
+ },
+ "translation": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "verse": {
+ "type": "string"
+ },
+ "year": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "text",
+ "chapter",
+ "verse",
+ "translation",
+ "year",
+ "publicDomain"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "sunrise": {
+ "type": "string"
+ },
+ "sunset": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "date",
+ "sunrise",
+ "sunset",
+ "brahmaMuhurta",
+ "doshaPeriods",
+ "ritu",
+ "doshaCycle",
+ "summary",
+ "sources",
+ "conventions",
+ "meta"
+ ],
+ "type": "object"
+}get_ayurveda_doshas1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "doshas": {
+ "items": {
+ "properties": {
+ "alsoCalled": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "devanagari": {
+ "type": "string"
+ },
+ "element": {
+ "type": "string"
+ },
+ "functions": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "id": {
+ "type": "string"
+ },
+ "modernElementPair": {
+ "type": "string"
+ },
+ "qualities": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "qualityGunas": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "sanskritName": {
+ "type": "string"
+ },
+ "seats": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "seatsVariant": {
+ "type": "string"
+ },
+ "source": {
+ "properties": {
+ "chapter": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "publicDomain": {
+ "type": "boolean"
+ },
+ "text": {
+ "type": "string"
+ },
+ "translation": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "verse": {
+ "type": "string"
+ },
+ "year": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "text",
+ "chapter",
+ "verse",
+ "translation",
+ "year",
+ "publicDomain"
+ ],
+ "type": "object"
+ },
+ "specialSeat": {
+ "type": "string"
+ },
+ "states": {
+ "properties": {
+ "accumulating": {
+ "type": "string"
+ },
+ "aggravated": {
+ "type": "string"
+ },
+ "balanced": {
+ "type": "string"
+ },
+ "settlesWith": {
+ "type": "string"
+ },
+ "source": {
+ "properties": {
+ "chapter": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "publicDomain": {
+ "type": "boolean"
+ },
+ "text": {
+ "type": "string"
+ },
+ "translation": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "verse": {
+ "type": "string"
+ },
+ "year": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "text",
+ "chapter",
+ "verse",
+ "translation",
+ "year",
+ "publicDomain"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "balanced",
+ "accumulating",
+ "aggravated",
+ "settlesWith",
+ "source"
+ ],
+ "type": "object"
+ },
+ "subDoshas": {
+ "items": {
+ "properties": {
+ "devanagari": {
+ "type": "string"
+ },
+ "function": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "moves": {
+ "type": "string"
+ },
+ "sanskritName": {
+ "type": "string"
+ },
+ "seat": {
+ "type": "string"
+ },
+ "source": {
+ "properties": {
+ "chapter": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "publicDomain": {
+ "type": "boolean"
+ },
+ "text": {
+ "type": "string"
+ },
+ "translation": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "verse": {
+ "type": "string"
+ },
+ "year": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "text",
+ "chapter",
+ "verse",
+ "translation",
+ "year",
+ "publicDomain"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "id",
+ "sanskritName",
+ "devanagari",
+ "seat",
+ "function",
+ "source"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "id",
+ "sanskritName",
+ "devanagari",
+ "alsoCalled",
+ "element",
+ "modernElementPair",
+ "qualities",
+ "qualityGunas",
+ "seats",
+ "specialSeat",
+ "seatsVariant",
+ "functions",
+ "subDoshas",
+ "states",
+ "source"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "limit": {
+ "type": "number"
+ },
+ "meta": {
+ "properties": {
+ "disclaimer": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "disclaimer"
+ ],
+ "type": "object"
+ },
+ "offset": {
+ "type": "number"
+ },
+ "sources": {
+ "items": {
+ "properties": {
+ "chapter": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "publicDomain": {
+ "type": "boolean"
+ },
+ "text": {
+ "type": "string"
+ },
+ "translation": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "verse": {
+ "type": "string"
+ },
+ "year": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "text",
+ "chapter",
+ "verse",
+ "translation",
+ "year",
+ "publicDomain"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "total",
+ "limit",
+ "offset",
+ "doshas",
+ "sources",
+ "meta"
+ ],
+ "type": "object"
+}get_ayurveda_doshas_id1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "dosha": {
+ "properties": {
+ "alsoCalled": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "devanagari": {
+ "type": "string"
+ },
+ "element": {
+ "type": "string"
+ },
+ "functions": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "id": {
+ "type": "string"
+ },
+ "modernElementPair": {
+ "type": "string"
+ },
+ "qualities": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "qualityGunas": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "sanskritName": {
+ "type": "string"
+ },
+ "seats": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "seatsVariant": {
+ "type": "string"
+ },
+ "source": {
+ "properties": {
+ "chapter": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "publicDomain": {
+ "type": "boolean"
+ },
+ "text": {
+ "type": "string"
+ },
+ "translation": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "verse": {
+ "type": "string"
+ },
+ "year": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "text",
+ "chapter",
+ "verse",
+ "translation",
+ "year",
+ "publicDomain"
+ ],
+ "type": "object"
+ },
+ "specialSeat": {
+ "type": "string"
+ },
+ "states": {
+ "properties": {
+ "accumulating": {
+ "type": "string"
+ },
+ "aggravated": {
+ "type": "string"
+ },
+ "balanced": {
+ "type": "string"
+ },
+ "settlesWith": {
+ "type": "string"
+ },
+ "source": {
+ "properties": {
+ "chapter": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "publicDomain": {
+ "type": "boolean"
+ },
+ "text": {
+ "type": "string"
+ },
+ "translation": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "verse": {
+ "type": "string"
+ },
+ "year": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "text",
+ "chapter",
+ "verse",
+ "translation",
+ "year",
+ "publicDomain"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "balanced",
+ "accumulating",
+ "aggravated",
+ "settlesWith",
+ "source"
+ ],
+ "type": "object"
+ },
+ "subDoshas": {
+ "items": {
+ "properties": {
+ "devanagari": {
+ "type": "string"
+ },
+ "function": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "moves": {
+ "type": "string"
+ },
+ "sanskritName": {
+ "type": "string"
+ },
+ "seat": {
+ "type": "string"
+ },
+ "source": {
+ "properties": {
+ "chapter": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "publicDomain": {
+ "type": "boolean"
+ },
+ "text": {
+ "type": "string"
+ },
+ "translation": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "verse": {
+ "type": "string"
+ },
+ "year": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "text",
+ "chapter",
+ "verse",
+ "translation",
+ "year",
+ "publicDomain"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "id",
+ "sanskritName",
+ "devanagari",
+ "seat",
+ "function",
+ "source"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "id",
+ "sanskritName",
+ "devanagari",
+ "alsoCalled",
+ "element",
+ "modernElementPair",
+ "qualities",
+ "qualityGunas",
+ "seats",
+ "specialSeat",
+ "seatsVariant",
+ "functions",
+ "subDoshas",
+ "states",
+ "source"
+ ],
+ "type": "object"
+ },
+ "meta": {
+ "properties": {
+ "disclaimer": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "disclaimer"
+ ],
+ "type": "object"
+ },
+ "sources": {
+ "items": {
+ "properties": {
+ "chapter": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "publicDomain": {
+ "type": "boolean"
+ },
+ "text": {
+ "type": "string"
+ },
+ "translation": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "verse": {
+ "type": "string"
+ },
+ "year": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "text",
+ "chapter",
+ "verse",
+ "translation",
+ "year",
+ "publicDomain"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "dosha",
+ "sources",
+ "meta"
+ ],
+ "type": "object"
+}get_ayurveda_qualities1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "limit": {
+ "type": "number"
+ },
+ "meta": {
+ "properties": {
+ "disclaimer": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "disclaimer"
+ ],
+ "type": "object"
+ },
+ "offset": {
+ "type": "number"
+ },
+ "pairs": {
+ "items": {
+ "properties": {
+ "a": {
+ "properties": {
+ "action": {
+ "type": "string"
+ },
+ "actionSanskrit": {
+ "type": "string"
+ },
+ "doshas": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "english": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "sanskritName": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "sanskritName",
+ "english",
+ "action",
+ "actionSanskrit",
+ "doshas"
+ ],
+ "type": "object"
+ },
+ "b": {
+ "properties": {
+ "action": {
+ "type": "string"
+ },
+ "actionSanskrit": {
+ "type": "string"
+ },
+ "doshas": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "english": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "sanskritName": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "sanskritName",
+ "english",
+ "action",
+ "actionSanskrit",
+ "doshas"
+ ],
+ "type": "object"
+ },
+ "note": {
+ "type": "string"
+ },
+ "number": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "number",
+ "a",
+ "b"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "rule": {
+ "type": "string"
+ },
+ "sources": {
+ "items": {
+ "properties": {
+ "chapter": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "publicDomain": {
+ "type": "boolean"
+ },
+ "text": {
+ "type": "string"
+ },
+ "translation": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "verse": {
+ "type": "string"
+ },
+ "year": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "text",
+ "chapter",
+ "verse",
+ "translation",
+ "year",
+ "publicDomain"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "total",
+ "limit",
+ "offset",
+ "rule",
+ "pairs",
+ "sources",
+ "meta"
+ ],
+ "type": "object"
+}get_ayurveda_tastes1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "limit": {
+ "type": "number"
+ },
+ "matrix": {
+ "additionalProperties": {
+ "properties": {
+ "decreasedBy": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "increasedBy": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "decreasedBy",
+ "increasedBy"
+ ],
+ "type": "object"
+ },
+ "type": "object"
+ },
+ "meta": {
+ "properties": {
+ "disclaimer": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "disclaimer"
+ ],
+ "type": "object"
+ },
+ "offset": {
+ "type": "number"
+ },
+ "rasas": {
+ "items": {
+ "properties": {
+ "decreases": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "devanagari": {
+ "type": "string"
+ },
+ "elements": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "english": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "increases": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "sanskritName": {
+ "type": "string"
+ },
+ "textForm": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "sanskritName",
+ "devanagari",
+ "textForm",
+ "english",
+ "elements",
+ "decreases",
+ "increases"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "sources": {
+ "items": {
+ "properties": {
+ "chapter": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "publicDomain": {
+ "type": "boolean"
+ },
+ "text": {
+ "type": "string"
+ },
+ "translation": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "verse": {
+ "type": "string"
+ },
+ "year": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "text",
+ "chapter",
+ "verse",
+ "translation",
+ "year",
+ "publicDomain"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "strengthOrder": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "total": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "total",
+ "limit",
+ "offset",
+ "strengthOrder",
+ "rasas",
+ "matrix",
+ "sources",
+ "meta"
+ ],
+ "type": "object"
+}post_ayurveda_constitution1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "composite": {
+ "properties": {
+ "convention": {
+ "type": "string"
+ },
+ "dominant": {
+ "type": "string"
+ },
+ "kapha": {
+ "type": "number"
+ },
+ "pitta": {
+ "type": "number"
+ },
+ "secondary": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ },
+ "vata": {
+ "type": "number"
+ },
+ "weighting": {
+ "properties": {
+ "dualTypeMargin": {
+ "type": "number"
+ },
+ "lagnaSign": {
+ "type": "number"
+ },
+ "moonSign": {
+ "type": "number"
+ },
+ "strongPlanetThreshold": {
+ "type": "number"
+ },
+ "strongestPlanet": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "lagnaSign",
+ "moonSign",
+ "strongestPlanet",
+ "strongPlanetThreshold",
+ "dualTypeMargin"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "vata",
+ "pitta",
+ "kapha",
+ "dominant",
+ "secondary",
+ "type",
+ "convention",
+ "weighting"
+ ],
+ "type": "object"
+ },
+ "conventions": {
+ "properties": {
+ "ayanamsa": {
+ "type": "string"
+ },
+ "signDoshaScheme": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "signDoshaScheme",
+ "ayanamsa"
+ ],
+ "type": "object"
+ },
+ "factors": {
+ "items": {
+ "properties": {
+ "doshas": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "id": {
+ "type": "string"
+ },
+ "input": {
+ "type": "string"
+ },
+ "source": {
+ "properties": {
+ "chapter": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "publicDomain": {
+ "type": "boolean"
+ },
+ "text": {
+ "type": "string"
+ },
+ "translation": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "verse": {
+ "type": "string"
+ },
+ "year": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "text",
+ "chapter",
+ "verse",
+ "translation",
+ "year",
+ "publicDomain"
+ ],
+ "type": "object"
+ },
+ "weight": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "id",
+ "input",
+ "doshas",
+ "weight",
+ "source"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "frame": {
+ "properties": {
+ "ayanamsa": {
+ "type": "string"
+ },
+ "ayanamsaDegrees": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "ayanamsa",
+ "ayanamsaDegrees"
+ ],
+ "type": "object"
+ },
+ "lagnaSign": {
+ "type": "string"
+ },
+ "meta": {
+ "properties": {
+ "disclaimer": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "disclaimer"
+ ],
+ "type": "object"
+ },
+ "moonSign": {
+ "type": "string"
+ },
+ "planetDoshas": {
+ "items": {
+ "properties": {
+ "dhatu": {
+ "type": "string"
+ },
+ "dhatuSanskrit": {
+ "type": "string"
+ },
+ "dhatuSource": {
+ "properties": {
+ "chapter": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "publicDomain": {
+ "type": "boolean"
+ },
+ "text": {
+ "type": "string"
+ },
+ "translation": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "verse": {
+ "type": "string"
+ },
+ "year": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "text",
+ "chapter",
+ "verse",
+ "translation",
+ "year",
+ "publicDomain"
+ ],
+ "type": "object"
+ },
+ "doshaSource": {
+ "properties": {
+ "chapter": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "publicDomain": {
+ "type": "boolean"
+ },
+ "text": {
+ "type": "string"
+ },
+ "translation": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "verse": {
+ "type": "string"
+ },
+ "year": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "text",
+ "chapter",
+ "verse",
+ "translation",
+ "year",
+ "publicDomain"
+ ],
+ "type": "object"
+ },
+ "doshas": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "graha": {
+ "type": "string"
+ },
+ "sanskritName": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "graha",
+ "sanskritName",
+ "doshas",
+ "dhatu",
+ "dhatuSanskrit",
+ "doshaSource",
+ "dhatuSource"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "strengthRanking": {
+ "items": {
+ "properties": {
+ "graha": {
+ "type": "string"
+ },
+ "rank": {
+ "type": "number"
+ },
+ "strong": {
+ "type": "boolean"
+ },
+ "totalVirupas": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "graha",
+ "totalVirupas",
+ "rank",
+ "strong"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "summary": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "frame",
+ "lagnaSign",
+ "moonSign",
+ "factors",
+ "composite",
+ "strengthRanking",
+ "planetDoshas",
+ "summary",
+ "conventions",
+ "meta"
+ ],
+ "type": "object"
+}post_ayurveda_dinacharya1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "alternatePeriods": {
+ "items": {
+ "properties": {
+ "dosha": {
+ "type": "string"
+ },
+ "end": {
+ "type": "string"
+ },
+ "span": {
+ "type": "string"
+ },
+ "start": {
+ "type": "string"
+ },
+ "third": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "dosha",
+ "start",
+ "end",
+ "span"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "brahmaMuhurta": {
+ "properties": {
+ "end": {
+ "type": "string"
+ },
+ "muhurtaMinutes": {
+ "type": "number"
+ },
+ "muhurtasPerAhoratra": {
+ "type": "number"
+ },
+ "source": {
+ "properties": {
+ "chapter": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "publicDomain": {
+ "type": "boolean"
+ },
+ "text": {
+ "type": "string"
+ },
+ "translation": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "verse": {
+ "type": "string"
+ },
+ "year": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "text",
+ "chapter",
+ "verse",
+ "translation",
+ "year",
+ "publicDomain"
+ ],
+ "type": "object"
+ },
+ "start": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "start",
+ "end",
+ "muhurtaMinutes",
+ "muhurtasPerAhoratra",
+ "source"
+ ],
+ "type": "object"
+ },
+ "conventions": {
+ "properties": {
+ "doshaClock": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "doshaClock"
+ ],
+ "type": "object"
+ },
+ "date": {
+ "type": "string"
+ },
+ "doshaPeriods": {
+ "items": {
+ "properties": {
+ "dosha": {
+ "type": "string"
+ },
+ "end": {
+ "type": "string"
+ },
+ "span": {
+ "type": "string"
+ },
+ "start": {
+ "type": "string"
+ },
+ "third": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "dosha",
+ "start",
+ "end",
+ "span"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "meta": {
+ "properties": {
+ "disclaimer": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "disclaimer"
+ ],
+ "type": "object"
+ },
+ "nextSunrise": {
+ "type": "string"
+ },
+ "routine": {
+ "items": {
+ "properties": {
+ "guidance": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "order": {
+ "type": "number"
+ },
+ "sanskritName": {
+ "type": "string"
+ },
+ "source": {
+ "properties": {
+ "chapter": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "publicDomain": {
+ "type": "boolean"
+ },
+ "text": {
+ "type": "string"
+ },
+ "translation": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "verse": {
+ "type": "string"
+ },
+ "year": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "text",
+ "chapter",
+ "verse",
+ "translation",
+ "year",
+ "publicDomain"
+ ],
+ "type": "object"
+ },
+ "timing": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "order",
+ "id",
+ "sanskritName",
+ "guidance",
+ "timing",
+ "source"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "sources": {
+ "items": {
+ "properties": {
+ "chapter": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "publicDomain": {
+ "type": "boolean"
+ },
+ "text": {
+ "type": "string"
+ },
+ "translation": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "verse": {
+ "type": "string"
+ },
+ "year": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "text",
+ "chapter",
+ "verse",
+ "translation",
+ "year",
+ "publicDomain"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "sunrise": {
+ "type": "string"
+ },
+ "sunset": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "date",
+ "sunrise",
+ "sunset",
+ "nextSunrise",
+ "brahmaMuhurta",
+ "doshaPeriods",
+ "alternatePeriods",
+ "routine",
+ "summary",
+ "sources",
+ "conventions",
+ "meta"
+ ],
+ "type": "object"
+}post_ayurveda_ritucharya1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "ayana": {
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "source": {
+ "properties": {
+ "chapter": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "publicDomain": {
+ "type": "boolean"
+ },
+ "text": {
+ "type": "string"
+ },
+ "translation": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "verse": {
+ "type": "string"
+ },
+ "year": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "text",
+ "chapter",
+ "verse",
+ "translation",
+ "year",
+ "publicDomain"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "id",
+ "source"
+ ],
+ "type": "object"
+ },
+ "conventions": {
+ "properties": {
+ "hemisphere": {
+ "type": "string"
+ },
+ "rituZodiac": {
+ "type": "string"
+ },
+ "ritucharyaScheme": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "ritucharyaScheme",
+ "rituZodiac",
+ "hemisphere"
+ ],
+ "type": "object"
+ },
+ "date": {
+ "type": "string"
+ },
+ "doshaCycle": {
+ "items": {
+ "properties": {
+ "dosha": {
+ "type": "string"
+ },
+ "meaning": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "state": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "dosha",
+ "state",
+ "meaning"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "meta": {
+ "properties": {
+ "disclaimer": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "disclaimer"
+ ],
+ "type": "object"
+ },
+ "phase": {
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "source": {
+ "properties": {
+ "chapter": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "publicDomain": {
+ "type": "boolean"
+ },
+ "text": {
+ "type": "string"
+ },
+ "translation": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "verse": {
+ "type": "string"
+ },
+ "year": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "text",
+ "chapter",
+ "verse",
+ "translation",
+ "year",
+ "publicDomain"
+ ],
+ "type": "object"
+ },
+ "tastes": {
+ "items": {
+ "properties": {
+ "english": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "sanskritName": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "sanskritName",
+ "english"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "id",
+ "tastes",
+ "source"
+ ],
+ "type": "object"
+ },
+ "regimen": {
+ "items": {
+ "properties": {
+ "guidance": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "source": {
+ "properties": {
+ "chapter": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "publicDomain": {
+ "type": "boolean"
+ },
+ "text": {
+ "type": "string"
+ },
+ "translation": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "verse": {
+ "type": "string"
+ },
+ "year": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "text",
+ "chapter",
+ "verse",
+ "translation",
+ "year",
+ "publicDomain"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "id",
+ "guidance",
+ "source"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "ritu": {
+ "properties": {
+ "classicalRitu": {
+ "type": "string"
+ },
+ "devanagari": {
+ "type": "string"
+ },
+ "end": {
+ "type": "string"
+ },
+ "gloss": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "sanskritName": {
+ "type": "string"
+ },
+ "solarMonths": {
+ "items": {
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "index": {
+ "type": "number"
+ },
+ "sanskritName": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "index",
+ "id",
+ "sanskritName"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "start": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "sanskritName",
+ "devanagari",
+ "gloss",
+ "classicalRitu",
+ "start",
+ "end",
+ "solarMonths"
+ ],
+ "type": "object"
+ },
+ "sources": {
+ "items": {
+ "properties": {
+ "chapter": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "publicDomain": {
+ "type": "boolean"
+ },
+ "text": {
+ "type": "string"
+ },
+ "translation": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "verse": {
+ "type": "string"
+ },
+ "year": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "text",
+ "chapter",
+ "verse",
+ "translation",
+ "year",
+ "publicDomain"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "strength": {
+ "properties": {
+ "level": {
+ "type": "string"
+ },
+ "source": {
+ "properties": {
+ "chapter": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "publicDomain": {
+ "type": "boolean"
+ },
+ "text": {
+ "type": "string"
+ },
+ "translation": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "verse": {
+ "type": "string"
+ },
+ "year": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "text",
+ "chapter",
+ "verse",
+ "translation",
+ "year",
+ "publicDomain"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "level",
+ "source"
+ ],
+ "type": "object"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "tasteIncreasing": {
+ "properties": {
+ "english": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "sanskritName": {
+ "type": "string"
+ },
+ "source": {
+ "properties": {
+ "chapter": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "publicDomain": {
+ "type": "boolean"
+ },
+ "text": {
+ "type": "string"
+ },
+ "translation": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "verse": {
+ "type": "string"
+ },
+ "year": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "text",
+ "chapter",
+ "verse",
+ "translation",
+ "year",
+ "publicDomain"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "id",
+ "sanskritName",
+ "english",
+ "source"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "date",
+ "ritu",
+ "ayana",
+ "phase",
+ "strength",
+ "tasteIncreasing",
+ "doshaCycle",
+ "regimen",
+ "summary",
+ "sources",
+ "conventions",
+ "meta"
+ ],
+ "type": "object"
+}get_ayurveda_dailyget_ayurveda_doshasget_ayurveda_doshas_idget_ayurveda_qualitiesget_ayurveda_tastespost_ayurveda_constitutionpost_ayurveda_dinacharyapost_ayurveda_ritucharyaVedic and Western astrology for AI agents: charts, dasha, matchmaking, panchanga, numerology, tarot.
Vedic astrology (Jyotish): birth charts, divisional charts, dashas, yogas, transits, panchang
30 Vedic Jyotish tools: natal charts, dashas, yogas, nakshatras. Swiss Ephemeris.
Vedic astrology for AI agents: chart facts, panchang windows, and Guna Milan compatibility.
Add one secure layer between your agents and this server.
