Saju from Seoul | Korean Astrology

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

Annotations already declare readOnly/destructive status. Description adds valuable behavioral context: what specific data is returned (stems, branches, Day Master, Five Elements) and how the hour parameter affects calculation ('refines the hour pillar').

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 sentence structure with zero waste. First sentence establishes purpose, inputs, and outputs. Second sentence addresses optional parameter behavior. Every clause 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?

Given 100% schema coverage and existence of output schema, the description appropriately focuses on high-level purpose and specific cultural context (Korean Four Pillars) without redundantly documenting return values that the output schema covers.

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?

With 100% schema coverage, baseline is 3. Description adds critical context beyond schema: specifies 'Gregorian' calendar system (crucial for date conversion tools) and explains the functional relationship of the optional hour parameter to the output.

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 'Compute' with explicit resource 'Korean Four Pillars (년월일시)' and detailed outputs (stems, branches, Day Master, Five Element counts). Distinguishes from siblings like get_day_master (single pillar) by specifying full chart computation.

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?

Provides implied usage by describing the full chart computation vs component-level siblings, and explains when to use the optional hour parameter ('refines the hour pillar'). However, lacks explicit comparison naming sibling alternatives like check_compatibility.

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?

Adds critical context beyond annotations: discloses 'entertainment-level signal only—not deterministic fate,' which is essential liability/scope disclosure for astrology tools. Annotations confirm readOnly/destructive status, but description adds practical limitation disclaimer. Lacks mention of data retention or privacy.

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?

Every sentence serves distinct purpose: (1) what the tool does/returns, (2) invocation triggers, (3) limitation + external reference. No redundancy. Well front-loaded with core function first.

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?

Complete given rich schema and presence of output schema (per context signals). Covers domain-specific context (Korean terms, entertainment disclaimer). Could benefit from explicit note that it requires exactly two people (not more), but this is implied.

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 baseline is 3. Description notes 'times optional' which reinforces the schema's optional status for hour parameters, but does not add semantic detail about date formats or valid ranges beyond schema constraints.

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?

Description opens with specific verb+resource (compare two birth charts) and clearly states return value (Day Master Five Element harmony). It explicitly targets relationship compatibility, distinguishing it from general Saju calculation siblings like calculate_saju or get_day_master.

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?

Provides explicit trigger keywords (soulmate, twin flame, 궁합, etc.) and prerequisites (two birth dates). Mentions external alternative (sajufromseoul.com) for full readings, but does not explicitly differentiate from sibling tools calculate_saju/get_day_master when user only has one birth date.

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?

Adds valuable behavioral context beyond annotations: specifies output is a 'short personality sketch' (content type) and clarifies this targets the specific 'day stem' rather than any stem. With readOnly/destructive hints already covering safety, this adds content semantics effectively.

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?

Single, well-structured sentence using an em-dash for parenthetical elaboration. No waste: 'short' sets output length expectation, parenthetical provides cultural context (天干/일간), and 'Saju chart' establishes domain. Front-loaded with action and object.

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?

Appropriately complete for the domain complexity. Cultural terms (Hanja, Heavenly Stem, Saju) provide necessary context for users familiar with East Asian astrology. Output schema exists, so omitting return value details is acceptable. Could benefit from mentioning that this is typically used in conjunction with calculate_saju.

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 detailed parameter description including Hanja examples. The main description does not add parameter syntax or validation details beyond the schema, which is appropriate given the high schema coverage (baseline 3).

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?

Clear verb ('Return') and resource ('personality sketch'), with specific domain context ('Heavenly Stem', 'day stem', 'Saju chart'). References the specific 'day stem' (일간) which implicitly distinguishes this from generic stem listing (list_stems_and_branches) and compatibility checking (check_compatibility), though explicit sibling differentiation is minimal.

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 through references to 'calculate_saju' in the parameter schema description and 'Saju chart' in the description, suggesting this follows a chart calculation. However, lacks explicit 'when to use' guidance (e.g., 'call this after calculate_saju to get personality details') or when-not-to-use distinctions.

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?

Beyond annotations declaring readOnlyHint=true, the description adds valuable domain context by specifying exactly what attributes are returned (Hanja, romanization, element, animal), giving the agent clear expectations about the dataset structure and cultural content without contradicting safety 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?

Single sentence packing exact counts, Korean terms, and specific data attributes. Every element earns its place with no redundancy. Front-loaded with the action and scope (Return all...).

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?

Given the output schema exists and parameters are fully documented in schema, the description provides adequate domain context by enumerating the specific fields (Hanja, romanization, element, animal) that distinguish this cultural dataset. Sufficient for a reference lookup 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?

With 100% schema coverage, the parameter descriptions in the schema already fully document the boolean flags (include_animals, include_hour_ranges). The description mentions 'animal' which loosely connects to include_animals, but adds no additional parameter guidance beyond the schema baseline.

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 specific verb 'Return' with exact quantities (10 Heavenly Stems, 12 Earthly Branches) and identifies the specific resource type (천간/지지). It clearly distinguishes from calculation-focused siblings (calculate_saju, get_day_master) by framing this as a comprehensive reference retrieval rather than a computation.

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 this is for retrieving complete reference data versus single calculations, but provides no explicit 'when to use' guidance or mention of alternatives (e.g., use get_day_master for single stem lookup, use this for full reference).

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