Ayurveda MCP Server by RoxyAPI

Ayurveda seasonal regimen - Ritucharya and ritu resolution API

post_ayurveda_ritucharya

Read-only

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.

Input Schema

TableJSON Schema

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

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedSep 6, 2026

TDQS

A4.2/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All Ayurveda MCP Server by RoxyAPI tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0

Disambiguation4/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Resources

Need Help?