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

Beyond the readOnly/idempotent/closed-world annotations, the description discloses what is not persisted (no guest profile or analysis saved), what is not returned (no raw natal positions, no other account data), and that no Luna debit or purchase occurs. It also flags how unknown birth time is handled and sets an eligibility boundary at 18+. That is substantial behavioral context not available 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?

The purpose is front-loaded in a strong opening sentence, but the remainder is a dense policy block with redundancy: the adult boundary is asserted twice (once as 'both birth subjects meet the adult birth-data boundary', then restated with the UTC-date rule), and the no-save guarantee appears in two forms. The content earns its place individually but the ordering and repetition weaken structure.

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

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

With an output schema present and rich annotations, the return shape and safety profile are covered, and the legal/eligibility caveats are thorough. Against a deeply nested otherBirth object at 0% schema coverage, though, the description leaves key call-shaping parameters undocumented, which is a real gap for a tool of this complexity.

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 0%, so the description carries the full burden, yet it explains only a fraction of the inputs: the 31-day cap implies the startDate/endDate window and 'unknown time remains uncertain' gestures at the time variant. The purpose enum (meeting/travel/shared_timing), place, timezone, timeSource, and especially disambiguation (reject/earlier/later) go entirely unexplained, and disambiguation is a nested-object field where wrong choices silently reject requests.

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 first sentence states a specific verb and resource with concrete scope: chart connections and simultaneous symbolic windows between the saved self chart and one supplied birth profile over up to 31 civil days. An agent can distinguish it from calculate_chart or get_profile. It stops short of naming a sibling alternative (e.g. compare_dates or get_timing_month), so the differentiation is inferred rather than stated.

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?

Prerequisites are explicit (linked saved birth details, active Novamris+ access) and the 31-day window bounds usage. However, there is no guidance on when to choose this tool over the timing siblings or over compare_dates, and no statement of when not to use it. The agent must infer the use case from the description alone.

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