zodiak.info.pl

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

Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so the description's added value is in scope limits: a hard 2020–2035 date range, timezone handling with Polish time as default, and eclipse visibility computed from Warsaw — a location-bound constraint the agent could not know otherwise. It does not discuss result size or how many entries a busy month may return.

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?

A single dense sentence, but it is front-loaded with the core scope ('events of a month') before the enumeration, and every clause contributes concrete content. It is somewhat packed with semicolon-separated lists, though nothing is redundant.

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 and full annotation coverage, the description only needs to convey scope and limits, which it does: date range, default timezone/language, and the Warsaw visibility caveat. The one remaining gap is the absence of any hint about output volume or ordering of the listed events across the month.

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 with defaults and enum values. The description only restates defaults (Polish time, optional Moon sign listing) without adding format hints or edge-case behavior beyond the schema, which is the expected baseline.

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 the exact resource (a month's astrological events) and enumerates its contents precisely: lunations with signs, ingress of the Sun and planets, retrograde stations and periods, eclipses with visibility, and optional Moon sign changes. This distinguishes it from siblings like sky_at (a single moment) and sign_dates (sign boundaries) without the agent needing to open any 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?

Usage is only implied by the content list — an agent can infer this is the tool for month-long event listings rather than a single-moment snapshot. There is no explicit when-to-use/when-not statement and no naming of sky_at or sign_dates as alternatives.

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 a safe, idempotent, closed-world read, so the description's extra context is what counts: it discloses that IANA history governs time zone and summer time, that output is calculations only with no interpretation, that a link opens the full result on the site, and that it reports how near the ascendant and cusps are to changing. Those are genuine behavioral facts not present in 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 purpose is front-loaded in the first clause and every later clause adds a distinct output category, so little is pure filler. The single sentence is dense and the long enumeration of computed artifacts could be trimmed or bulleted for faster scanning.

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 document return values, and it still covers the non-obvious cases: missing birth time, DST resolution via IANA history, and no-interpretation scope. For a 9-parameter astronomical tool it is close to complete, with only parameter interrelationships left 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%, including enum values and range hints, so the schema carries parameter meaning on its own. The description adds only marginal semantic value, mainly the effect of omitting the time parameter; it does not clarify interactions such as place versus lat/lon/tz or the 'later' flag for repeated clock times.

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 a specific verb and resource ('Computes a natal (birth) chart from the date, local clock time and place of birth') and enumerates the outputs, so an agent can tell this apart from sky_at or chinese_year by the natal/birth framing. It does not explicitly name any sibling, so full differentiation is left implicit.

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 useful conditional guidance — 'Without a time it gives what does not depend on the hour' — which tells the agent the time parameter is optional and what happens without it. However, there is no explicit statement of when to choose this over astro_calendar, chinese_year or sky_at, so routing is implied rather than instructed.

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 read-only annotations, the description outlines the specific scope of the tool (1901–2100) and lists complex outputs like 'yin or yang' and 'Lichun'. This defines the functional boundaries and nature of the data being returned.

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 dense but efficient, using the initial clause to front-load the list of all returned data points. While lengthy, every part of the description serves a unique, informative purpose, making the complexity easy to digest.

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?

Given that the tool calculates many specific, complex attributes (elements, Chinese New Year dates, etc.), the description is exceptionally complete. It provides a full map of what the agent can expect, leaving very little ambiguity for successful invocation.

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?

Although schema coverage is 67%, the description adds significant semantic value by detailing how the 'date' parameter should be interpreted (e.g., the year shift for January and February). This crucial contextual information elevates it beyond mere parameter documentation.

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 clearly states the resource being analyzed—the Chinese zodiac—and enumerates the specific data points provided, such as animal, element, and sexagenary name. While it doesn't directly reference sibling tools, the highly specific output profile makes its purpose distinct from general calendar tools.

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 tool provides excellent usage guidance by defining two distinct input modes (year vs. date of birth). Crucially, it includes a vital operational rule regarding January and February births belonging to the previous year, which prevents common agent invocation errors.

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, so the safety profile is fully covered. Beyond that the description adds genuinely useful behavior: the dataset's coverage limits and the Polish-name-first matching with alias tolerance (Londyn and London both work). It says nothing about ranking, partial matches, or what happens when the query is ambiguous beyond the limit hint.

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 tightly packed sentences with the output and scope front-loaded and the sibling routing second. Every clause carries information, though the parenthetical aside about Londyn makes the first sentence slightly dense.

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 two-parameter lookup with a full output schema, the description covers nearly everything an agent needs: what is returned (lat, lon, tz), the dataset boundary, name tolerance, and downstream use. Return-value formatting is correctly left to the output 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 coverage is 100%, so the baseline is 3, and the description earns an extra point by clarifying that query accepts native Polish spellings and alternate names rather than only a canonical string. Limit semantics (how many candidates to return) remain documented only in the schema, not in the description.

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 the exact resource and return payload (coordinates and IANA time zone of a town or city) and bounds coverage precisely: all Polish places plus world cities over 15,000. It also distinguishes the tool from its siblings by naming birth_chart and sky_at as consumers of the result.

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 concrete usage contexts: verifying which place birth_chart or sky_at will resolve to, and disambiguating multiple places with the same name before passing lat, lon and tz onward. It stops short of stating any when-not-to-use condition or what to do if zero results come back.

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 this a read-only, idempotent, non-destructive, closed-world operation, so the safety profile is covered. The description adds a genuinely useful behavioral detail — that retrograde motion produces three crossings per return, so multiple dates appear per cycle — but says nothing about accuracy limits when birth time is omitted, place-resolution fallbacks, or defaults.

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?

It is a single sentence, which is efficient, but it is dense with stacked parentheticals and the clause "each return with its dates and the age" is awkward and partially redundant. The core subject is front-loaded, but readability suffers.

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 8 parameters and a full output schema plus rich annotations, the description only needs to convey intent and the multi-crossing nuance, which it does. Minor gaps remain around birth-time sensitivity and place-resolution behavior, but nothing essential for calling the tool 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 88%, so nearly every parameter (date range, place, lat/lon, tz, time, lang, house_system) is already documented in the schema. The description adds only an oblique reference to "places of birth" and nothing about how place/lat-lon/tz interact or that time is optional, so it sits at the high-coverage baseline.

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 astrological resource — Saturn returns near ages 29/59/88 and Jupiter returns roughly every 12 years — returning each to its birth position, which is enough to tell what the tool computes. It stops short of differentiating itself from the sibling solar_return or stating the operation in a verb-led way, and the phrasing ("come back to their places of birth") is indirect.

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 guidance, no note that a birth date (and ideally birth time and place) is required input, and no routing away from the closely related solar_return or transits siblings. Usage is only implied by the subject matter.

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 the supported year range, default Polish timezone, minute-level precision, and the extra sign-specific output fields. It does not discuss error behavior or edge cases, but the read-only annotations already cover the safety profile.

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 operation and uses only three sentences. It is efficient overall, though the phrase 'With a sign, also its usual first and last day...' is slightly compressed and could be clearer.

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?

Given the rich input schema, output schema, and annotations, the description is complete enough for an agent to call the tool correctly. It covers the main operation, range, timezone default, sign-specific behavior, and the main edge-case use.

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?

The schema coverage is already 75%, and the description adds meaningful semantics beyond the schema by explaining what happens when a sign is supplied: usual first/last day and earliest/latest entry across 1900–2100. It also reinforces the year range and timezone default, though it says little about the lang parameter 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 specific resource and computation: zodiac sign ingress times for a given year, with minute precision and timezone context. It is clearly not a general birth chart tool, though it does not explicitly name sibling tools or draw sharp boundaries against astro_calendar or birth_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?

It gives a clear use case for edge-of-sign birth-date questions, which helps an agent choose this tool over a broader birth-chart tool. It does not state exclusions or name alternatives, so the routing guidance is useful but not fully 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 establish read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower; the description still adds real context by disclosing the 'now' default and that place-dependent fields only appear when a place is given. It omits failure modes (invalid or ambiguous place names have no stated behavior) and pagination/precision caveats.

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?

Dense but front-loaded: the output inventory comes first, the place-conditional second, and the routing examples last. Every clause carries information 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?

With an output schema and rich annotations already present, the description covers what is needed: returned fields, the default time, and the place-dependent extras. Remaining gaps are precedence between place and lat/lon and what happens on an unmatched place name.

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 baseline is 3, but the description adds meaning beyond it: date omission implies the current moment, and place is explained as a mode switch that adds angles and houses rather than just another coordinate input. It does not clarify how place interacts with or overrides lat/lon when both are supplied.

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-and-resource: reports zodiac positions (signs and degrees), retrogrades, aspects, Moon phase and next sign change, and lunations at a moment. The phrase 'at a moment' and the sample questions ('what sign is the Moon in today') implicitly separate it from the natal-chart sibling birth_chart and from astro_calendar/sign_dates, so an agent can pick it 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?

Gives concrete triggering questions and the key rule that omitting the date means 'now', plus the conditional that supplying a place switches on ascendant/midheaven/houses. It stops short of stating when NOT to use it or naming an alternative sibling (e.g. for natal charts or calendar lookups).

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, so the safety profile is covered; the description adds real behavior: the result is a link that opens the sky map, printing supports A4/A3/A6, and the answer additionally lists eclipses within 15 days, active meteor showers, and the NASA picture of the day. Some of that overlaps the output schema, and it says nothing about the link's lifetime or failure modes when a place is not found.

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, but the core is a single sprawling run-on sentence that strings together card contents, print formats, and every returned fact. The information earns its place, yet the structure makes it hard to scan and would benefit from being split into purpose, inputs, and outputs.

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 12-parameter tool with an output schema and read-only annotations, the description covers the important agent-facing facts: default time, place vs coordinates, print formats, and the extra returned data. The remaining gaps are minor edge cases (place not found, conflicting place and coordinates) that the schema partially handles.

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 baseline is 3, but the description adds genuine meaning beyond the schema: it clarifies the default hour as 22:00 when no time is given ('at the given hour, or 22:00'), and explains that title/subtitle map to the card's heading and its line. It does not address precedence when both place and lat/lon are supplied.

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 artifact: it 'makes a printable card of the sky on a day' at a place, and enumerates what the card and answer contain (title, Moon phase, sunrise/sunset, planets, QR code, A4/A3/A6 formats). That is clearly distinguishable from data-returning siblings like sky_at or astro_calendar, which do not produce a card.

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?

Ends with an explicit usage condition: 'Use it when someone wants a gift or keepsake of the night sky on a date,' which tells the agent the intent that selects this tool. It stops short of naming an alternative (e.g. use sky_at for raw sky data instead of a card), so the routing is implied rather than fully spelled out.

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 this a read-only, idempotent, closed-world computation, so the safety profile is covered. The description adds genuinely new behavior: the default year and default location fallbacks, and that the response spans multiple years rather than a single moment. It says nothing about what happens when birth time is unknown, though the schema allows omitting it.

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?

It is a single dense sentence with three nested parentheticals, which packs a lot in but reads awkwardly and buries the output description in a trailing clause. Nothing is truly wasted, but restructuring into purpose-then-output sentences would make it easier 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 13-parameter tool with an output schema, the description covers the core concept, defaults and output content, which is adequate. The notable gap is the unknown-birth-time case and the coordinate inputs, though the output schema and per-parameter schema text offset some of that.

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?

With 62% schema coverage across 13 parameters, the schema carries most of the load, including the lat/lon/tz vs place alternation and the date/range constraints. The description contributes default semantics that the schema does not state (year defaults to current year, place defaults to birth place, return_place overrides it), but it ignores house_system, lang, return_tz/return_lat/return_lon and the optional time entirely.

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 precisely what is computed (the exact minute the Sun returns to its natal position, plus that moment's chart with planets, ascendant and houses) and what else is returned (the returns of following years). It is clear and specific, but it never names the sibling it differs from, so an agent cannot tell from the text alone why to pick this over planet_returns or birth_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?

Defaults are mentioned parenthetically (this year by default, place of birth by default), which hints at typical usage, but there is no explicit statement of when to use this tool, when not to, or which sibling covers adjacent needs such as natal charts, planetary returns or transits. The agent must infer the use case from the purpose sentence alone.

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 safety is covered. The description adds real behavioral context beyond that: aspects are returned most-exact-first, ascendant/midheaven appear only when birth time is known, and a link to the site's double chart is included. It does not describe response size or limits, which keeps it short of a 5.

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 sentences, front-loaded with what is computed, then the input shape, then the scope limit. Almost every clause carries information; the closing note about the link is mildly promotional but still tells the agent something about the response.

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 the nested person-object contract and the ordering guarantee. The one substantive omission is the semantics of house_system, which an agent cannot resolve from any supplied field for a tool involving two charts with possibly different house systems.

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?

Coverage is only 33% at the top level, but the description compensates by spelling out each person object: date, optional time, and place or lat/lon/tz, plus optional name. The notable gap is house_system, an enum parameter documented nowhere in either the schema or the description, so the agent has no basis for choosing placidus vs whole.

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 a specific verb and resource ('Compares two birth charts') and then enumerates exactly what is computed: inter-chart aspects with exactness ordering, and each person's planets in the other's houses. That level of specificity makes it clearly distinguishable from siblings like birth_chart (single chart) or transits without opening any 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?

It scopes the tool explicitly with 'Calculations only, no reading of the relationship', which tells the agent not to expect interpretation. However, it never names the alternatives (birth_chart for one person, transits for time-based comparison), so an agent must infer the sibling routing on its own.

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 genuinely useful behavior beyond that: today is the default day, exact transits are limited to Jupiter through Pluto and span twelve months, and no forecasting/interpretation is performed.

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?

A single dense sentence, front-loaded with the core operation and then enumerating the three output groups, with the "no forecast" caveat closing it. Nothing is wasted, though the colon-list makes it slightly harder to scan than separate sentences would.

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 values need no explanation, and the safety profile is in annotations. However, for a nine-parameter tool the description leaves real gaps: it never says birth data (`date`, optionally `time`/`place`/coordinates) is required, never mentions resolving place names (a find_place sibling exists), and its "a day (today by default)" phrasing sits ambiguously next to the actually-required `date`.

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 89%, so the schema already documents nearly all nine parameters including formats, enums, and ranges. The description adds only the "today by default" default for the day and the twelve-month transit window; it does not clarify the distinction between the transit day (`on`) and the required birth `date`, which is the one semantic an agent could get wrong.

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 operation and resource: planets of a day computed against a birth chart, returning houses, aspects, and twelve-month outer-planet transits. It is clearly distinct from natal-only or sky-snapshot siblings, though it never names those siblings 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?

"Against a birth chart" implies the precondition (you need birth data), and "Calculations only, no forecast" rules out interpretation, but there is no explicit statement of when to choose this over birth_chart, sky_at, solar_return, or planet_returns. Usage must be inferred from the output content described.

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, closed-world behavior, so the safety profile is covered. The description adds real context beyond that: the explicit degradation behavior without a time, and 'Calculations only', which signals no interpretive commentary is produced.

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?

Dense and front-loaded: the return contents come first, then the two operational caveats as short sentences. No filler, though the single long enumeration sentence is heavy and could be split for scanability.

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-value explanation is not required, yet the description spends most of its length listing outputs. With 9 parameters and an unlabeled house_system enum, the description leaves the important 'whole vs placidus' and place-vs-coordinates decisions entirely to 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 89%, so most parameters (tz, lat/lon alternates, date range, lang, node, place) are already documented. The description only contributes the time-dependency note for 'time'; it adds no format or interaction detail beyond the schema (e.g., place vs lat/lon precedence, house_system choice).

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 the specific artifact (a sidereal/Lahiri birth chart) and enumerates its contents: lagna, nine grahas with rashis/nakshatras/padas, whole-sign houses, navamsa, and Vimshottari periods. The 'sidereal zodiac (Lahiri ayanamsa)' qualifier implicitly separates it from the tropical sibling birth_chart, though no sibling is 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?

It gives one useful eligibility rule — omitting the hour drops lagna and houses — which tells an agent when the tool is appropriate versus insufficient. However, there is no guidance on choosing between this and birth_chart, astro_calendar, or planet_returns, and no exclusions.

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