Astrodai Vedic Astrology & Ephemeris Engine

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already establish that this is a safe, read-only, idempotent operation. The description adds meaningful behavioral context beyond those annotations by clarifying that it does not perform birth time correction and that birth details are used only for calculation and are not stored.

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 front-loaded with the core purpose and avoids unnecessary wording. The opening sentence is long because it enumerates several outputs, but each clause contributes useful information and the following sentences are brief.

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?

There is no output schema, so the description appropriately explains what the tool returns in plain language: time windows until sign changes, pada and D9/D10 sensitivity, and life chapter date movement per minute. It is sufficiently complete for a three-parameter read-only calculation tool, though it could say more about when to use 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 description coverage is 100%, so all three parameters are already documented in the input schema. The description mentions birth time conceptually but does not add format, validation, or usage details beyond what the schema provides.

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 precise, specific capability: it measures how sensitive the chart is to the recorded birth time, including rising sign, Moon nakshatra pada, D9/D10 rising signs, and life chapter date movement. This clearly distinguishes it from the sibling tools, which cover chart overview, chapters, birthplace lookup, life areas, and panchang.

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 purpose: an agent would use this when birth time accuracy or chart sensitivity is in question. The description also includes a useful exclusion, stating that it does not correct the birth time, but it does not explicitly say when to choose this tool versus alternatives or what prerequisite conditions apply.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations, the description discloses a concrete rate limit (3 answers per chart per 6 hours) shared across life_area and current_chapter, and a privacy/data-handling statement (birth details used only for calculation, a one-way code retained 6 hours for fair-use enforcement). This explains the non-idempotent hint in practical terms. What it does not cover is failure behavior, e.g. what happens when the quota is exhausted or the birthplace token expires.

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, front-loaded with the answer contents before the quota and privacy caveats, so the agent gets the payload description first. The first sentence is dense with parenthetical notation (True Chitrapaksha ayanamsa, month and year) that adds precision but makes it slightly heavy to scan.

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 read-only tool with no output schema, the description fully specifies what the answer contains, the units of the timing output (month and year), the quota cost, the shared quota scope, and the data-retention behavior. An agent can decide to call it and predict the response shape without further information.

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 format and ranges for birth_date, birth_time and place_token. The description adds the prerequisite framing ('place_token from find_birthplace' is echoed from the schema) but no extra semantics such as how the recorded local time is interpreted against timezone or what to do if the birth time is uncertain.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a concrete resource (sidereal birth chart, True Chitrapaksha ayanamsa) and enumerates the exact contents returned: rising sign, Moon sign and nakshatra, Sun sign with one-line meanings, plus the running Vimshottari chapter and sub-chapter. An agent can tell this is the compact snapshot tool rather than a deep-dive like life_area.

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 rather than stated: it is framed as a 'short plain-language summary' and the sibling mentions establish that life_area and current_chapter share the same quota, hinting at a snapshot-first relationship. However, there is no explicit when-to-use rule versus current_chapter, even though the overview duplicates the current Vimshottari chapter that sibling appears to provide, nor any stated prerequisite ordering with find_birthplace beyond the place_token pointer in the schema.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations (which only establish read-only, closed-world, non-idempotent, non-destructive), the description discloses two valuable operational facts: a quota of up to 3 answers per chart per 6 hours shared across three tools, and the privacy handling of birth details via a one-way code retained 6 hours. It does not describe the response shape or latency, but for a read-only astrology lookup this is substantial added context.

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 capability statement is front-loaded and dense but readable, and the quota/privacy clauses are genuinely useful rather than filler. The final two sentences are slightly verbose and repetitive (both restate the 6-hour retention window), which keeps it from a 5.

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 carries the full burden of explaining returns, and it does so concretely: the running chapter and sub-chapter with month and year, plain-language planet meanings, houses, life areas, and the next sub-chapter start. Rate limits and privacy handling are also covered, leaving no major gap for an agent calling a 3-parameter read tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All three parameters are fully documented in the schema, including date format, 24-hour time format, and the 24-hour validity of place_token from find_birthplace. The description adds nothing per-parameter beyond stating that birth details are used only for calculation. At 100% schema coverage 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 names a specific resource — the Vimshottari mahadasha and antardasha running today — and enumerates what the answer contains (planets, their houses, life areas, next sub-chapter start date). It also bounds scope with 'finer periods are not included', which separates it from a full dasha listing. It stops short of explicitly contrasting itself with chart_overview or life_area, only noting they share a quota.

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 scoping line 'finer periods are not included' implicitly tells an agent when this tool is sufficient versus needing a deeper period tool. However, no explicit when-to-use guidance against chart_overview or life_area is given, and those siblings are mentioned only in the context of a shared quota rather than as alternatives. The agent must infer selection criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only, idempotent, non-destructive and closed-world, and the description goes well beyond them: it discloses coverage limits (population floor, latitude cutoff), the result cap of 5 candidates, the presence of a place_token in each result, and a recovery strategy for empty results. That is exactly the kind of behavioral context an agent cannot get 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?

