TianJi Astrology

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

With no annotations, the description carries the full burden. It does disclose the offline-vs-online geocoding split (a real network dependency) and the astrological conventions used (Placidus houses, major aspects, classic orbs), which is valuable. But it omits important behavioral facts: that hour/minute default to 12:00 when birth time is unknown, and what that default implies for house accuracy.

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 written sentences with zero filler, front-loading what the tool returns before explaining how to supply location. The example coordinates make the format concrete without bloat; only the missing time defaults keep it from being fully complete.

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 needn't be spelled out, and the description nonetheless summarizes them usefully. Given 11 parameters and no annotation safety profile, the remaining gap is the silent 12:00 default for hour/minute and coordinate sign convention, which matter for correctness but are secondary to the well-covered location handling.

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% across 11 parameters, so the description must compensate and it only partly does. It clarifies the genuinely ambiguous ones — lng/lat/tz_str with a concrete example ('-74.01, 40.71, America/New_York') and the city/nation geocoding fallback — but leaves name, year/month/day ranges, and the hour/minute defaults (12 and 0) entirely undocumented.

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 specific verb and resource ('Compute a full natal (birth) chart') and enumerates the exact deliverables: 10 planets with sign/degree/house/retrograde, 12 Placidus cusps, and aspects with orbs. This clearly distinguishes it from the sibling get_current_transits (which would be current/transit positions rather than a 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?

The description gives a genuine conditional rule for input modes — pass lng/lat/tz_str for exact offline computation, otherwise city+nation get geocoded online — which is useful decision guidance. However, it says nothing about when to pick this tool over siblings like get_current_transits, nor any prerequisite or exclusion conditions.

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?

With no annotations, the description carries the burden and does disclose the key behavioral fact: the data is the current sky at UTC now at Greenwich, so the agent knows the time and reference frame are fixed, not caller-supplied. It doesn't mention the ephemeris source or precision, which is the only real gap.

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 sentence with the resource and time basis front-loaded and the use cases trailing. Every phrase adds information; nothing is 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?

An output schema exists, so return values need no explanation, and zero parameters means there is little to specify. The description covers the one thing that matters (the fixed time/place frame), leaving only minor gaps such as data precision.

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?

Zero parameters gives a baseline of 4. The description arguably deserves credit here for clarifying the implicit defaults — the timestamp is 'now' and the location is Greenwich — which is the only semantic ambiguity a no-param call could carry.

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 concrete resource — today's planetary positions — and specifies the exact time/location basis (UTC now at Greenwich), which separates it from compute_natal_chart and get_sign_profile. It doesn't explicitly say how it differs from those siblings, but 'today' vs 'natal' is inferable.

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?

Three concrete use cases are given ('transit analysis, daily overviews, and timing work'), so the agent knows the context in which to reach for it. No explicit exclusions or named alternatives are offered, which keeps it from 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?

No annotations are provided, so the description must carry the behavioral load. 'Reference card' implies a static, read-only lookup, which is useful, but it says nothing about invalid-sign handling or whether the response is a single record. With an output schema present, return-shape disclosure is not required, so this is a moderate gap rather than a severe one.

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?

One short sentence with no filler that front-loads what the tool is and lists the returned fields. Efficient and appropriately sized.

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?

The output schema covers return values, so the description needn't enumerate them beyond the summary already given. However, for a required free-text parameter with zero schema documentation, the missing input format guidance leaves a real gap.

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 description never explains the 'sign' parameter's expected form (e.g., 'Aries' vs 'aries' vs a date). With a single undocumented required parameter, the description should compensate but does not.

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 ('reference card for a zodiac sign') and enumerates the exact fields returned (element, modality, ruling planet), which clearly distinguishes it from siblings like compute_natal_chart and get_current_transits. It lacks an explicit verb but the noun phrase is unambiguous.

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 guidance on when to use this versus compute_natal_chart or get_current_transits, and no note on prerequisites. The lookup nature is only implied by 'reference card'.

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?

With no annotations, the description carries the behavioral burden and does well: it discloses the >=2 independent factor threshold, per-claim verdicts, and blocked gate behavior. It does not cover malformed input handling or other operational edge cases, leaving a modest transparency gap.

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 critical purpose and gating rule are front-loaded, and the detailed claims example is justified by the complexity and missing schema descriptions. Every element earns its place without redundant 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?

An output schema exists, so return-value details need not be fully repeated, and the description still explains the verdict/gate outcome. Given the tool's complexity and zero schema description coverage, the description supplies enough input structure, workflow context, and pass/fail semantics for an agent to call it correctly.

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 must compensate, and it does: chart_json is identified as exact JSON from compute_natal_chart or get_current_transits, while claims is given a detailed JSON array shape with factor types and examples. This adds substantial meaning beyond the bare string 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?

The description states a specific verb and resource: validate interpretation claims against a chart to prevent hallucination before publishing. It also ties chart_json to sibling tools compute_natal_chart and get_current_transits, making its role distinct from those generators.

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 clearly says to use this as a confirmation gate before publishing claims and what to do when blocked: rewrite against verified factors or drop the claim. It does not explicitly describe when not to use it or name alternative validation paths, so it falls short of full when/when-not guidance.

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