Vedic astrology for AI agents: charts, daśā, readings, muhūrta and JPL DE440 ephemeris.
Scored across 13 tools
Most tools have clearly distinct purposes (chart vs ephemeris vs dasha vs compatibility), and the get_ephemeris_* family is tidy. However, the interpretive layer—get_forecast, resolve_timing, and interpret_domain—overlaps: resolve_timing is explicitly described as 'like forecast,' and interpret_domain returns a 'domain reading' similar to forecast's domain verdict, so an agent could easily misselect among these three.
All 13 names follow a clean verb_noun pattern (find_muhurta, get_chart, interpret_domain, resolve_timing), with the nine ephemeris operations sharing an explicit get_ephemeris_* namespace. The varied leading verbs are semantically meaningful rather than arbitrary, so the convention stays predictable and readable.
13 tools is well within the ideal 3-15 band and each tool maps to a distinct capability (charts, ephemeric primitives, predictive readings, timing search). No redundant or filler tools are evident for the scope of a full astrology API.
The surface covers natal charts, compatibility, dasha, a broad ephemeris suite (angles, ayanamsa, positions, series, sunrise), muhurta, guidance, and both deterministic and LLM interpretation—strong lifecycle coverage. Minor gaps remain around divisional/varga charts and explicit transit (gochara) interpretation, though get_ephemeris_series partly compensates.
Auspicious windows (muhūrta) in a date range. Scans each day in the range and ranks windows for the subject. The pañcāṅga is computed for eventPlace, never defaulted to the birthplace.
Cost: 10 credits per call (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Deterministic: the same input always gives the same answer.
Example arguments: {"subject":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209},"eventPlace":{"latitude":19.076,"longitude":72.8777,"timezone":"Asia/Kolkata","label":"Mumbai"},"freeText":"signing a lease","rangeStart":"2026-11-01","rangeEnd":"2026-11-15"}
| Name | Required | Description | Default |
|---|---|---|---|
| topN | No | How many ranked windows to return. Default 5. | |
| eventId | No | Event type identifier, if known. | |
| subject | Yes | Birth data of the person the event is for; windows are ranked against their chart. | |
| freeText | No | The event described in words, when there is no eventId. | |
| rangeEnd | Yes | Last date to search, YYYY-MM-DD. | |
| timeOfDay | No | Local time (HH:MM) at which each day is evaluated. Default: local sunrise. | |
| eventPlace | Yes | Where the event will happen: latitude, longitude and IANA timezone. The pañcāṅga is computed here, never at the birthplace. | |
| rangeStart | Yes | First date to search, YYYY-MM-DD. | |
| subjectName | No | Optional name of the subject, used only in the response text. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: 10-credit cost with only successful calls charged, a free sandbox key returning a fixed sample, and determinism ('same input always gives the same answer').
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?
Four short sentences are front-loaded with purpose and constraints, followed by one long but high-information example. The example costs length but earns its place by illustrating the deeply nested required arguments; no sentence is 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 an output schema present, return values need no explanation, and the input schema documents all nine parameters. The description covers cost, determinism, place semantics, and an example, leaving only sibling-relative routing unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3; the description still adds value by providing a complete example argument object showing the nested subject/eventPlace shapes, and by stressing that eventPlace (not the subject's birthplace) drives the pañcāṅga computation.
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 (scans/ranks) and resource (auspicious muhūrta windows in a date range), and the second sentence clarifies the ranking basis (the subject's chart). An agent can distinguish this from read-only siblings like get_forecast or resolve_timing from the name-plus-description alone.
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 usage (range scanning, ranking windows, cost per call, sandbox behavior) and warns that the pañcāṅga is computed at eventPlace, never the birthplace. However it never names when to prefer this over sibling tools such as resolve_timing or get_forecast, so alternative selection is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Natal chart. Sidereal (Lahiri) chart: ascendant, the nine grahas, twelve houses, yogas and the Vimśottarī daśā. A modern Western block is added unless western is false. With location, also astrocartography lines at that place and the chart's own frame relocated there.
Cost: 1 credit per call (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Deterministic: the same input always gives the same answer.
Example arguments: {"birthData":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209}}
| Name | Required | Description | Default |
|---|---|---|---|
| western | No | Set false to omit the modern Western block. | |
| location | No | Both coordinates or neither: a half-filled location is refused, never defaulted. | |
| birthData | Yes | The person's birth data: date, local time (omit if unknown), IANA timezone, latitude and longitude. | |
| includeDasha | No | Include the Vimśottarī daśā periods in the chart response. Default true. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds genuinely non-structured traits: cost (1 credit), the fact that only successful calls are charged, a free sandbox key returning fixed sample data, and an explicit determinism guarantee. The half-filled-location refusal rule is useful but largely duplicates the schema.
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 body is dense and front-loaded, with cost and determinism called out before the example. The opening fragment 'Natal chart.' merely restates the title and earns little, but the remaining sentences are compact and information-rich.
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 computation tool with a full output schema, the agent needs to know what is computed, what the optional flags change, cost, and determinism — all present. Return-value detail is correctly delegated to the output schema, and the example args make the call shape unambiguous.
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, setting a baseline of 3. The concrete example argument object demonstrates the nested birthData shape and correct timezone/coordinate formatting, which adds real value beyond the schema's per-field text.
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 resource and enumerates exactly what is computed: sidereal (Lahiri) ascendant, nine grahas, twelve houses, yogas, and Vimśottarī daśā, plus optional Western and astrocartography blocks. That is far more specific than the title 'Natal chart'. It never names a sibling (e.g. get_dasha for daśā-only or get_compatibility for synastry), so full sibling differentiation is missing.
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?
Conditional behavior is spelled out well (`western` false omits the Western block, `location` adds astrocartography), which implies when each option applies. However, there is no explicit routing guidance against the many siblings — an agent is left to infer that get_dasha should be used when only daśā periods are needed, or get_compatibility for relationship work.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compatibility of two charts. Computes both charts and reads them together. Each partner object is a BirthData object plus optional name and gender.
Cost: 12 credits per call (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Deterministic: the same input always gives the same answer.
Example arguments: {"a":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209,"name":"A"},"b":{"date":"1991-11-03","time":"06:10","timezone":"Asia/Kolkata","latitude":19.076,"longitude":72.8777,"name":"B"}}
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | First partner: birth data plus optional name and gender. | |
| b | Yes | Second partner: birth data plus optional name and gender. | |
| referenceDateIso | No | ISO date the reading is anchored to. Defaults to now. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive, so the bar is lower; the description still adds genuinely useful traits beyond them: credit cost (12 per successful call), free sandbox behavior, and determinism. It does not describe output shape, but an output schema exists.
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?
Purpose is front-loaded, followed by tightly scoped notes on cost, determinism, and a single compact example. The long example JSON is the only mild overhead but it earns its place as usage illustration.
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, return values need not be explained, and the description covers cost, determinism, sandbox behavior, and the partner object shape. The unaddressed referenceDateIso is the main remaining gap for an otherwise complete definition.
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 rich per-field descriptions, so the baseline is 3. The description adds the fact that `name`/`gender` are optional plus a worked example, but does not explain referenceDateIso or the semantic effect of omitting `time`.
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 resource (compatibility of two charts) and clarifies the mechanism ('computes both charts and reads them together'), which separates it from the single-chart get_chart sibling. It does not explicitly name the sibling it differs from, keeping it just short of a 5.
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 context of comparing two partners is implied, and the example shows the expected two-partner shape, but there is no explicit when-to-use guidance, no when-not conditions, and no routing to alternatives like get_chart or interpret_domain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Vimśottarī daśā timeline. Cost: 1 credit per call (only successful calls are charged; a sandbox key is free and returns a fixed sample). Deterministic: the same input always gives the same answer. Example arguments: {"birthData":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209}}
| Name | Required | Description | Default |
|---|---|---|---|
| birthData | Yes | The person's birth data: date, local time (omit if unknown), IANA timezone, latitude and longitude. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint, destructiveHint=false, idempotentHint, openWorldHint=false), so the bar is lower. The description adds valuable non-obvious context: a credit cost model including that only successful calls are charged and that a sandbox key returns a fixed sample, plus determinism. This is useful operational detail beyond the structured fields.
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 short, line-structured, and front-loads the resource before cost and determinism notes. Each line (cost, determinism, example) earns its place, though 'Deterministic' partially overlaps the idempotentHint annotation.
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 single-parameter tool with full schema coverage, an output schema, and safety annotations, the description supplies the operational facts an agent needs (cost, determinism, sample invocation). Return values need not be explained given the output schema, though the absence of any when-to-use context is a remaining 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% and the nested birthData object is fully documented, so the baseline is 3. The description goes further by supplying a complete, valid example argument object, which concretely demonstrates the required nesting, field names, and format needed to invoke the tool correctly.
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 'Vimśottarī daśā timeline,' which is a verbatim restatement of the title rather than a statement of what the tool does. It supplies no verb (compute/return/list) and no differentiation from siblings like get_chart, get_forecast, or resolve_timing. This is a tautology of the name/title.
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?
There is no indication of when to use this tool versus alternatives such as get_chart, resolve_timing, or get_forecast, which all appear to operate over the same birth data. No prerequisites or exclusions are stated. The agent must infer the tool's role entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ascendant, MC and house cusps. Ascendant, midheaven and twelve cusps for a moment and place. Placidus is undefined beyond the polar circles at some moments; the call then returns 422 houses_undefined_at_latitude. Cost: 0.1 credit per call, billed as 1 credit per started block of 10 Ephemeris calls (only successful calls are charged; a sandbox key is free and returns a fixed sample). Deterministic: the same input always gives the same answer. Example arguments: {"datetime":"1990-05-12T14:35:00+05:30","latitude":28.6139,"longitude":77.209,"houseSystem":"placidus"}
| Name | Required | Description | Default |
|---|---|---|---|
| zodiac | No | sidereal (default) or tropical. | sidereal |
| ayanamsa | No | Sidereal only. | lahiri |
| datetime | Yes | ISO 8601 with Z or an explicit offset, between 1800-01-02 and 2149-12-31 UTC. A time without a zone is refused (invalid_datetime). | |
| latitude | Yes | Geographic latitude in decimal degrees, north positive. | |
| longitude | Yes | East positive. | |
| houseSystem | No | House system for the cusps: whole_sign (default), equal or placidus. | whole_sign |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the read-only/idempotent profile, yet the description adds several things they cannot: Placidus is undefined beyond the polar circles and yields 422 houses_undefined_at_latitude, the cost is 0.1 credit per call billed per started block of 10 with only successful calls charged, sandbox keys are free, and results are deterministic. This is exactly the extra context the description should carry.
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?
Front-loaded with the purpose, then the failure mode, cost, determinism and an example; each sentence carries distinct information. Slightly list-like, but nothing is padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return-value description is unnecessary, and the description still covers the one edge case (polar latitude with Placidus), the billing model, and determinism. Nothing material 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% and the enum values, defaults and lat/long conventions are all documented in the schema, so the baseline is 3. The worked example arguments add a small amount of invocation value but no meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States the resource precisely: ascendant, midheaven and twelve house cusps for a moment and place, which tells an agent exactly what comes back. It does not, however, differentiate itself from nearby siblings such as get_ephemeris_positions or get_chart.
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 statement of when to choose this over get_ephemeris_positions (planetary positions) or get_chart, despite twelve sibling tools. The reader must infer applicability from the returned data alone; there is no when-not guidance either.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ayanamsa values. Lahiri, Raman, Krishnamurti and Fagan–Bradley (mean, without nutation) at a moment. Cost: 0.1 credit per call, billed as 1 credit per started block of 10 Ephemeris calls (only successful calls are charged; a sandbox key is free and returns a fixed sample). Deterministic: the same input always gives the same answer. Example arguments: {"datetime":"2026-10-06T00:00:00Z"}
| Name | Required | Description | Default |
|---|---|---|---|
| datetime | Yes | ISO 8601 with Z or an explicit offset, between 1800-01-02 and 2149-12-31 UTC. A time without a zone is refused (invalid_datetime). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, closed-world, but the description adds traits they do not carry: deterministic output, 'mean, without nutation' (a substantive modeling choice), the credit cost and 10-call block billing, and that failed calls are free and sandbox keys return a fixed sample. That is genuine behavioral value beyond structured fields.
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?
Front-loaded with what is returned, then cost, determinism, and a concrete example. Four short lines, each carrying distinct information; no filler or restatement of the title.
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?
An output schema exists, so return formatting need not be explained. The description covers scope, supported systems, input format, determinism, cost, and error behavior. The only real gap is sibling differentiation — nothing tells the agent when ayanamsa is the right ephemeris call versus angles or positions.
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% — the single datetime parameter already documents ISO 8601 with Z/offset, the accepted UTC range, and the invalid_datetime refusal. The description's example argument only illustrates the format the schema already defines, so it earns the baseline 3 rather than more.
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 the resource precisely — ayanamsa values — and enumerates the four supported systems (Lahiri, Raman, Krishnamurti, Fagan–Bradley) with the qualifying 'mean, without nutation'. However, it never differentiates itself from the other ephemeris siblings (get_ephemeris_angles, get_ephemeris_positions, get_ephemeris_series), so an agent must infer which one it wants.
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?
Usage is implied by the name and the listed systems, but there is no explicit when-to-use or when-not-to-use statement relative to the other ephemeris tools, and no exclusions. The billing/sandbox note is operational context rather than selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Positions at a moment. Sun, Moon, planets and lunar nodes at one moment: longitude, latitude, distance, speed and retrograde flag, with sign, and nakṣatra and pada when sidereal. equatorial: true adds apparent right ascension and declination.
Cost: 0.1 credit per call, billed as 1 credit per started block of 10 Ephemeris calls (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Deterministic: the same input always gives the same answer.
Example arguments: {"datetime":"2026-10-06T06:00:00Z","bodies":["Sun","Moon","Mars","Jupiter","Saturn","TrueNode"],"zodiac":"sidereal","ayanamsa":"lahiri"}
| Name | Required | Description | Default |
|---|---|---|---|
| bodies | No | Default: all twelve. | |
| zodiac | No | sidereal (default) or tropical. | sidereal |
| ayanamsa | No | Sidereal only. | lahiri |
| datetime | Yes | ISO 8601 with Z or an explicit offset, between 1800-01-02 and 2149-12-31 UTC. A time without a zone is refused (invalid_datetime). | |
| equatorial | No | Also return apparent right ascension and declination. Default false. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and non-open-world, so safety is covered; the description goes well beyond that by disclosing the billing model (0.1 credit per call, billed in blocks of 10, only successful calls charged), sandbox-key behavior (free, fixed sample), and a determinism guarantee. It also notes that a zone-less datetime is refused with invalid_datetime — a failure mode an agent needs to avoid. This is exactly the kind of context annotations cannot express.
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?
Purpose is front-loaded in the first sentence, followed by return fields, cost, determinism and a concrete example — a sensible ordering with no filler. It is on the dense side, packing four distinct concerns into one block, but every sentence carries information an agent would otherwise have to guess.
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?
An output schema exists, so return structure need not be re-explained, yet the description still previews the fields usefully. Combined with cost, determinism, sandbox behavior, the invalid_datetime edge case and a full example call, an agent has everything needed to invoke this correctly on the first attempt.
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, but the description adds real meaning: it explains what `equatorial: true` actually yields (apparent right ascension and declination), notes that nakṣatra/pada appear only when sidereal, and supplies a worked argument set showing bodies, zodiac and ayanamsa combined. That is useful semantics beyond the schema text rather than a repetition of it.
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 — 'Sun, Moon, planets and lunar nodes at one moment' with the exact returned quantities (longitude, latitude, distance, speed, retrograde flag, sign, nakṣatra/pada, optional RA/dec). An agent knows precisely what this returns, and the title 'Positions at a moment' reinforces it. It does not, however, differentiate itself from near-name siblings like get_ephemeris_angles or get_ephemeris_series, which a reader must infer from the sibling names alone.
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?
There is no explicit when-to-use or when-not-to-use statement, and no sibling alternative is named despite four other get_ephemeris_* tools in the list. The cost/determinism lines help an agent decide whether to spend a credit, but they are operational facts, not routing guidance. Usage is only weakly implied by the example arguments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Positions over a range. Positions from start to end (inclusive) every stepMinutes, for transit tables and station finding. At most 1,000 points (too_many_points beyond). Price: 1 credit per started 100 points (a 365-point daily table costs 4). Cost: 1 credit per started 100 points (only successful calls are charged; a sandbox key is free and returns a fixed sample). Deterministic: the same input always gives the same answer. Example arguments: {"start":"2026-10-01T00:00:00Z","end":"2026-10-10T00:00:00Z","stepMinutes":1440,"bodies":["Mercury","Venus"]}
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | ISO 8601 with Z or an explicit offset, between 1800-01-02 and 2149-12-31 UTC. A time without a zone is refused (invalid_datetime). | |
| start | Yes | ISO 8601 with Z or an explicit offset, between 1800-01-02 and 2149-12-31 UTC. A time without a zone is refused (invalid_datetime). | |
| bodies | No | Default: all twelve. | |
| zodiac | No | sidereal (default) or tropical. | sidereal |
| ayanamsa | No | Sidereal only. | lahiri |
| stepMinutes | Yes | Minutes between points (1 to 525,600). At most 1,000 points per call. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations (which already cover read-only/idempotent/non-destructive) by disclosing the 1,000-point cap with its error code, per-call credit pricing, that only successful calls are charged, that a sandbox key returns a fixed free sample, and that results are deterministic. This is exactly the operational context an agent needs before committing to a billable call.
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?
Front-loaded correctly and the critical cap appears early, but the pricing sentence is essentially duplicated ('**Price: 1 credit per started 100 points** (a 365-point daily table costs 4)' followed by 'Cost: 1 credit per started 100 points'). That redundancy wastes space in an otherwise tight definition.
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, return values need not be described, and the description covers the operational essentials: caps, cost, determinism, defaults, and an example call. The only gap is that it never routes the agent away from get_ephemeris_positions for single-instant queries.
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 carries the parameter detail and the baseline is 3. The description adds value with a concrete example argument object and by tying stepMinutes to the 1,000-point ceiling, which helps the agent reason about the interaction between the two required params.
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+resource ('Positions over a range'), defines the sampling cadence ('from start to end inclusive every stepMinutes'), and names its audience ('transit tables and station finding'). It implicitly distinguishes itself from get_ephemeris_positions by being range-based, but never names that sibling explicitly, so the differentiation is left to inference.
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 a use context ('for transit tables and station finding') but no when-not guidance and no reference to alternatives like get_ephemeris_positions. An agent can infer this is the multi-point variant, but the description never says what selects it over its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sunrise and sunset. Sunrise, sunset and the next sunrise for a local date and place: upper limb at the sea-level horizon with 36.6′ refraction. The Vedic day runs from sunrise to the next sunrise. Cost: 0.1 credit per call, billed as 1 credit per started block of 10 Ephemeris calls (only successful calls are charged; a sandbox key is free and returns a fixed sample). Deterministic: the same input always gives the same answer. Example arguments: {"date":"2026-10-06","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209}
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Local calendar date, YYYY-MM-DD. | |
| latitude | Yes | Geographic latitude in decimal degrees, north positive. | |
| timezone | Yes | IANA name, e.g. Asia/Kolkata. Defines the local day. | |
| longitude | Yes | East positive. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior, yet the description still adds real value beyond them: per-call credit cost and block billing rules, the fact that only successful calls are charged, sandbox-key behavior, and an explicit determinism guarantee. These are operational traits an agent cannot derive from the structured fields.
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?
Front-loaded with the one-line purpose, then compact labeled lines for cost, determinism and examples. Slightly more than strictly necessary, but every line carries information an agent would otherwise have to guess.
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, the description need not explain return values, and it covers everything else an agent needs: the exact sunrise definition, billing implications, determinism, and a ready-to-use example. Nothing required to invoke it 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 date, timezone, latitude and longitude are already documented with format, ranges and sign conventions. The description's example arguments add a concrete working call but no semantics beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource (sunrise, sunset, and the next sunrise) for a defined local date and place, and pins down the exact astronomical convention (upper limb at sea-level horizon, 36.6′ refraction). This clearly separates it from siblings like get_ephemeris_positions or get_ephemeris_angles, which cover broader ephemeris quantities.
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 note that "the Vedic day runs from sunrise to the next sunrise" implies a use context, but the description never states when to prefer this tool over siblings such as get_ephemeris_angles or get_ephemeris_series, nor any exclusions. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Forward-looking reading for a question. The interpret verdict for domain, voiced as a narrative answer to question by a language model grounded in the classical statements for the domain. Expect tens of seconds; set a client timeout of at least 90 s.
Cost: 8 credits per call (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Voiced by a language model: allow up to 90 seconds.
Example arguments: {"birthData":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209},"domain":"career","question":"How will the next year unfold for my work?"}
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Life area the question is about, e.g. career, marriage, finance or health. | |
| question | Yes | The question in plain language, e.g. "What does the next year hold for my career?" | |
| birthData | Yes | The person's birth data: date, local time (omit if unknown), IANA timezone, latitude and longitude. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, not idempotent, closed-world), and the description adds substantial context on top: it warns of tens-of-seconds latency and a 90 s minimum client timeout, states the 8-credit cost with the rule that only successful calls are charged, and explains that a sandbox key is free and returns a fixed sample. That billing and latency disclosure is exactly the kind of behavior the annotations cannot express.
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 purpose is front-loaded in the first sentence, followed by cost/latency notes and a concrete example. It is a bit dense with repeated latency warnings ('tens of seconds' then 'allow up to 90 seconds'), but every block is actionable and there is no 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 three-parameter, nested-object tool with an output schema, the description covers what is needed to invoke it correctly: cost, latency expectation, sandbox behavior, and a complete example. Return-value detail is legitimately omitted because an output schema exists.
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 carries the parameter meaning and the baseline is 3. The description goes slightly beyond by supplying a full worked example of the three arguments, showing how domain, question, and nested birthData (with timezone and coordinates) are populated together.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it produces an interpretive verdict for a domain, voiced as a narrative answer to the user's question by a language model grounded in classical statements. This distinguishes it conceptually from a raw verdict tool, but it never names a sibling (e.g. interpret_domain or get_guidance), so the agent must infer which of the forward-looking tools to 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?
Usage is implied by 'forward-looking reading for a question' rather than stated as a rule, and there is no explicit when-to-use/when-not guidance against siblings like interpret_domain, get_guidance, or resolve_timing. Cost and timing notes hint at when it is worth calling, but routing guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lifestyle guidance for the running daśā periods. Plain-language guidance cards for each running daśā level (mahādaśā, antardaśā, …) at referenceDate (default: now).
Cost: 3 credits per call (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Deterministic: the same input always gives the same answer.
Example arguments: {"birthData":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209}}
| Name | Required | Description | Default |
|---|---|---|---|
| birthData | Yes | The person's birth data: date, local time (omit if unknown), IANA timezone, latitude and longitude. | |
| referenceDate | No | ISO date or datetime. Defaults to now. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world. The description adds genuinely non-obvious behavioral facts: a 3-credit cost with only successful calls charged, a free sandbox key returning a fixed sample, and determinism of output. It does not describe latency or output shape, but the output schema covers returns.
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?
Purpose is front-loaded in the first sentence, followed by scope, cost, determinism and an example. Every block earns its place, though the inline JSON example is long relative to the rest and could arguably be trimmed.
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 the safety/idempotency profile, the description only needed to add cost, determinism and argument shape, which it does. The one remaining gap is that it never positions itself against the several sibling tools that overlap in purpose.
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 both parameters are already documented, including the optional time and the reduced-house-detail caveat. The description restates the referenceDate default (already in schema) but the worked example does clarify the nested birthData shape. Baseline 3 is appropriate since the schema does 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 states a specific resource ('lifestyle guidance cards for each running daśā level') and enumerates the levels it covers (mahādaśā, antardaśā). An agent can tell it produces interpretive guidance rather than raw daśā periods, but it never names or distinguishes itself from sibling tools like get_dasha or interpret_domain, which occupy adjacent semantic space.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a default for referenceDate, which implies you can omit it, but offers no when-to-use/when-not guidance and no routing to alternatives such as get_dasha (raw periods) or interpret_domain (other interpretative output). The agent is left to infer which of the several guidance-adjacent siblings to call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Domain reading. Deterministic reading of one life domain: verdict, supporting and cautionary factors, timing windows, method agreement and the weighed corpus position. No language model is called. Cost: 5 credits per call (only successful calls are charged; a sandbox key is free and returns a fixed sample). Deterministic: the same input always gives the same answer. Example arguments: {"birthData":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209},"domain":"career"}
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Life area to read, e.g. career, marriage, finance or health. | |
| birthData | Yes | The person's birth data: date, local time (omit if unknown), IANA timezone, latitude and longitude. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/non-destructive, and the description adds real value on top: no language model is invoked, output is deterministic, pricing is 5 credits with only successful calls charged, and a sandbox key returns a fixed free sample. This is exactly the behavioral context structured fields do not carry.
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?
Purpose is front-loaded, followed by tight one-line cost and determinism statements and a single worked example. Slightly long, but every line (credits, sandbox behavior, determinism) 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 annotations and an output schema already present, the description's remaining burden is behavioral and cost context, which it covers well, plus a callable example. The only real gap is sibling routing, which a complex multi-prediction platform arguably warrants.
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 both parameters (including the 15-value domain enum and the nested birthData fields) are already documented. The worked example argument adds a concrete, callable shape but no semantics beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Deterministic reading of one life domain') and enumerates what the reading contains (verdict, factors, timing windows, method agreement, corpus position). It does not name any sibling it is distinguished from, so an agent still has to infer how it differs from get_guidance, get_forecast or get_chart.
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 never says when to choose this tool over the twelve siblings, nor does it state prerequisites or exclusions beyond the domain enum. The cost line and example hint at context but give no routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decision timing. Like forecast, for a decision question, optionally anchored to targetDate or dateRange. Expect tens of seconds.
Cost: 7 credits per call (only successful calls are charged; a sandbox key is free and returns a fixed sample).
Voiced by a language model: allow up to 90 seconds.
Example arguments: {"birthData":{"date":"1990-05-12","time":"14:35","timezone":"Asia/Kolkata","latitude":28.6139,"longitude":77.209},"domain":"career","question":"Should I accept the offer?","targetDate":"2026-11-15"}
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Life area the decision is about, e.g. career, marriage, finance or health. | |
| question | Yes | The decision question in plain language, e.g. "Is this a good time to change jobs?" | |
| birthData | Yes | The person's birth data: date, local time (omit if unknown), IANA timezone, latitude and longitude. | |
| dateRange | No | Optional period the decision is about: start and end dates, YYYY-MM-DD. | |
| targetDate | No | Optional date the decision is about, YYYY-MM-DD. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavioral context beyond the annotations: 7 credits per call with only successful calls charged, a free sandbox key returning a fixed sample, expected latency of tens of seconds up to 90 seconds because an LLM voices the result. Annotations cover the read-only/idempotency profile, so this cost-and-latency disclosure is the real added value.
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 short blocks front-load the purpose, then cost/latency, then an example. Every sentence carries information, though the opening 'Like forecast' is slightly redundant with the sibling comparison already implied by the name.
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, the description needn't explain return values, and annotations plus full schema coverage handle the rest. Cost, latency, and a worked example make it callable without further digging, though it never states prerequisites (e.g., whether birth data accuracy affects results) beyond what the schema notes on omitted time.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents every parameter and the enum domain. The full example arguments object illustrates how birthData, domain, question, and targetDate combine, which is mildly useful, but no syntax or domain meaning is added beyond structured fields. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific function (decision timing for a decision question) and explicitly relates it to the sibling get_forecast while distinguishing the use case. The resource is identifiable, though the phrasing 'Decision timing' as a lead is terse and partly restates the title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage via 'for a decision question' and notes optional anchoring to targetDate or dateRange, but never states when to pick this over get_forecast, find_muhurta, or get_guidance. The guidance is implied rather than explicit.
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.
find_muhurtaget_chartget_compatibilityget_dashaget_ephemeris_anglesget_ephemeris_ayanamsaget_ephemeris_positionsget_ephemeris_seriesget_ephemeris_sunriseget_forecastget_guidanceinterpret_domainresolve_timingVedic and Western astrology for AI agents: charts, dasha, matchmaking, panchanga, numerology, tarot.
Vedic kundli, panchang, dashas, nakshatras and KP charts for AI agents, one API key.
Vedic astrology for AI agents: chart facts, panchang windows, and Guna Milan compatibility.
Professional Vedic astrology tools for AI agents via MCP.
Add one secure layer between your agents and this server.
