LsTuvi - Tử Vi & Lịch âm

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral context: the output is a score out of 100 with each contributing factor explained, which tells the agent what to expect back despite the absence of an 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?

One well-formed sentence that front-loads the operation and ends with the return contract; no filler or repetition of the title.

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 two-object tool with no output schema, the description covers the computation basis and return shape adequately. Minor gaps remain around the optional name field and input bounds, but an agent can call this correctly from what is given plus the 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 description coverage is effectively 0% beyond the gender enum note, so the description must compensate. It does convey that birth_year and gender are the inputs that drive the calculation, but it never mentions the optional 'name' field, the 1920–2100 year bounds, or how gender affects the Bát Trạch cung phi computation.

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 resource ('Compares two people by birth year and gender') and enumerates the exact frameworks used (nạp âm, heavenly stem, earthly branch, Bát Trạch cung phi, zodiac animal). It implicitly separates itself from the sibling find_compatible_birth_years by comparing two concrete people rather than returning year lists, though it never names that sibling to make the distinction explicit.

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?

Nothing states when to pick this over find_compatible_birth_years or create_tuvi_chart; the two-person comparison framing implies match-making/pairing use cases but the agent must infer it. There are no exclusions or prerequisites called out.

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 description's job is to add context — and it does, disclosing the 1900–2100 domain limit and leap-month support, which annotations cannot express. Since there is no output schema, the note that results include can chi for day/month/year plus the solar term is genuinely useful behavioral disclosure.

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: verb, resource, domain limit, and outputs in that order. No filler or repetition of the title.

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 three-parameter, annotation-covered conversion tool with no output schema, the definition supplies the range limit, leap-month caveat, and a sketch of the returned fields. Only the exact shape/format of the returned can chi and solar term data is left unstated, which is a minor 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 67%, with date and leap_month documented inline; the description's phrase 'with leap months, 1900–2100' adds a valid-range constraint on the date parameter that the schema lacks. It does not explain the direction enum values beyond their self-explanatory names, so it stays at baseline-plus rather than adding rich 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: converts a date between the Gregorian and Vietnamese lunar calendars, with the supported range (1900–2100) and leap-month handling. It is clearly distinct from siblings like get_lunar_day or find_good_days, though it never names an alternative to sharpen the 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?

Usage is only implied by the stated purpose and the 1900–2100 range constraint. There is no explicit guidance on when to pick this over get_lunar_day or other date-related siblings, and no mention of prerequisites.

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 and determinism are covered. The description adds genuinely new context: the chart is derived from Gregorian input and the palace interpretations are 'rule-based', which sets expectations that the reading is deterministic rather than free-form analysis.

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: the first front-loads what is built and what comes back, the second gives the trigger. The component enumeration is long but earns its place because there is no output schema, so the agent needs to know what the payload contains.

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 5 parameters, no output schema, and a fairly complex domain (astrological computation), the description covers the essentials: inputs, computation basis, and returned structure. The only residual gap is the undocumented optional 'name' field, which affects nothing about invocation correctness.

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 80%, so the schema already documents gender, view_year, birth_date and birth_time, and the description mainly restates them as the inputs. It adds no format or edge-case meaning, and the lone undocumented parameter (name) is left unexplained in both places. Baseline 3 applies when 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?

