AstralRead

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so safety is covered. The description adds real value beyond that by specifying the output payload (per-page title, one-to-two-sentence summary, link) and the bilingual result support.

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 and return shape are front-loaded in the first sentence, and the long enumeration of supported factor types in the second is dense but each item earns its place by establishing the tool's input domain. Slightly list-heavy, but 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 and only two simple params, the description carries the burden well: it explains what comes back and what inputs are accepted in both languages. Missing details are minor — nothing about result limits, pagination, or what happens when a factor isn't found.

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 'topic' and 'lang' fields are already documented, so the baseline is 3. The description goes beyond the schema's single example by spelling out the full accepted vocabulary of chart factors and by stating 'English or Russian', which materially reduces malformed queries.

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 ('Finds pages of the AstralRead astrology knowledge base for a chart factor') and immediately distinguishes itself from computational siblings like natal_chart or transits_today by returning curated pages rather than chart data. The return shape (title, summary, link) is stated up front.

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 enumerated topic vocabulary (planets in signs/houses, Ascendant/MC, aspects, patterns, Nodes/Chiron, transits) makes the intended use case unmistakable — interpretation lookups rather than chart computation. It does not explicitly name siblings or state when not to use it, which keeps it below a 5.

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 cover read-only, idempotent, non-destructive behavior, so the bar is lower. The description adds two genuinely useful behavioral facts beyond them: omitting birth time degrades output (no houses, Ascendant, MC), and birth data is not stored or logged. It says nothing about failure modes such as unresolvable place names or geocoding limits.

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-loads the output inventory, then usage, then required inputs, then the privacy note — a sensible order with little waste. The opening sentence is long and list-heavy, but every clause carries information about what is returned.

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 explanation and does so thoroughly, and it flags the degraded mode when birth_time is absent. Minor gaps remain around geocoding failure behavior and error reporting for an eight-parameter 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?

Schema coverage is 100%, so the schema already documents all eight parameters including defaults, ranges, and the place-vs-coordinates fallback. The description only restates the priority ('birth date, the place (or coordinates) and ideally the birth time') without adding format or edge-case detail beyond the schema. 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 verb and resource ('Calculates a natal (birth) chart') and enumerates exactly what it returns: Sun/Moon/planet positions, angles, house cusps, and aspects with orbs. The mention of the Swiss Ephemeris and tropical features (Ascendant, MC, Koch/Placidus houses) implicitly separates it from the Vedic sibling, but no sibling is ever named explicitly.

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 clear trigger: 'use it when someone asks for their birth chart or about their placements,' and states the input prerequisites. It does not address when to prefer vedic_chart, sky_today, or transits_today, so an agent must infer the boundary from the tool 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 read-only, idempotent, non-open-world behavior, so the bar is lower; the description still adds non-obvious behavior — that output times depend on language (UTC for English, Moscow time for Russian) and that a page link is included.

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 verb and scope in the first clause, and the two-sentence structure wastes little; the long content enumeration is dense but each item is genuinely informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description compensates by fully enumerating the returned sections (moon sign/phase/illumination, lunations, eclipses, stations, aspects, retrograde list, planet positions) plus the supplementary link.

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 a date pattern and a lang enum already documented, so baseline is 3; the description adds the cross-parameter coupling that lang also determines the timezone of all timestamps, which is not visible in 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 ("Returns the sky of one calendar day from the Swiss Ephemeris") and enumerates the payload contents, which makes it distinguishable from natal_chart, transits_today and the other chart siblings.

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 birth data needed" gives a clear selection signal that separates it from the birth-data tools (natal_chart, vedic_chart, vimshottari_dasha), but no sibling is named as an alternative nor is a when-not condition given.

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 cover read-only/idempotent/non-destructive, and the description adds genuinely new context: Swiss Ephemeris computation, no forecast text generated, and an explicit privacy guarantee that birth data is not stored or logged. What it doesn't clarify is output shape or how an omitted birth_time degrades the result (that detail lives only in 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?