Four short sentences, each carrying distinct information: scope, result shape, query narrowing, and fallback. The dataset limits are front-loaded before the usage tips, and nothing is repeated from the schema or annotations.

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 one required string parameter, no output schema, and no nested structures, the description covers everything an agent needs: what it searches, its coverage boundaries, how many results come back, what the results contain, and what to do on a miss. No meaningful gap remains.

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 single parameter already documents the comma-separated region/country form, so the baseline is 3. The description adds the reason for that syntax ('to narrow the search'), turning a format note into actionable search strategy, which is a modest but real gain over 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 a specific verb and resource ('Look up a town in the Astrodai atlas') and immediately bounds the dataset: towns above ~15,000 people, nothing at or beyond 66 degrees latitude. No sibling tool does place lookup, so there is no ambiguity to resolve, and the scope constraints make the tool's domain unmistakable.

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?

Explains the workflow role by noting the returned place_token is 'for the other tools', which tells the agent this is a first step feeding later calls, and gives explicit fallback advice ('If nothing matches, try the nearest larger town'). It stops short of naming a specific alternative tool or stating when not to call it, but the sibling set contains no competing search tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations (read-only, idempotent, closed-world, non-destructive), it discloses substantive operational facts: a shared quota of 3 answers per chart per 6 hours across chart_overview and current_chapter, and a privacy guarantee that birth details are used only for calculation with a one-way code retained 6 hours. It adds no note on what happens when the quota is exhausted or whether repeat calls return identical output.

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?

Contents are front-loaded with the output payload first, then areas, then limits and privacy. The long enumeration of returned findings is dense but earns its place given there is no output schema; wording is compact with no filler sentences.

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 carries the return-value burden and does so thoroughly, covering payload shape, allowed areas, the health exclusion, quota sharing with siblings, and data retention. An agent can decide whether to call it and what to expect without further information.

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 are already documented in the schema, including the area enumeration and place_token provenance. The description adds no format, range, or constraint detail beyond what is structured, 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 resource ('plain-language findings from the birth chart for one area of life') and enumerates exactly what comes back: house strength, ruling planet and its position, supporting planets, and current-chapter relevance. It also enumerates the eight valid areas and rules out health. The only gap is that it never contrasts itself with chart_overview or current_chapter, which it mentions solely in the quota sentence.

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?

Lists the selectable areas and explicitly excludes health, which is useful when-not guidance. But it gives no direction on choosing between this and chart_overview (whole chart) or current_chapter (chapter detail) despite naming both, so the agent must infer the selection rule from sibling names.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real value beyond that: it discloses the computation reference time (12:00 local unless a time is given), explicitly states what is not returned, and gives a data-handling assurance that birth details are used only for this answer and not stored.

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 tight sentences with the resource definition front-loaded, followed by the calculation-time caveat, then scope exclusions and the privacy note. No sentence is filler, and nothing is buried.

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 usefully enumerates the returned panchang elements, states the computation time basis, and rules out commonly expected fields like sunrise/sunset. It stops short of describing output shape or ordering and does not mention the 1900–2099 date bound or place_token expiry, which live only in the schema.

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 three parameters are already documented, including the 12:00 default and the place_token provenance. The description's 'calculated at 12:00 local time unless a time is given' restates the schema default rather than adding new meaning, 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?

The description enumerates exactly what the tool computes (weekday, tithi, paksha, nakshatra, yoga, karana) for a date and place, which is far more specific than the title 'Panchang for a day'. It also defines negative scope by excluding sunrise, sunset and Rahu kalam, though it does not name a sibling tool to differentiate against.

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 enumeration of panchang elements and the date/place framing, and the exclusion of sunrise/sunset/Rahu kalam tells the agent when this tool is insufficient. However, there is no explicit when-to-use guidance relative to siblings such as chart_overview or birth_time_check, and no statement that place_token must come from find_birthplace.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.