Ayurvedic constitution from a birth chart, dinacharya, ritucharya and dosha catalogues for agents.
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 | No | 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 | No | Longitude in decimal degrees. It sets the clock time of sunrise at this place. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, so the safety profile is already covered. The description adds meaningful behavioral detail: it composes two routes, defaults apply throughout and are echoed, and it mentions that dosha periods are 'cut from the actual day and night.' This goes beyond what annotations 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?
Three sentences, front-loaded with the output list, and every sentence earns its place: what it returns, why to use it, and when to avoid it. No fluff or repetition.
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?
No output schema exists, so the description carries the burden of describing the return value. It lists the key components of the reading and notes the composition behavior, which is sufficient for a widget-oriented tool. Minor gaps like response structure details are acceptable given the compact parameter description.
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 six parameters. The description does not need to add parameter-level details, and it does not introduce any conflicting parameter context. 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 states a specific verb ('Get'), a concrete resource ('one days Ayurveda reading for a place'), and enumerates the exact outputs: sunrise, brahma muhurta window, six dosha periods, and season. It also explains that this route composes two other routes, clearly distinguishing it from sibling tools without explicitly naming them.
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 tells the agent when to use this tool ('so a widget needs one call rather than two') and explicitly states the exception: 'call those two routes directly to choose a different season scheme, zodiac, hemisphere or dosha clock.' This is actionable routing guidance that prevents misuse.
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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover read-only safety, so the description adds value by disclosing modeling choices: states are expressed as position/quality rather than complaints, qualities are constrained to the twenty gunas, and text variants are recorded from a second primary source. This is meaningful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence front-loads the core result set and the second adds important data-modeling context. It is slightly dense but each clause contributes something non-obvious about the returned catalogue.
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 compensates by naming the doshas, their attributes, sub-doshas, states, and verse provenance, as well as language/pagination parameters via the schema. It does not describe the response envelope or list-vs-detail relationship with the ID sibling, but there is enough for a straightforward read-only catalogue call.
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% with detailed descriptions for lang, limit, offset, and compact, so the schema fully documents parameters. The description adds no parameter-specific meaning, which matches the baseline for full coverage.
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 concrete verb-resource pair: 'Return vata, pitta and kapha' plus the attributes each carries. It distinguishes the collective catalogue from the ID-scoped sibling and from the tastes/qualities endpoints by positioning this as the canonical three-dosha listing.
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?
No guidance is given about when to call this endpoint instead of get_ayurveda_doshas_id or get_ayurveda_daily, and no exclusions or alternatives are named. The text only implies a data-modeling role ('join to the tastes and qualities endpoints'), not a selection rule.
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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint and destructiveHint annotations already establish safety. The description adds meaningful behavioral context beyond that: it enumerates the payload components (elements, qualities, seats, sub-doshas, states) and reveals the joinable field qualityGunas. Since there is no output schema, this return-shape disclosure is valuable. It does not discuss translation fallback or failure modes, but the parameter schema covers the language behavior.
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 scope and payload; the second states the intended use case and a cross-join hint. Every sentence earns its place and the most important information 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?
For a simple read-only single-resource tool with a fully documented 3-parameter schema and no output schema, the description together with the schema is complete. It tells the agent what data comes back, when to use it, and how to relate it to another domain entity. No critical operational details such as auth, destructive effects, or pagination are relevant enough to be required here.
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 id, lang, and compact. The description adds the qualityGunas join hint, which enriches use of the returned data, but it does not add semantic meaning to the parameters themselves. The baseline of 3 is appropriate when the schema carries the parameter-documentation 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?
States a specific verb and resource: 'Return one dosha with its elements, qualities, seats, five sub-doshas and three states.' This clearly differentiates it from the sibling get_ayurveda_doshas (plural), which presumably returns the whole catalogue, and from get_ayurveda_qualities/tastes, which target different concept sets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit use context: 'Use it to render a dosha card or a glossary entry without pulling the whole catalogue.' This tells the agent when to prefer this tool over fetching all doshas, and the phrase 'without pulling the whole catalogue' implies the alternative of using the plural list tool. It stops short of naming that sibling explicitly or stating when not to use it, so it loses a point.
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. |
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 meaningful behavioral context beyond that: the response deliberately reports a recorded commentary disagreement rather than resolving it silently, and explains why that choice matters for dosha linkage. This is exactly the kind of non-obvious behavior that helps an agent trust and interpret the result.
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 efficient, front-loading the core purpose and then adding only consequential detail about the commentary disagreement. Every clause contributes useful information. It is slightly longer than the minimal ideal, but not padded, and the structure is logical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description adequately explains what the response contains: the ten opposed pairs, each member's action word, the half-verse rule, and the dosha associations. It also flags the one ambiguous pair. The remaining invocation details like pagination and response language are fully covered by the parameter 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?
Parameter schema description coverage is 100%, so the baseline is 3 even though the tool description adds no parameter-specific guidance. The description does not discuss lang, limit, offset, or compact, but the schema already documents each with defaults, ranges, and meanings. No additional parameter insight is needed.
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: 'Return the twenty gunas, the qualities of Ayurveda, as the ten opposed pairs...' This is far more specific than the title and clearly identifies the unique deliverable among the sibling tools, especially by noting the link to doshas. No agent could mistake this for get_ayurveda_tastes or 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 makes it implicitly clear this tool is for retrieving the guna pairs, but it never explicitly states when to use it versus alternatives such as get_ayurveda_tastes or get_ayurveda_doshas. There is no when-not-to-use guidance or named sibling alternative, so usage is implied rather than directed.
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. |
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 ancient-order note, bitter-before-pungent reversal, and the fact the matrix appears both per-taste and per-dosha. These are genuine behavioral traits an agent can't infer from the name or schema alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: the first states the resource, the second explains the ordering nuance, the third explains the dual-index return structure. Both non-obvious behaviors earn their place. The language is dense but not bloated, and the most important information (the resource and the matrix) 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?
For a read-only list tool with fully documented parameters and safety annotations, the description covers the domain, the ordering surprise, and the return structure. No output schema exists, but the description compensates by explaining what the matrix contains and how it is indexed. It does not specify the exact JSON field names, but that level of detail is generally unnecessary for tool 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 all four parameters (lang, limit, offset, compact) are already documented with types, ranges, defaults, and even token-efficiency notes. The description adds no parameter information but does not need to; it focuses on the return data shape, which is the correct division of labor.
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 the six rasas, the tastes of Ayurveda...' and immediately specifies the distinctive eighteen-cell matrix behavior. It clearly distinguishes this from sibling tools like get_ayurveda_doshas or get_ayurveda_qualities by naming the rasa domain and the bidirectional dosha matrix. The title is also informative.
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 makes clear the tool returns the rasa-to-dosha matrix read in two directions, which is the core use case. It does not explicitly state when to prefer this over sibling tools, but it names the specific resource and its unique matrix layout. It could have mentioned 'for dosha-specific lists, use get_ayurveda_doshas' but the context signals and sibling names make the domain boundary reasonably clear.
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite readOnlyHint=true covering safety, the description adds substantial behavioral context: it reveals that the composite dosha blend is a RoxyAPI convention rather than classical, that version and weights ship in the response, and that every response includes a general-wellness/cultural-interest disclaimer. It also flags that ayanamsa choice can change the reading and that signDoshaScheme can change it outright. These are precisely the kinds of non-obvious behaviors an agent needs to know.
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, no fluff, and the most decision-relevant facts are front-loaded: what it reads, what it returns, and what is conventional versus classical. The sentence about the composite being a RoxyAPI convention is the longest and could arguably be tightened, but every clause earns its place. Minor deduction for the last sentence packing disclaimer behavior into an already dense sentence, but overall excellent.
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 tool with 100% schema coverage, no output schema, and no nested objects, the description tells the agent what will come back (vata/pitta/kapha shares, verses, composite metadata, disclaimer) and which inputs drive which factors. The only somewhat open question is the exact output shape, but without an output schema the description cannot be expected to provide it and it does enough: it names the parts of the response. Complete for an AI agent selecting and invoking it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and every parameter has a rich description already, including sensitivity notes for time and ayanamsa. The top-level description adds no parameter-level detail, but it does provide the interpretive framing that the three factors are rising sign, Moon sign, and strongest graha by shadbala, which contextualizes why those inputs matter. Baseline 3 is appropriate because the schema already 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 opens with a precise verb and object ('Read the Ayurvedic constitution from a sidereal birth chart') and immediately enumerates the exact output (vata, pitta, kapha shares with verses). It also states the three astrological factors scored, clearly distinguishing this from any generic Ayurveda endpoint. The title reinforces it and the description elevates it.
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 says what the tool does and names the three factors it reads, which implies this tool is for birth-chart-derived constitution rather than daily or seasonal routines. It does not explicitly name alternative siblings or state when not to use it, but the heavy specificity of the factors and the mention that the composite is a convention create clear usage context. It lacks explicit exclusions such as 'for daily wellness use get_ayurveda_daily instead'.
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds valuable behavioral context: it explains that both dosha clock grids are returned regardless of the chosen mode, that the brahma muhurta is calculated as a fixed 96-to-48-minute window before sunrise rather than a share of the night, and that the default division follows the frame chapter's classical rule. This goes beyond the annotations and helps an agent understand the tool's actual behavior.
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, every one of which carries specific information: the output set, the default classical division, and the fixed brahma muhurta window. It is front-loaded with the core compute action and result list, and it avoids repeating schema details or generic filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 7 parameters, no output schema, and no sibling differentiation burden beyond what the description already handles, the description is remarkably complete. It explains the core calculations, the classical basis, the alternative mode, and the return shape. The only minor absence is an explicit statement of return format, but the description already tells the caller what will be present (sunrise, sunset, brahma muhurta, six dosha periods, both grids), so an agent can invoke it correctly without further documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning beyond the schema. It explains the conceptual role of latitude ('sets how long the day and night actually are'), the difference between the two doshaClock modes in classical terms, and the meaning of timezone for local day resolution. The description also states that both grids are returned whichever mode is selected, which is not in the schema. This earns a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Compute') with a clear resource (dinacharya daily routine) and enumerates the exact outputs: sunrise, sunset, brahma muhurta window, and six dosha periods for day and night. It also distinguishes the calculation basis (actual day/night divided into thirds) and explicitly names the alternative clock grid, which differentiates it from sibling tools that cover doshas, constitution, or ritual routines.
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 states that this tool computes a complete daily routine for one date and one place, and it explains the two available modes (default thirds vs modern clock grid). It implies when to use it — when a caller needs sunrise/sunset, brahma muhurta, or dosha periods — and the doshaClock parameter description reinforces the choice. It does not explicitly name sibling alternatives or state when not to use it, so it loses a point, but the context is strong.
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 |
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 material behavioral context: real solar ingress instants, tropical-by-default boundaries, sidereal as an optional ~24-day-later convention, and season-boundary resolution at midday UTC. This goes well beyond the annotations, though it does not describe every edge case.
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 with the core purpose front-loaded and every sentence earning its place. The description covers purpose, response contents, and the key zodiac convention without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by enumerating the key response fields: season instants, half-year, dosha state, taste, and behavior items. Combined with complete schema documentation for all six parameters, an agent has enough to invoke the tool correctly, though the absence of explicit usage exclusions is a small gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 even without parameter detail in the prose. The description does add some high-level context about tropical vs sidereal boundaries, but individual parameters are fully documented in the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Resolve') and resource ('the ritucharya, the Ayurvedic season, for a date'), and states the concrete deliverable: the regimen from the primary text. It clearly separates this seasonal-resolution tool from sibling daily-routine, dosha, taste, and constitution tools by naming the exact domain and inputs.
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 when to use the tool: when a date needs to be resolved to its Ayurvedic season and regimen. It does not explicitly name sibling alternatives or state when-not-to-use cases, but the scope is unambiguous enough for an agent to select it correctly against the sibling list.
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_ayurveda_dailyget_ayurveda_doshasget_ayurveda_doshas_idget_ayurveda_qualitiesget_ayurveda_tastespost_ayurveda_constitutionpost_ayurveda_dinacharyapost_ayurveda_ritucharyaClaiming 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 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.
Jyotish, Panchang, Hindu festival and Sanatan Dharma knowledge tools with citations.
Add one secure layer between your agents and this server.
Most tools are sharply separated by resource: dosha list/detail, qualities, tastes, constitution, routine, and season. The overlap is get_ayurveda_daily, which deliberately combines dinacharya and ritucharya, but its description clearly frames it as a one-call convenience and points to the post routes for customised calls.
All tool names follow the same verb_ayurveda_resource pattern, with get_ for read-only catalogue lookups and post_ for calculations. This makes the API predictable; the only minor oddity is doshas_id, but it does not break the pattern.
Eight tools cover the core catalogue (doshas, qualities, tastes), daily/seasonal readings, and the two calculation endpoints. This is well-scoped and each tool earns its place without redundancy.
The surface covers the main Ayurveda knowledge objects and the key date/location calculations, so agents can assemble useful readings. The main gap is that there is no separate endpoint for managing or listing location/convention options, but the daily composite helps tie the routes together.