The description opens with a specific verb and resource — 'Builds a Vietnamese Tử Vi Đẩu Số (Purple Star) birth chart' — and then enumerates the computed components (lunar date, can chi, nạp âm, cục, 12 palaces with stars, per-palace reading). That output list makes it unambiguously distinct from siblings like convert_lunar_solar, which only converts dates.

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 explicit trigger: 'Use when the user wants their Tử Vi chart or asks what their chart says.' That is clear context for selection, but it names no exclusion or alternative (e.g., when to use convert_lunar_solar instead), so it falls short of the 5-level routing clarity.

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 readOnly, idempotent, non-destructive and closed-world behavior, so the description only needs to add operational context. It does usefully disclose the output shape (best and worst matching years) despite there being no output schema, but it leaves open whether all intermediate scores are returned or only the extremes, and it never explains the "Vietnamese age-matching rules" it relies on.

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 tightly packed sentence with the core action and return value front-loaded and no filler. It could be split slightly to separate input contract from return contract, but nothing here is wasted.

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 scoring tool with no output schema, the definition covers inputs and outputs at a workable level and annotations carry the safety profile. It falls short on explaining the scoring rules and the best/worst result semantics, which is the main thing an agent would want to know before invoking it.

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 75%, so most parameters are already documented, including the range default of 10 and the partner_gender default. The description only adds a marginal gloss by tying birth_year and gender to "one person" and confirming that a range is scanned; it does not clarify how range bounds are applied.

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 ("scores"), a specific resource ("every partner birth year within a range") and states the return ("best and worst matching years"). It implicitly distinguishes itself from check_age_compatibility by scanning a range rather than one pair, but it never names that sibling, 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?

Usage is implied: supply one person's birth year and gender when you want to explore a span of candidate partner years rather than test a single match. There is no explicit when-not guidance and no alternative tool named, so the agent must infer that check_age_compatibility is the right choice for a single pair.

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 the safety profile is covered. The description adds genuinely useful behavior beyond that: the ranking is rule-based (Vietnamese day-selection), personalization is optional, and the response mixes recommended days with reasons, auspicious hours, and days to avoid.

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 verb and scope and ends with the return shape. The parenthetical activity list (wedding, opening a shop, moving house…) duplicates the enum values already documented in the schema and could be trimmed.

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 carries the burden of describing the return value (best days, reasons, good hours, days to avoid) and covers both required and optional inputs. It is only slightly thin on ordering/ranking format details, but nothing critical for a correct call 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%, including enum labels for all ten activities and the bride/groom roles for the birth-year fields, so the schema does most of the work. The description only adds the high-level notion that birth years are optional and apply to the people involved, which is largely already conveyed 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 ("Ranks the days of one Gregorian month") plus the rule system used (Vietnamese day-selection rules) and what the output contains (best days with reasons and good hours, days to avoid). That is clearly distinct from siblings like convert_lunar_solar or create_tuvi_chart, which do conversion and charting rather than day ranking.

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?

Gives clear context for when the optional personalization applies (birth years of the people involved, with the schema noting the bride/groom case for weddings). It does not name an alternative tool or state exclusions, but the sibling set contains no direct competitor for day selection, so the omission is minor.

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 covered. The description adds genuine value beyond that by specifying which derived facts come back (Tam Tai, Kim Lâu, palace for men and women) and by fixing the target year as 2027, which is not encoded 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?

A single dense sentence, front-loaded with the verb and target year, with no filler. The enumeration is long but each item is load-bearing given there is no 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?

With no output schema, the description responsibly lists the returned facts, and the annotations cover safety and determinism. What remains unstated is minor: whether results are fixed for 2027 only and whether any input validation beyond the schema range is enforced.

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?

Only one parameter exists and schema coverage is 100%, with the schema already stating the Gregorian birth year and the 1920–2100 bounds. The description's phrase 'for a birth year in the lunar year 2027' confirms the interpretation but adds no format or edge-case 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?

The description gives a specific verb ('Returns') and a precise resource: the traditional facts for a birth year in lunar year 2027 (Đinh Mùi). Enumerating the returned fields (age, branch/stem relation, element relation, Tam Tai, Kim Lâu, yearly palace) makes it easy to distinguish from siblings like create_tuvi_chart or find_compatible_birth_years, though it never names those alternatives 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?

