NatalChart.AI Astrology

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

Annotations already declare readOnlyHint, openWorldHint=false and idempotentHint, so the safety profile is covered. The description's only extra disclosure is the '(API Pro)' tier marker, which usefully signals a subscription requirement, but it says nothing about result ordering, pagination, or how ranking is computed.

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 with the resource and scope front-loaded, plus a trailing tier marker. No filler, though the parenthetical tier tag is slightly detached from the sentence flow.

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 4-parameter tool with a nested required object and no output schema, the description should at least sketch the return shape; 'catalogue ... ranked' implies an ordered list but nothing is said about what a ranked city entry contains or how ties/limits behave. Adequate but with clear gaps.

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 0% schema description coverage the description must carry the burden, and it partially does: 'chosen life spheres' maps to focus and 'worldwide or in one region' maps to region. However, 'limit' (3-12) is never mentioned, and the relationship between the nested birth object and the chart is only implied.

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 (catalogue of major cities) and what is done with it (ranked for one chart, overall or by life spheres, worldwide or by region). An agent can distinguish it from the temporal best_days sibling, 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?

The phrase 'for one chart' implies birth data is required and that results are scoped to a single natal chart, but there is no explicit when-to-use, when-not-to-use, or comparison against the obvious alternatives best_days and location_score. Guidance 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.

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

Annotations cover the safety profile (readOnly, idempotent, closed-world), so the bar is lower. The description adds real value beyond them: the 62-day window cap, the returned ordering ('five best days first'), the per-day scoring ingredients (transits, Moon phase/sign, void of course), and an API Pro gating signal.

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 compact sentences, front-loaded with what gets produced and what feeds the score. The trailing '(API Pro)' note is slightly orphaned but not wasteful.

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 does the necessary work of describing the return shape (per-day scores, five best first, which factors are included). Combined with annotations, an agent has enough to call it correctly, though the sparse parameter coverage leaves the birth object under-explained.

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 only 40% across 5 parameters, so the description should carry more weight. It repeats the activity enum values and restates the 62-day window that the schema already documents in 'to', and says nothing about the nested birth object's date/time/coordinate semantics.

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: every day of a window scored for one activity, with the scoring inputs enumerated. It is clear what the tool produces, though it never contrasts itself with siblings like daily_transits or transits that also surface day-level astrological data.

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 guidance. The parenthetical '(API Pro)' hints at an access tier but the description never tells an agent when to prefer this over daily_transits or transits, leaving the choice to inference.

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 readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral note, 'No generated text' (pure calculation, no narrative), but says nothing about response size, whether the week's events always appear, or how missing birth time alters the result beyond the schema's own note.

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 with no filler; the most important content (what is returned) is front-loaded. It is slightly run-on, packing four distinct outputs plus a conditional and a caveat into one clause chain, which costs a little readability.

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 it does describe the returned contents and the effect of the birth parameter, including the planet-by-planet transit orbs. It stops short of stating prerequisites or routing guidance, but for a two-parameter calculation tool it is largely sufficient.

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 only 50% (date and most birth fields documented, latitude/longitude not). The description compensates by clarifying the conditional role of the birth object: it activates the natal transit computation, otherwise only sky/phase/events are returned. That adds meaning beyond the schema, though it does not address the undocumented coordinate fields.

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 concrete outputs: the sky at noon UTC, the Moon's phase, the week's sky events, and, with birth data, transits to the natal chart with orb. That is a specific, verifiable content claim. It does not explicitly distinguish itself from the close siblings 'sky' and 'transits', which it appears to combine, so an agent must infer the boundary.

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 statement of when to choose this over 'sky', 'transits', 'natal_chart', or 'solar_return'. The only usage signal is the implicit conditional 'with birth data', which hints that natal transits require birth data but does not frame alternatives or exclusions.

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, and openWorldHint=false, covering the safety profile. The description adds useful context beyond that: the '(API Pro)' tag signals an access requirement, and it names the returned payload (angles, planets with orbs, life-sphere scores), but it does not discuss rate limits, error handling, or the time-null withholding behavior documented 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?

