Ayurveda MCP Server by RoxyAPI

Dinacharya daily routine - Brahma muhurta and dosha clock API

post_ayurveda_dinacharya

Read-only

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.

Input Schema

TableJSON Schema

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

Schema Changelog

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

First observedSep 6, 2026

TDQS

A4.5/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

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?