Yinyang Masters

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 covered. The description adds real value by disclosing what the result contains (Ten Gods, Hidden Stems, Na Yin, Shen Sha, Five-Element strength), which matters because there is no output schema. It does not mention the default solar_time or any date-range/validation behavior, keeping 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?

A single front-loaded sentence that names the operation first and then lists outputs; no filler or repetition. The dense enumeration is justified because it substitutes for a missing output schema.

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 read-only chart generator with fully documented parameters and no output schema, the description covers both what it does and what it returns. Minor gaps remain around timezone/lunar-conversion assumptions and how gender affects the chart, but nothing essential to invoking it correctly 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 description coverage is 100%, so all three parameters (gender, solar_date, solar_time) are already documented in the schema, including the 08:30 default. The description adds no additional meaning about formats, accepted gender values, or timezone handling, so the baseline 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?

The description gives a specific verb ('Lập' = cast/create) plus a specific resource ('lá số Bát Tự Tứ Trụ') and enumerates the chart components produced (Can Chi 4 trụ, Thập Thần, Tàng Can, Nạp Âm, Thần Sát, Ngũ Hành statistics). This clearly separates it from siblings like tuvi_chart_vn or calculate_numerology by domain, though it never names an 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 prerequisites, and no mention of when a different chart tool (tuvi_chart_vn, get_birth_chart, calculate_numerology) would be the better choice. The agent must infer the use case entirely from the tool name and the enumerated outputs.

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 safety is covered. The description adds genuinely non-obvious behavior — habits exceeding the remaining minutes are omitted but explicitly listed, phasing is weekly with check-in days — yet says nothing about the return shape, whether plans vary by goal, or how numerology themes are injected.

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 sentences, front-loaded with the deliverable, then the constraints and the optional enhancement. No filler or restated title, and the parenthetical about omitted habits is placed exactly where it matters.

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 four-parameter, read-only generator with full schema coverage and no output schema, the description covers scope, constraints and optional enrichment well enough to call correctly. The remaining gap is the result format — the agent cannot say what the plan object looks like — which matters slightly more given no output schema exists.

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% and the schema already explains each parameter including the enum values and the 5-240 minute bounds, so the baseline is met. The description still adds meaning by tying minutes_per_day to the exclusion-and-listing behavior and birth_date to the personal-month alignment, clarifying what those inputs actually change.

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 ('Build a structured 30-day habit plan') plus the inputs that shape it (time budget, week-by-week phasing, optional numerology alignment). It is clearly distinguishable from sibling build_productivity_plan and from calculate_numerology/plan_my_personal_year, which it only optionally draws on.

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 implies when to use it (a user wants a 30-day habit plan within a daily time budget) and names the optional birth-date condition, but it never states when to prefer this over build_productivity_plan or the numerology siblings, nor any prerequisites 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=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context about the output ('at least 8 real profession-specific tasks into high-impact operational quadrants'), but says nothing about whether the plan is persisted, how long the generated content is, or whether repeated calls vary.

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 definition is two sentences and front-loads the action and artifact before the framework inventory. Some promotional wording ('rigorous', 'proven') and the long parenthetical role list consume space without adding selection value, but nothing is structurally confusing.

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, read-only generator with no output schema, the description covers what the tool returns at a structural level (quadrants, minimum task count) and how frameworks shape the result. It is close to complete; the only missing piece is how it relates to the other planning-oriented sibling tool.

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 both parameters are already documented, and the description's profession and framework lists largely restate the schema examples. The one additive detail is the implicit expectation that 'profession' should map to a recognized role so the 8 tasks are domain-specific, but no format guidance is given for free-text values.

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 gives a specific verb and artifact ('Construct a rigorous daily productivity matrix') and names the framework and profession dimensions it works over, so an agent knows exactly what will be produced. It does not name or contrast any sibling such as build_habit_stack, leaving the boundary between a 'productivity plan' and a 'habit stack' to inference.

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 phrase 'tailored to your specific profession', which suggests calling it when the user wants a profession-specific daily plan. There is no explicit when-to-use statement, no when-not, and no pointer to the nearest alternative (build_habit_stack) for users who want habit tracking rather than a one-shot schedule.

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. The description adds that the computation follows the Pythagorean system and what numbers result, but says nothing about determinism limits (e.g., name normalization, diacritics, invalid dates) beyond what annotations supply.

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 well-formed sentence that front-loads the verb and system, then lists outputs, then inputs. No redundant or filler wording.

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 simple two-parameter, read-only calculation tool with no output schema, the description usefully enumerates the returned numbers, which compensates for the missing output schema. Only the response shape (e.g., whether the numbers come as an object or text) is left unstated.

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 both parameters are already documented in the schema with constraints (maxLength 120, YYYY-MM-DD format). The description only restates the inputs generically, adding no new meaning such as handling of middle names or time zones.

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 verb (Calculate), the specific system (Pythagorean numerology), and enumerates the outputs produced: life path, expression, soul urge, karmic debt. This clearly separates it from numerology-adjacent siblings such as decode_angel_number, though it does not explicitly name a sibling it differs from.

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, and no mention of alternatives like decode_angel_number or plan_my_personal_year. The required inputs (birth name and date) only weakly imply the appropriate context.

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 safe, idempotent, closed-world read, so the safety burden is covered; the description adds real behavioral context by disclosing that Moon and Rising layers only activate when birth time and location are supplied. It also frames the response stance ('constructive strengths and mindful growth areas'). It does not disclose degradation behavior when only one person's time/location is given, which is the main remaining behavioral 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?