The description is a single front-loaded sentence with a parenthetical tier note; every element contributes and there is no filler. It is perhaps overly terse for a tool with nested parameters, but it is structurally clean and free of redundancy.

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 tool with two nested required parameters, no output schema, and only 0% top-level schema description coverage, the description is too thin. It helpfully enumerates the returned contents, but it omits input format expectations and the important behavior around unknown birth time, which the schema alone must carry.

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?

Top-level schema description coverage is 0%, and the description does not explain the two required objects (birth and location) or their required fields. It only vaguely maps to the two inputs via 'one place against one chart', leaving the agent to read the nested schema for all meaningful parameter detail.

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 identifies the resource and output: astrocartography for one place against one chart, returning relocated angles, planets with orbs, and life-sphere scores. It implicitly distinguishes itself from multi-place siblings like best_cities by saying 'one place', but lacks an explicit action verb such as 'computes' or 'scores' to remove all ambiguity.

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 guidance on when to use this tool versus alternatives. The phrase 'One place against one chart' hints at a single-location use case compared to a multi-location tool, but no sibling is named and no conditions or exclusions are stated.

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, and closed-world, so the safety profile is covered. The description adds the default behavior ('full by default') and the contents of each part, but says nothing about computation cost, failure modes, or how unknown birth times affect output (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?

Front-loaded with the purpose, then a single long but information-dense sentence covering the parts and the default. Every clause carries meaning, though the enumeration is heavy enough that it reads as a list rather than terse prose.

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 burden of explaining return contents and does so thoroughly for each part value. It leaves error behavior and the birth sub-field semantics to the schema, which is reasonable given those fields are individually documented there.

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 0% and the 'part' enum has no per-value description in the schema, yet the description enumerates every enum value and spells out exactly what each returns (bodies with sign/degree/speed/retrograde/house, angles, twelve Placidus cusps, aspects with orbs, balances, fixed stars). This is precisely the compensation a low-coverage schema needs.

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?

Opens with a concrete verb+resource: computes a natal chart from birth data, and the 'part' enumeration makes the scope of what is returned unambiguous. It does not differentiate itself from siblings such as solar_return, synastry, or transits, so a 5 is not warranted.

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 helps the agent choose an output shape ('full by default', or one specific part), which is a form of usage guidance. It offers no guidance on when to choose natal_chart over the sibling chart tools (synastry, solar_return, transits), and no exclusions or prerequisites are stated.

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 and a closed world, so safety and repeat-call behavior are covered. The description adds only the default-date behavior, which is genuinely useful but is also echoed in the schema; nothing about return volume or coverage window beyond 'coming week' is disclosed.

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 front-loaded sentence that leads with the payload and ends with the argument syntax and default. No filler, nothing 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?

For a one-optional-parameter, read-only lookup with no output schema, the description conveys both what comes back and the default date behavior, which is enough to call it correctly. A brief note on the time basis of the 'coming week' window would make it fully complete.

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 single date parameter is already documented as YYYY-MM-DD with a today (UTC) default. The description restates the same format and default, adding no new semantic detail, 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?

Names the concrete outputs (planetary positions, Moon phase, week's sky events) scoped to a single date, which is far more informative than the terse name 'sky'. It does not explicitly contrast itself with siblings like transits or daily_transits, which could plausibly overlap, so it stops 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?

Usage is implied by 'for a date ... today by default', which tells the agent the natural calling context. There is no explicit statement of when to prefer this over transits/daily_transits/natal_chart, and no exclusions, so it remains implied rather than stated.

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=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds the useful facts that the chart can be cast for a location other than the birth place and that this is an API Pro feature, but says nothing about return contents, precision, or failure behavior for unknown times.

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 compact sentence plus a tier tag; nothing is padded or redundant, and the core purpose is front-loaded. It is arguably under-specified rather than over-long, but as structure goes it is efficient.

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 tool with a nested birth object, an optional location override, and no output schema, the description is thin: it never indicates what the returned chart contains or how a missing birth time (documented as suppressing time-dependent values in the schema) affects the result. Annotations cover the read-only/idempotent profile, so the gap is moderate rather than severe.

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?

Top-level parameters (year, birth, location) carry no schema descriptions, though the nested birth object does document date, time, and timezone. The phrase 'cast for the birth place or another location' partially compensates by clarifying that location is an optional override of the birth coordinates, but year constraints and the location shape are left unexplained.

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 product (the solar return chart) and its scope (one year, cast for the birth place or another location), so an agent knows what is produced. It does not, however, distinguish this from closely related siblings like natal_chart or transits, leaving the agent to infer the difference from the name 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 when-to-use guidance, no prerequisites, and no mention of alternatives such as natal_chart or transits. The only routing signal is the parenthetical '(API Pro)', which hints at an access tier rather than a usage condition.

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=true, idempotentHint=true and openWorldHint=false, so safety and determinism are covered structurally. The description adds the output contents and a hint at tier gating, but says nothing about what happens when a birth time is missing or how the computation degrades.

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 front-loaded sentence that enumerates the three deliverables without padding. It is efficient, though the parenthetical tier tag is cryptic.

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 sketches the return shape (aspects, overlays, sphere scores), which is the most important gap it could fill. It still omits parameter intent and any behavior around unknown birth times, leaving the complex nested input under-explained.

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?

Top-level parameter coverage is 0%: neither personA nor personB is described, so the two-object contract is left to the nested schema. The description adds no parameter meaning at all, and it does not explain the symmetry or ordering requirements of the two birth-data objects.

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 action (compare two charts) and names three concrete outputs: inter-chart aspects with orbs, house overlays both ways, and a per-sphere score. This distinguishes it from the single-chart natal_chart sibling, though it never names that alternative 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?

There is no when-to-use guidance, no comparison against natal_chart or transits, and no note on prerequisites such as the API Pro tier except the terse '(API Pro)' tag. The user must infer that this is the two-person compatibility tool purely from the name.

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, and non-open-world behavior, so the safety profile is covered. The description adds genuinely new context: the hard 92-day window cap and the '(API Pro)' access requirement, which an agent needs before invoking 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?

A single, front-loaded sentence that enumerates the payload contents without filler. The trailing parenthetical is the only element that slightly interrupts the flow.

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 nested-object tool with no output schema and sparse schema descriptions, the definition is only partially sufficient: it lists returned data categories but does not explain the default `from` behavior, the response shape, or how the large event list is delivered.

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 only 33%, so the description should compensate, but it only loosely echoes the 'up to 92 days' window already documented on the `to` field. The `from` parameter and the nested birth fields (notably latitude/longitude/timezone) receive no additional clarification.

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 (transit events) and spells out the contents: transit-to-natal aspects by date, sign ingresses, and stations. It is clearly distinct from natal_chart or synastry, though it does not explicitly contrast with the nearby sibling daily_transits.

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 guidance on when to choose this over daily_transits or sky, nor any stated prerequisites beyond the parenthetical '(API Pro)'. The 92-day window hints at scope but not at tool selection.

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=true, idempotentHint=true, and openWorldHint=false, covering the safety profile. The description adds that it costs nothing and indicates return content (plan, count, refill time), but doesn't go beyond annotations with details like rate limits or auth requirements.

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 a single, efficient sentence that front-loads the key information ('Your plan, today's count and when the pool refills') and adds a concise bonus ('Costs nothing'). No waste.

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 simplicity of the tool (no parameters, no output schema), the description is minimally adequate. It conveys what the tool returns but could be clearer about it being an API usage or quota check, and lacks explicit usage context.

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 zero parameters, the baseline is 4. The description doesn't need to explain parameters, and the schema is empty, so this dimension is adequately handled.

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 vaguely refers to 'your plan, today's count and when the pool refills,' which aligns with the title 'Requests left today' but doesn't specify API request quota in clear terms. It distinguishes from siblings like best_cities or transits by its focus on usage, but lacks a precise verb+resource definition.

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 explicit guidance on when to use this tool versus alternatives is provided. The phrase 'costs nothing' hints at free usage, but no when-to-use or when-not-to-use conditions are stated.

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