Four sentences, front-loaded with the computed content, then usage, then defaults, then provenance/privacy – a sensible order with little waste. Slightly dense in the first sentence (planet list plus orbs) but the density is substantive, not 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 10-parameter tool with no output schema, the description adequately implies the return contents (tight aspects with orbs, each planet's sign and natal house, Moon phase). It stops short of stating what is omitted when birth_time or place are absent, leaving that to the schema, but nothing essential 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 description coverage is 100%, so the schema already documents every parameter, including the orb-relevant defaults, enums and coordinate/timezone lookups. The description echoes the date-default behavior ('today in the person's time zone') but adds no syntax, precedence or edge-case guidance beyond the schema, so 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 verb ('Lists') and a precisely scoped resource: tight transits of a given day to a natal chart, enumerating the bodies (Moon, Sun, Mercury, Venus, Mars, Jupiter, Saturn), the natal points (planets, Ascendant, MC) and the exact orbs (2°, 3° for Jupiter/Saturn). That scoping separates it from natal_chart (birth chart) and sky_today (general sky) without needing to name them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit usage examples ('what are my transits today', 'what is happening in my chart this week') and the date-default rule, which tells an agent when to reach for it. It does not explicitly exclude cases or point to a sibling like sky_today when the user wants a general sky rather than a natal-based reading.

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 establish read-only, idempotent, non-destructive and closed-world, so the description is free to add real value and does: exact ephemeris convention, mean node for Rahu, which chart elements are produced, and the data-handling guarantee that birth data is neither stored nor logged. That privacy statement is behavior an agent cannot get from any structured field.

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 verb and resource, and the two trailing sentences carry distinct jobs (usage triggers, scope limit, data handling). The first sentence is a long enumerated run-on, but each item in the enumeration is informative output content, so little is wasted.

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, yet the description enumerates the returned chart contents (rashi, degree, house per graha, nakshatra/pada/lord, Moon's nakshatra symbol and deity), which is exactly what an agent needs to know before calling. Input edge cases like unknown birth time are covered by 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 seven parameters (including the birth_time-omission consequence and place/coordinates fallback) are already documented in the schema. The description adds no extra parameter guidance beyond 'birth data', which is the correct baseline-3 outcome when the schema does the work.

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?

Specific verb ('Calculates') plus a precisely bounded resource ('Vedic (Jyotish) birth chart') with the computational basis named (Swiss Ephemeris, Lahiri ayanamsa, whole-sign houses). The scope line 'Pure calculation: no doshas, yogas or predictions' separates it from the sibling dasha/prediction tools and from natal_chart's likely tropical output.

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 concrete user-question triggers ('what is my nakshatra', 'my Vedic chart', 'my rashi / Moon sign in Jyotish') and a clear exclusion ('no doshas, yogas or predictions'). It does not name the sibling that handles those excluded cases (e.g., vimshottari_dasha), so the routing 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.

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, yet the description still adds real context beyond them: the Swiss Ephemeris / Lahiri ayanamsa methodology, the 365.25-day year convention that affects date precision, the caveat that results are classical themes not predictions, and the privacy statement that birth data is not stored or logged. Missing is any mention of failure modes (e.g. unresolvable place names), which keeps it at 4.

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 clause and the enumeration of returned periods is the substance rather than padding. The opening sentence is long and dense with commas, and the trailing sentences (year convention, disclaimer, privacy) are short and purposeful, so it is efficient but not maximally tight.

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 carries the burden of describing the return value — and it does so item by item, including the number of upcoming Antardashas. Combined with the privacy note, the computational convention, and the ready-made example questions, an agent has everything needed to call this correctly for an eight-parameter 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?

Schema description coverage is 100%, so every one of the eight parameters (birth_date, birth_time, place, latitude, longitude, timezone, date, lang) is already documented with format and defaults in the schema. The description adds only the broad statement that 'dates use a 365.25-day year' and does not elaborate on parameter interaction or required combinations, so 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 verb and resource ('Calculates the Vimshottari dasha periods of a birth chart') and then enumerates exactly which periods are produced: Moon's nakshatra, balance of the first Mahadasha, the full Mahadasha sequence, and the Mahadasha/Antardasha/Pratyantardasha running on a date. That output inventory is what separates it from the more general natal_chart and vedic_chart siblings, so an agent can route without opening a schema.

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?

Explicit use context is supplied with two concrete example questions ('which Mahadasha am I in', 'when does my Saturn dasha start'), which is strong positive guidance. It does not name a when-not condition or point at an alternative sibling such as vedic_chart for general chart work, so it stops short of a 5.

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