Three sentences: method and scope first, conditional data depth second, output framing third. No filler, no restatement of the title, and the most important routing information is front-loaded.

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 a fully documented schema, strong annotations, and no output schema, the description covers purpose, methods, conditional input requirements, and the flavor of the return. The only missing piece an agent might want is guidance on partial data (one person's time known, the other's not) and whether the coordinates/timezone must be supplied as a complete set.

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 meaning the schema lacks: it explains why latitude/longitude/timezone/birth_time exist collectively — they gate the Moon and Rising computations rather than being incidental data. It adds nothing about person names or relationship_type, but the enum options are self-explanatory in the 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?

States a specific verb and resource ('Analyze multi-layered compatibility between two people') plus the exact methods used ('Pythagorean Life Path numerology and Western tropical Sun signs'), which cleanly separates it from sibling single-person tools like get_birth_chart, get_transits, and calculate_numerology. An agent can identify the two-person relational scope without opening the 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?

The conditional clause 'If exact birth times and locations are provided, incorporates Moon emotional resonance and Rising ascendant dynamics' tells the agent when to supply the six optional location/time parameters and what depth they unlock. It gives clear usage context but never routes the agent away from adjacent siblings (e.g., get_birth_chart for a single person's chart), so it stops short of explicit 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?

The annotations already establish that this is a read-only, idempotent, non-destructive, closed-world operation. The description adds meaningful behavioral context by calling it a 'three-question reflective' check and by disclosing the kinds of esoteric outputs returned, while the 'not a diagnosis' line sets an important expectation.

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 two compact sentences with no filler. The purpose and outputs are front-loaded in the first sentence, and the second sentence provides a concise, relevant caveat.

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 low-complexity reflective tool with full annotation coverage and no output schema, the description supplies enough context to understand the tool's purpose and expected result type. It does not explain the optional nature of two of the three parameters or how their inputs affect the result, but the schema covers those details adequately.

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 each of the three enum parameters already has a clear explanation in the schema. The description reinforces the idea of three reflective questions but does not add parameter-level meaning beyond what the schema already provides, so the baseline score is appropriate.

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: a three-question reflective chakra check that suggests an energy center to focus on. It also lists the concrete outputs (theme, element, frequency, affirmation, crystal), making it clearly distinguishable from unrelated siblings such as draw_tarot_cards or bazi_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 an intended-use context with 'For self-reflection; not a diagnosis,' which usefully frames when the tool is appropriate. However, it does not explicitly compare this tool with relevant siblings like find_my_crystals or find_healing_frequency, nor does it state when not to use it beyond the diagnosis caveat.

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, non-destructive and closed-world, so the safety profile is fully covered. The description's one real contribution is stating what the response contains — symbolic reflection, life-domain resonance, and a single concrete mindful action — which is valuable given there is no output schema, but it stops short of noting determinism (same number+context yields same reading) or limits on supported inputs.

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 compact sentences, front-loaded with the capability and followed by the deliverable. The parenthetical number lists are efficient illustration rather than padding, though they partly duplicate the examples already present in the schema's 'number' description.

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 simple two-parameter, read-only lookup tool with no output schema, the description covers the essentials: what inputs are in scope and what the caller gets back. The only meaningful gap is the absence of any routing hint toward the overlapping numerology sibling.

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 both 'number' and the 'context' enum are already fully documented, establishing a baseline of 3. The description's phrase 'current life domain resonance' loosely gestures at the context parameter but never names it or explains how the enum values (love, career, twin_flame...) change the reading, adding little beyond the 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?

Uses a specific verb ('Interpret') and enumerates the exact resource classes it covers — angel numbers, master numbers, karmic debt numbers — with concrete examples (111, 444, 11, 22, 13, 14). An agent can tell this is a number-symbolism decoder rather than a chart or tarot tool, though it never explicitly contrasts itself with the sibling calculate_numerology, which overlaps conceptually.

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: you have a number sequence and want its meaning. There is no statement of when to prefer this over calculate_numerology or karma_chart_read, no note on which numbers are valid versus rejected, and no mention of what to do if the user's number is not in the supported set.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the exact shape of each returned card (position, orientation, keywords, element) and the seed mechanism for reproducibility, which is valuable given idempotentHint=false and no output 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?

Three short sentences with the action front-loaded, followed by return shape and the seed note in descending order of importance. No filler or redundant phrasing; every clause carries information an agent can act on.

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 correctly compensates by enumerating the returned fields, and annotations cover the safety profile. Minor gaps remain around spread-specific behavior (number of cards per spread, whether the question affects the draw), but nothing needed to invoke the tool correctly 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 description coverage is 100%, so the schema already documents seed, spread, question and allow_reversed, including the full spread enum. The description restates the seed reproducibility semantics already present in the schema and adds nothing about how 'question' influences the draw or what card counts each spread yields, so baseline 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?

States a specific verb and resource ('Draw tarot cards') plus the selection mechanism ('using a chosen spread'), which is enough for an agent to identify the operation. It does not name or contrast any sibling, but no sibling in the list offers tarot drawing, so the name alone disambiguates.

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 a question using a chosen spread' implies the usage context, and all parameters are optional with defaults, so the tool can be called with no arguments. However, there is no explicit when-to-use guidance, no statement of when not to use it, and no pointer to related divination siblings such as check_compatibility or get_daily_cosmic_weather.

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, closed-world, non-destructive behavior, so the safety profile is covered. The description adds genuine context beyond that: it names the calculation method and its boundary condition (Lunar calendar year determined by the Tết/Lunar New Year boundary) and discloses the output content (governing virtues, spiritual strengths, invocation prayer). It does not discuss error handling for malformed dates.

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 the core capability, then the calculation nuance, then the payoff. Minor marketing residue ('sacred invocation prayer', 'lifelong') but nothing structurally wasteful or out of order.

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-parameter, read-only divination lookup with no output schema, the description covers what it computes, how the input is interpreted, and what categories of result come back. Only edge behavior (e.g. invalid or ambiguous dates, response shape) is left unaddressed, which is a modest gap at 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 100% and there is a single parameter, so the baseline is 3. The description earns above baseline by explaining the behavioral consequence of the two accepted input forms — that supplying a full year triggers exact Lunar-year resolution against the Tết boundary, which the schema does not convey.

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 (identify) and two specific resources (Guardian Angel from the 72 Kabbalistic Angels / Shem HaMephorash, and Patron Bodhisattva / Bát Đại Bản Mệnh Phật) derived from birth date. This is clearly separable from siblings like calculate_numerology, bazi_chart, or tuvi_chart_vn 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?

Usage is implied rather than stated: an agent can infer this applies when a user asks about guardian angels or patron buddhas. There is no explicit when-not guidance and none of the 20 sibling tools are named or ruled out (e.g. versus calculate_numerology or decode_angel_number), leaving routing 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description's own contribution is the wellness/non-medical framing plus a hint that the output is a frequency suggestion (e.g. 528 Hz). It does not say how many suggestions come back or whether both inputs can be combined, so meaningful behavioral gaps remain.

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 core purpose, then examples, then scope. Two sentences, no filler. The parenthetical enum examples lightly overlap with the schema but help an agent recognize intent quickly.

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 simple, zero-required-parameter lookup with 100% schema coverage and complete annotations, the description supplies enough to call it correctly. The only shortfall is not indicating the shape of the returned suggestion (single frequency vs. a list with labels), and no output schema exists to cover 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?

Schema description coverage is 100% and both parameters are fully enumerated, so the schema does the heavy lifting. The description adds modest value by naming representative goal values and indicating that a chakra is an alternative way to query, rather than explaining anything the schema lacks.

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 ('Suggest') plus resource ('Solfeggio and tuning frequencies') with concrete examples (528 Hz, 432 Hz) and the two input lenses named (goal, chakra). It is immediately distinguishable from the astrology/tarot/numerology siblings, though it does not explicitly state that distinction.

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?

Clear usage context: it is for a listening or meditation goal, or for a chakra, and it is framed as 'for relaxation and reflection; not medical advice'. It gives a scope boundary but no explicit when-not-to-use or alternative tool routing, which is a minor gap given no sibling competes for this intent.

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, closed-world and non-destructive, so the safety profile is covered. The description adds genuine behavioral context by disclosing the result set (top three crystals) and its fields (chakra, element, placement) in the absence of an output schema, though it says nothing about input validation or partial-questionnaire behavior.

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 clauses, front-loaded with the action and then the output, with no filler. The single-sentence density is efficient, though splitting the input and output halves would read marginally cleaner.

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 and five optional parameters, the description carries the return-value burden and does so adequately by naming the top-three shape and result attributes. It stops short of explaining what happens with zero answers or how results are ranked, minor gaps for a read-only recommendation tool.

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% with rich enum descriptions, so the baseline is 3. The description adds real value by translating the five parameters into user-facing questionnaire dimensions (life focus, challenge, chakra, placement, style), which bridges the vocabulary gap for an agent populating an all-optional intent form.

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+resource ("match crystals to an intention") and enumerates the questionnaire dimensions, so an agent knows exactly what this produces. It does not explicitly distinguish itself from adjacent siblings like check_my_chakras or find_healing_frequency, which keeps it at 4 rather than 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 "using a short questionnaire" and the intention-matching framing, so an agent can infer this is the tool for crystal recommendations. However, there is no explicit when-to-use/when-not guidance and no named alternative among the many spiritual-guidance siblings.

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 genuinely useful behavioral context beyond that: the exact astrological conventions applied (tropical zodiac, Placidus houses) and that exact input precision is mandatory, which shapes how the agent must gather data. It doesn't discuss failure modes for invalid timezones or ambiguous times, which the dst_fold parameter implies exist.

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 sentences, front-loaded with the calculation and its conventions, followed by prerequisites. Every clause carries information an agent needs, and nothing is repeated or padded.

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 enumerates what comes back (signs, planets in houses, tightest aspects), which is what an agent needs to report results. The gap is the absence of guidance on precision tolerance, ambiguous DST times, or what happens with unknown birth times — relevant for a 7-parameter, 5-required precision tool.

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 every parameter is already documented, including the IANA format hint and the instruction not to guess birth time. The description restates those same requirements ("exact birth date, local birth time, IANA time zone and birthplace coordinates") without adding format, range, or edge-case meaning. Baseline 3 is appropriate since the schema carries the load.

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?

Uses a specific verb and resource ("Calculate a Western natal birth chart") and names the underlying system (tropical zodiac, Placidus houses) plus the concrete outputs: Sun/Moon/Rising, planets in signs and houses, tightest major aspects. This lets an agent distinguish it from siblings like bazi_chart or tuvi_chart, which are different astrological systems, 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?

The description clearly establishes the invocation context: it requires exact birth date, local birth time, IANA timezone and coordinates, which tells an agent this is a precision calculation, not a rough or date-only reading. It stops short of naming alternatives (e.g. get_transits for current sky positions) or stating when not to use it, so it falls short of 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds real context beyond that: the tool needs no personal birth details and defaults to today, and it effectively discloses the shape of the results by naming the data categories returned. It still says nothing about formatting, units, or error handling for out-of-range dates, so with annotations carrying the safety burden a 3 is apt rather than a 4.

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 core capability is front-loaded in the opening clause, and the enumerated output categories are dense but each earns its place by telling the agent what it will receive. The trailing prerequisite sentence is short and purposeful; the only minor cost is a fairly long first sentence.

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?

This is a single-parameter, zero-required, read-only tool, and the description compensates for the absent output schema by listing the returned data categories and for the absent auth story by noting no birth details are needed. Nothing essential to a correct call is missing, though a note on date-range errors would make it 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 parameter already documents YYYY-MM-DD, the UTC default, and the 1900-2100 range. The description only echoes "any date (default today)" and adds no format, validation, or edge-case meaning beyond the schema, so the baseline 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?

The description uses a specific verb and resource ("Get the planetary atmosphere for any date") and enumerates the exact contents: Moon phase and illumination, Moon sign and element, retrograde planets, daily aspects, and Solfeggio frequency guidance. It also separates itself from natal-work siblings (get_birth_chart, bazi_chart, karma_chart_read) by stating it "does not require personal birth details."

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 rather than stated: "for any date (default today)" tells the agent the tool is date-scoped and needs no personal data, which is a useful selection cue against birth-detail tools. However, it never explicitly says when to prefer this over siblings like get_transits, tuvi_horoscope, or search_yinyang_guides, and gives no 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 readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds real value beyond them by disclosing that only the 'tightest' aspects are returned — a filtering behavior an agent would otherwise not expect — and by restating the input dependency on birth data. It stops short of describing the response shape or how tight the orb cutoff is.

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 sentences, zero filler. The output description comes first and the input prerequisite second, which is the right front-loading for an agent deciding whether it can call the tool.

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 an 8-parameter, 6-required tool with no output schema, the description covers the essential contract: what is computed and what data is required. Minor gaps remain — it does not mention the optional 'place' or 'dst_fold' inputs or clarify the orb threshold behind 'tightest' — but the fully documented schema absorbs most of that burden.

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 every parameter including date, dst_fold, and birth_time is already documented. The description only reinforces that birth data mirrors the natal chart and that a date is added; it adds no format or semantic detail beyond the schema, so the baseline 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 a specific verb and output ('Show where the planets are' plus 'transit-to-natal aspects') and explicitly defines the astrological concept in parentheses. It distinguishes itself from a plain natal-chart tool by referencing 'the same birth data as the natal chart', though it never names get_birth_chart or get_daily_cosmic_weather directly.

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 prerequisite ('Requires the same birth data as the natal chart plus the date to check') tells an agent what inputs are needed, which is genuine usage context. However, there is no explicit statement of when to pick this over get_birth_chart or get_daily_cosmic_weather, and no exclusions or edge-case guidance.

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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered and the description's burden is low. The description adds value by enumerating the analytical layers produced (nhân nghiệp, quả báo, thời điểm kích hoạt, remedies), which tells the agent the output is a deep multi-part reading rather than a summary. It does not say how long or structured the response is, nor that results depend on birth-time accuracy — a meaningful behavioral caveat for this kind of tool.

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 the core purpose front-loaded, and the four analytical layers are enumerated in a natural reading order from cause to timing to remedy. The parenthetical "(Remedies)" is slightly redundant, but there is no filler or repetition requiring removal.

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 read-only, idempotent tool with five fully documented parameters the input side is complete, and the description does characterize the output's conceptual content. However, with no output schema, the agent gets no sense of the response's shape, depth or size for what is clearly a long interpretive report, and there is no differentiation from the chart-building siblings that share the same inputs.

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% — every parameter including gender encoding (0/"nu", 1/"nam"), birth_time, hour_index and timeline_years is documented in the schema itself. The description mentions no parameters at all and adds no meaning beyond that, so the baseline 3 for a fully documented schema 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?

The description names a specific deliverable: a multi-layer karma reading ("Luận giải Nghiệp Lực đa tầng") that combines Tử Vi and Bát Tự and decomposes into four outputs — past-life causes, this-life retribution, activation timing via đại vận/lưu niên, and Buddhist remedies. That is much more specific than a generic chart tool. It stops short of a 5 because it never names or contrasts itself with the obvious siblings (tuvi_chart_vn, bazi_chart, karma_diagnose), so an agent must infer the split.

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: the phrase "kết hợp Tử Vi & Bát Tự" signals this is the combined-karma analysis rather than a plain chart, which hints at when to pick it over tuvi_chart_vn or bazi_chart. There is no explicit when-to-use statement, no when-not, and no mention of prerequisites such as needing an accurate birth time for the timing layer to be meaningful.

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 needs no restating. The description adds value by disclosing that input is a free-form natural-language account and that output includes a traced classical causal chain plus prescriptive remediation ('chỉ dẫn pháp hóa giải'), but says nothing about depth, length, or how the diagnosis is bounded.

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 front-loaded sentence with the diagnosing action and causal-tracing outcome stated early, followed by a compact parenthetical of use cases. The parenthetical is long but each item is informative rather than 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?

Since there is no output schema, the description carries the burden of conveying what comes back, and it does so briefly (causal tracing plus remedial guidance). Combined with complete schema coverage and rich annotations, the remaining gap is mainly sibling differentiation against karma_chart_read, which keeps it out of the top band.

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% for the single 'text' parameter, so the baseline is 3. The description does contribute example content categories (financial hardship, marriage, health, injustice, past mistakes) that hint at what to put in the free-form text, but adds no length, formatting, or language constraints beyond what the schema already states.

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 ('Chẩn đoán' — diagnose) and resource ('căn nguyên nghiệp quả' — karma root cause), and the parenthetical lists the concrete problem domains it handles (finance, marriage, health, grievance, past misdeeds). It does not distinguish itself from the sibling karma_chart_read, which sounds like an adjacent karma-reading capability, so an agent cannot fully disambiguate from the text 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?

The enumerated problem categories imply when to reach for this tool (user describes a concrete life difficulty in natural language), which is a usable but implicit signal. There is no explicit when-not guidance, no mention of prerequisites, and no routing to alternatives such as karma_chart_read or search_yinyang_guides, leaving overlap resolution 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile needs no restating. The description adds that output is derived purely from the birth date and comprises one annual number plus twelve monthly themes, which is useful. It still says nothing about determinism across years, edge cases, or result format.

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 with no filler, no repetition of the title, and the output scope stated before the input source. Every clause carries information an agent needs.

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 only two well-documented parameters and no output schema, the description does the important remaining job of stating what the result contains: an annual personal-year number plus twelve monthly themes. A note on seasonality or the meaning of the returned numbers would make it fully self-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 100%, and the schema documents both 'year' (with 1900-2100 bounds) and 'birth_date' (YYYY-MM-DD). The description only echoes that the calculation starts 'from a date of birth' and targets a 'calendar year', adding no format or range detail beyond the schema, so baseline 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?

The description uses a specific verb ('Calculate') with a precisely scoped resource ('numerology personal year' plus 'personal month theme for each of its 12 months') and names the input ('a date of birth'). It is clearly narrower than the sibling calculate_numerology, though it never explicitly names that sibling to route the agent.

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 the phrase 'to plan' a calendar year, so an agent can infer this is the year-planning variant. There is no explicit when-to-use statement, no exclusion, and no pointer to alternatives such as calculate_numerology or build_productivity_plan despite many overlapping siblings.

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 cover the safety profile (read-only, idempotent, non-destructive, closed-world), so the lower bar applies. The description still adds value beyond them by disclosing the return shape: matching guides with a short summary and a flag for whether an interactive practice tool is included, which matters since there is no output schema. It omits ranking/relevance and pagination behavior, keeping 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?

Two sentences, front-loaded with the verb and resource, then the return shape. No filler, though the long topic enumeration is somewhat list-like and only weakly tied to the pillar parameter.

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 explains what comes back, and all three parameters are at least implicitly addressed. Remaining gaps are minor: result ordering, whether query matches body text or titles only, and how strictly pillar filters.

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 67%: query has an example-bearing description and pillar is an enum with a description. The description's topic list loosely mirrors the pillar enum but never explains the limit cap of 5 or how pillar interacts with query, so it adds little beyond the 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?

States a specific verb and resource ('Search Yinyang Masters in-depth guides') and enumerates the covered topics, so the domain is unambiguous. It does not contrast itself with adjacent siblings like find_my_crystals or calculate_numerology, which cover overlapping subject matter.

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 implies usage (look up guides on a topic) but gives no explicit when-to-use versus when-to-pick-a-sibling-tool guidance, and no prerequisites or exclusions. An agent must infer that this is the generic content-search entry point while the siblings are computation-specific.

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, non-destructive and closed-world, so the safety profile is fully covered. Beyond that, the description adds the computational scope (which star systems and palace attributes are produced), which is genuinely useful, but says nothing about output format, precision limits, or how inputs like birth_time versus hour_index affect the result.

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 begins with the verb and resource before the detail list. The enumeration of 12 palaces is long but each item conveys scope, so little is wasted; splitting the domain terms from the behavioral notes would improve 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?

For a simple read-only chart generator with no output schema, the description conveys the result content but omits the response shape and any routing versus tuvi_horoscope. It is adequate but leaves the agent guessing on the most likely confusion point among siblings.

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 the precedence rule for birth_time over hour_index and the gender encoding, so the schema carries parameter meaning fully. The description adds no parameter-level detail beyond the schema, making the baseline 3 appropriate.

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 ("Lập lá số", cast a chart) and resource (Tử Vi chart) and enumerates exactly what the output contains: 12 palaces, star brightness levels, auxiliary stars, Tuần/Triệt, Thân cư and Mệnh cư. It never names a sibling, so the agent cannot tell from this text alone how it differs from tuvi_horoscope or bazi_chart, which keeps it below 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?

There is no guidance on when to use this tool versus the obvious sibling tuvi_horoscope, and no prerequisites such as whether the birth date must be solar (implied only through the schema). The agent must infer usage entirely from the name and purpose sentence.

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, non-destructive and closed-world, so the safety profile is covered. The description adds that results are anchored to a viewing date and span three nested period lengths, but says nothing about output shape or whether birth data must be complete for a valid result. Useful but thin beyond the annotations.

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 with a colon-delimited enumeration of the three period layers, zero filler. It could be marginally clearer by naming the viewing-date anchor before the period list, but 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?

Five parameters with full schema coverage and no output schema, so the description should at least sketch what comes back (period boundaries, star placements, ratings) and how it relates to tuvi_chart_vn. Neither is present, leaving the agent to guess the result shape for a non-trivial astrology computation.

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 all five parameters including target_date's default-today behavior are already documented in the schema. 'Theo mốc ngày xem' only restates target_date in prose and adds no format or constraint detail beyond the schema. Baseline 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?

States a specific verb (Tính) and resource (vận hạn Tử Vi) and enumerates the three scopes it covers: Đại vận 10 năm, Lưu niên từng năm, Nguyệt vận từng tháng. An agent can tell this is a multi-layer fortune-period calculator, but nothing distinguishes it from the sibling tuvi_chart_vn, which likely produces the underlying 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?

Usage is only implied: you call it to see fortune across decade/year/month periods, anchored on 'mốc ngày xem'. There is no explicit statement of when to prefer this over tuvi_chart_vn, no prerequisite such as needing a birth chart first, and no 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 establish this as a read-only, idempotent, closed-world, non-destructive operation, so the safety profile is covered. The description adds meaningful context beyond that: the concrete output contents (structured ritual phases, 5 present-tense affirmations, Day 1 kickoff exercise, 7-day milestone cadence) and an explicit framing constraint ('promotes grounded psychological alignment without unrealistic promises') that tells the agent what tone and caveats to expect.

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 the verb and resource, then the deliverables, then the framing caveat. Each sentence carries information; the only mildly redundant piece is that the deliverable list slightly restates what the title implies, but it is concrete rather than 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?

There is no output schema, so the description properly takes on the burden of describing the return content — phases, affirmations, kickoff exercise, and cadence — which it does. The main gap is that the optional 'method' parameter and how it changes the generated script are unaddressed; otherwise an agent has enough to call this 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 coverage is 100%, so both parameters are documented in the schema itself, and the description's list of life focuses only loosely mirrors the 'desire' examples. The 'method' parameter (369_method, 55x5_method, scripting, visualization, box_breathing_manifestation) is never mentioned in the description, so it adds no meaning beyond the schema. Baseline 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?

The description opens with a specific verb-plus-resource ('Create an intentional manifestation ritual script') and scopes it to a named set of life focuses, which is far more concrete than the title alone. It does not name or contrast any sibling tool, but the deliverable (a ritual script with phases, affirmations, Day 1 exercise, 7-day cadence) is distinctive enough that an agent can separate it from build_habit_stack or build_productivity_plan.

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: the enumerated life focuses (wealth, career breakthrough, romantic love, inner peace, creative flow) hint at when the tool applies, but there is no explicit when-to-use or when-not-to-use statement and no alternatives are named. An agent must infer from domain overlap that this is the ritual-script generator rather than a planning or chart tool.

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