calculate_7_wisdoms_seed_of_life

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

Annotations already declare read-only, idempotent, non-destructive and closed-world, but the description goes further: zero-auth, stateless, no PII stored, and a clear split between the deterministic `soul_a` payload and the day-dependent `today_living_sky` transits. It also specifies the error contract ('invalid ISO dates return a structured JSON error'), which no structured field covers.

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 sibling routing are front-loaded, and the sentence order moves from what it produces, to when to use it, to guarantees, to parameter fallbacks. The eight-tradition enumeration is long but scopes the output surface for a highly niche tool; a small amount of density is the only cost.

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 complex multi-system computation with six parameters and an output schema, the description covers the missing pieces: auth model, statefulness, determinism versus time-varying output, all optional-parameter fallbacks, and error behavior. Return-value detail is legitimately delegated 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 already 100%, so the baseline is 3, but the description adds consequence-level meaning the schema does not: omitting `birth_time` falls back to 12:00 UTC solar noon, supplying `tz` converts local time to UTC (affecting unequal Chaldean hours), and omitting `lat`/`lon` drops Placidus houses and the Ascendant. That tells an agent what is lost by leaving optional fields out, not just what the fields are.

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 set: 'Compute a single person's deterministic natal chart, VVK-XXXX-YYYY Cosmic Soul Key, and 7-Wisdoms profile', then enumerates the eight traditions covered and adds the `today_living_sky` transit output. It explicitly distinguishes itself from the sibling tools that handle two people (`calculate_3d_soul_synastry`) and 3-31 people (`calculate_family_constellation_matrix`).

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 names the exact selection rule: this tool for one individual, the synastry tool for two people, the constellation matrix for groups of 3 to 31. Prerequisite-free usage is also stated ('Zero-auth and stateless'), so an agent knows no setup call is needed before invoking it.

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