Usage is only implied: an agent can infer you call this when a user asks about a birth year's 2027 outlook. There is no explicit when-to-use, when-not-to-use, or pointer to a sibling for related questions such as compatibility or chart creation.

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 the safety profile is covered. The description adds genuinely new behavioral context by disclosing what is actually returned — a summary (short answer, key points, FAQ, or article opening) rather than the full article, which sets agent expectations about content depth.

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 zero waste, front-loading the return type and resource before the parenthetical routing hint. Nothing is redundant with the title or annotations.

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 the possible return shapes, which is the key missing piece for a one-parameter read tool. It omits error behavior for an invalid or unknown slug, a minor gap given the tool's simplicity.

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%, so the description must carry the load, and it does the most important thing: it tells the agent where the slug comes from (search_articles). The schema's pattern constraint covers format, but the description does not restate it, leaving a small gap.

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 ('Returns the summary of one lstuvi.com article by slug') and immediately distinguishes itself from the sibling search_articles by naming it as the slug source. An agent can tell this is a single-item fetch, not a search.

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 parenthetical '(from search_articles)' gives a clear routing rule: obtain the slug via search_articles, then call this. It stops short of stating when not to use it or what happens on a missing slug, so it is clear context rather than 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.

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

The annotations already establish that the operation is read-only, idempotent, non-destructive, and closed-world. The description adds useful behavioral detail by listing the returned content: lunar date, can chi, hoàng đạo/hắc đạo classification, trực, lunar mansion, clashing ages, taboo days, and auspicious hours.

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 that states the action, scope, default, and result contents without unnecessary wording. Every listed result type is relevant to what the tool returns.

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 lookup with one fully documented optional parameter and no output schema, the description is complete enough. It explains the input scope, default behavior, and enumerates the returned calendar fields an agent would need to understand the result.

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 already explains that the date parameter is a Gregorian date in YYYY-MM-DD format and defaults to today in Vietnam. The description echoes the default behavior but adds no further parameter semantics 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?

The description gives a specific verb and resource: it returns the Vietnamese lunar calendar entry for one Gregorian date. It clearly scopes the tool to a single date and enumerates the core result fields, though it does not explicitly distinguish itself from the close sibling convert_lunar_solar.

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 one Gregorian date (default today),' which tells the agent this is a single-date lunar lookup. However, there is no explicit when-to-use or when-not-to-use guidance relative to convert_lunar_solar or find_good_days.

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 a closed-world scope, so the safety profile is fully covered. The description adds that the payload includes both free-feature flags and paid prices, which is useful, but says nothing about currency, staleness, or whether prices are region-specific.

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 states the return content before enumerating categories. Every clause carries information; nothing is padded or repeated from the title.

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 zero-parameter, read-only lookup with no output schema and full annotation coverage, the description is nearly complete: it tells the agent what data comes back and which package categories exist. Minor gap is the absence of currency or freshness details an agent might need to present prices accurately.

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?

The tool takes zero parameters, so the baseline is 4 and there is no per-parameter semantics to compensate for. The description correctly implies no input is required to get the full price list.

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 ("Returns") and resource (free features plus current prices) and even enumerates the paid categories covered: chart reading, couple reading, Tử Vi chat packages, coin top-ups. None of the sibling tools deal with pricing, so an agent can route to this unambiguously.

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 purpose makes the usage context fairly self-evident (answer cost/pricing questions), but the description never says when to call it, when not to, or what to do instead. No alternative or prerequisite is named, so the guidance is only implied.

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's useful addition is the return shape (titles, slugs, short descriptions), which matters since there is no output schema. It says nothing about matching behavior (accent-insensitive substring? ranking?), so it stays at adequate.

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 action and scope, with no filler. The domain enumeration is slightly long but genuinely narrows the corpus, so it earns its place.

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 tool with no output schema, the description covers purpose and return fields, which is most of what is needed. It leaves the undocumented limit parameter and the exact matching/ranking semantics unexplained, and gives no pointer to get_article for retrieving a full result.

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%: query is documented in the schema, but limit has no description beyond min/max 1-20. The description adds no meaning for either parameter, so with a mid-level coverage gap the description should have compensated and 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 verb and resource ('Searches the Vietnamese articles published on lstuvi.com') and names the subject domain (Tử Vi, palaces, stars, lunar calendar, yearly outlooks), so an agent knows exactly what corpus is searched. It does not differentiate itself from the sibling get_article, which is the obvious complement, so it falls 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?

The word 'Searches' implies discovery use, and the schema note that an empty query lists newest articles hints at browsing, but the description never says when to use this versus get_article or the forecast tools. No exclusions or prerequisites are offered.

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