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

Annotations already declare readOnlyHint=true and destructiveHint=false, so this is clearly a safe, non-mutating analysis. The description adds a minor behavioral constraint ('Requires both people's birth data') but no additional side-effect or runtime behavior disclosure is necessary.

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 one tightly scoped sentence that front-loads the trigger phrases, with no filler or repeated schema information. Every word contributes to routing the agent correctly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has a complex nested schema with 8 parameters, and the description only covers identification and a high-level data requirement. It does not clarify how the agent should phrase or compose the question, whether missing birth info should trigger follow-up questions, or why some optional parameters matter. The output schema helps fill the return-value gap, but the overall guidance remains thin for a tool of 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 only 50%, and the description does little to compensate. It names the requirement for both birth datasets but adds no explanation of the question, lifeEvents, targetDate, detailLevel, or outputMode parameters. The schema does some of the work, but the description should surface more about the two required nested birth objects.

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 precise trigger scenarios (궁합, 결혼 가능성, relationship compatibility) and the comparison of two birth charts, which clearly distinguishes this from single-person tools like legend_saju_read_fortune or legend_saju_analyze_name. The verb and resource are specific and recoverable from context.

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 explicitly says when to use the tool and even provides example Korean intent. The requirement that both birth datasets are needed is a useful precondition. However, it does not mention when not to use it or explicitly name alternative tools for relationship-related queries.

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 and destructiveHint=false, so the description adds value by stating a concrete behavioral contract: it keeps legal Hanja observations, declared stroke standards, and birth-name guidance separate. This is beyond the annotations and is useful for setting agent expectations about how the tool organizes its output.

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 core usage instruction and then a precise behavioral note. Every sentence contributes meaning and there is no redundancy.

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 tool's complexity (nested name/birth objects and many optional parameters), the description provides the right high-level guidance without duplicating the schema. The output schema and numerous parameter descriptions cover invocation details, although the sparse coverage of some stroke parameters keeps this from a 5.

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 50%, so the description must compensate for undocumented parameters like givenStrokes and surnameStrokes. It does not mention any parameter names, types, or composition rules beyond general domain keywords. The schema itself carries most of the parameter burden, but half of the parameters remain not described.

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 ('Use this for') and lists concrete question types: 작명, 성명학, 81순, 이름 한자, 인명용 한자, 획수, and 파자. It also explains what the tool separates (legal Hanja observations, declared stroke standards, and birth-based naming guidance), making it clearly distinct from sibling tools like compatibility or fortune reading.

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 opening phrase 'Use this for' gives an explicit when-to-use instruction, and the listed Korean keywords define the exact domain. However, it does not explicitly say when not to use it or point to an alternative sibling, so it stops short of a full when-not/alternative guide.

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 signal a safe, read-only, non-destructive operation. The description adds scope context by separating specialized method selection from ordinary fortune reading, but it does not describe the actual operation, outputs, or any edge behavior beyond that.

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 sentences, each purposeful and immediately front-loaded with the trigger condition and a clear exclusion. The long list of domains is efficient because it defines the tool's full intended scope.

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 that the schema is simple, annotations cover safety, and an output schema exists, the description is mostly complete for an agent. The only real gap is the lack of direct parameter guidance, but the domain list and exclusion statement make the intended use sufficiently clear.

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 0% schema description coverage, the description needed to explain the parameters, and it partially does: the long list of system types hints at what the 'systems' parameter can contain and 'specialized question' hints at the query. However, it never mentions 'limit' nor explicitly maps the systems list to the schema property, so the compensation is incomplete.

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 clear action: find a calculation method that fits a specialized question, while enumerating the covered systems. It differentiates itself from ordinary fortune reading, which is enough to distinguish it from sibling tools like legend_saju_read_fortune.

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?

Explicitly says 'Use this when a user asks which ... calculation method fits' and gives a when-not: 'Do not use it for an ordinary fortune reading.' This gives clear positive and negative selection criteria, even though it does not name the exact alternative tool.

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 mark this as read-only and non-destructive, so the description only needs to add behavioral context. It does that by specifying that the chart is cast from a question time or six line values and that it targets specific divination methods rather than general natal interpretation. This adds meaningful operational clarity 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?

The description is two sentences with no filler, placed at the start and front-loaded with the intended use case. The exclusion is stated directly and economically.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description, schema, and annotations together provide enough information for correct invocation. The main missing element is that for someone seeking a general natal reading, there is no explicit pointer to the appropriate 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%, with rich per-property descriptions for questionDateTime, lineValues, birthTimeAccuracy, and others. The description reinforces the relevant inputs, such as 'a question time or six line values', but does not meaningfully add to what the schema already documents.

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 action ('Cast') with a clear resource ('a traditional divination chart') and scope: 기문둔갑, 대육임, 주역, 점괘, or a concrete decision from a question time or six line values. It also directly distinguishes itself from general natal fortune reading.

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 explicitly says when to use the tool and gives a clear exclusion: 'Do not use it for a general natal fortune reading.' However, it does not name the alternative sibling tool that should be used instead for natal readings, so the routing is slightly incomplete.

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 the readOnlyHint annotation, the description explains the scope: it handles five cross-culturally audited concepts and returns shared motifs plus conflicting conditions with primary-source excerpts. It also explicitly discloses a serious limitation—it does not turn the remaining raw corpus into invented meanings—which is valuable behavioral context for an agent.

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 sentences, front-loads the primary use case, and includes only high-signal constraints about scope and hallucination avoidance. Every sentence provides useful guidance, with no filler or redundancy.

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 rich input schema, annotations, and output schema, the description is sufficiently complete. It tells the agent what the tool does, what it returns, and how far its coverage extends, and the parameter and output details are already handled by the structured 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 high at 86%, and the schema already explains most parameters including dream, question, outputMode, detailLevel, and dreamContext. The description itself does not add parameter-level semantics, but it does not need to because the schema carries the load; only maxDreamMatches remains undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool's purpose: interpreting dreams via Korean-specific terms (해몽, 꿈풀이) and English, and specifies the output type: shared motifs and conflicting conditions with primary-source excerpts. This distinguishes it from the sibling fortune, name analysis, and date-selection tools without ambiguity.

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 opens with 'Use this for 해몽, 꿈풀이, or dream interpretation,' giving explicit when-to-use guidance for the target scenario. It does not explicitly name alternative sibling tools or exclusion conditions, but the intended use case is clear enough for an agent to route dream-interpretation requests correctly.

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 the readOnlyHint annotation, the description discloses meaningful behavioral details: it returns live state, is deterministic, source-traceable, and makes no model or network call. This gives an agent confidence that the operation is safe and side-effect-free without requiring structure inspection.

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 short sentences, each earning its place. The first fronts the primary function, and the second removes any concern about network or model latency, making the text both efficient and immediately useful.

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 a zero-parameter schema and an output schema present, very little needs to be stated. The description covers what the tool returns, the core property 'deterministic', and the safety guarantee 'no model or network call', which is sufficient for an agent to correctly select and invoke 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?

The tool has zero parameters and the schema coverage is 100%, so there is no parameter meaning for the description to add. The absence of parameters is already fully represented by the empty schema, and the description appropriately focuses on behavior instead.

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 ('Return') and a specific resource ('deterministic engine manifest'), and adds clarity with 'live' and 'source-traceable'. This distinguishes it from the predictive/estimation flavors implied by sibling tools like legend_saju_read_fortune and legend_saju_analyze_compatibility.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'No model or network call' gives clear context that this is an inspection tool, not a generation or prediction tool. It implies when an agent should select it — to view the engine manifest rather than obtain a reading — but it does not explicitly name alternative tools or exclusion conditions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds useful behavioral context by telling the agent to read structuredContent, look for recommendations, use a deep one-call expert mode, and not search capability IDs first. This goes beyond what annotations alone provide.

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 compact and front-loaded with trigger phrases, then moves directly into the most important behavioral guidance. Every sentence earns its place; there is no filler or repetitive schema restating.

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 nested schema, output schema, and annotations, the description covers the key call-shaping details: when to invoke, what to read from the result, which detailLevel to use, and the no-capability-search workflow. The remaining gap is that with eight sibling tools, an explicit line about which sibling is NOT appropriate would make the choice fully unambiguous.

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 56%, so a meaningful share of parameter behavior is already documented in the schema, e.g., hour ambiguity, calendar defaults, and birthTimeAccuracy. The description adds a useful directive for detailLevel=expert, but it does not meaningfully enrich other parameters like asOfYear, timelineRange, or lifeEvents.

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?

Title and trigger list make clear this reads a Saju/운세 fortune: it covers 사주 봐줘, 운세 봐줘, 재물운, 사업운, 연애운, etc. The description is specific about the resource and intent, but it never contrasts itself with the sibling tools, so the differentiation is implicit rather than 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?

The description gives explicit triggering conditions with concrete Korean examples and adds workflow guidance like using detailLevel=expert for a deep one-call analysis. It does not give when-not-to-use guidance or name which sibling tool to choose instead, so it stops short of a full routing contract.

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 readOnlyHint=true and destructiveHint=false, so safety is well covered outside the description. The description adds the useful behavioral note that the server can plan from the question when requestedCapabilities is empty, but it does not disclose other non-obvious behavior such as return shape or expert-mode composition, which are left to the 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?

The opening sentence is action-oriented and the long list of named traditions genuinely supports the tool's purpose. The description is dense and would be clearer with short groupings or bullets, but every sentence earns its place and the critical usage conditions are 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 complex 22-parameter tool, the description is unusually complete: it gives the capability scope, the trigger conditions, the difference from focused tools, and the two valid invocation styles. The output schema fills most remaining return-semantics gaps, and the required question parameter is minimal enough to call the tool safely.

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 45%, so the description must compensate for parameter meaning, but it fully explains only requestedCapabilities and vaguely references the question. It clarifies that capability IDs are optional and the server can infer from the question, which is useful given the 22 optional parameters, but most parameters still rely on their own schema descriptions.

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 explicitly states 'Use this for expert, mixed-system, or named-method requests' and then enumerates the exact traditions covered, from Myeongri and Zi Wei to Qimen and dream traditions. It clearly identifies a concrete scope and distinguishes this broad tool from the focused sibling tools.

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 explicit trigger conditions ('expert, mixed-system, or named-method requests'), explains the capability-ID path versus letting the server plan from the question, and says to use focused tools for ordinary single-goal requests. It does not name the focused sibling tools explicitly, which would make the routing guidance fully explicit.

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 and destructiveHint=false, covering the safety profile. The description adds context about the intended invocation trigger and avoids misapplication, but it does not disclose further behavioral details such as how candidate dates are returned or constrained beyond schema and 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?

Two sentences with no wasted filler, and the most decisive usage rule is stated up front. The Korean examples add practical precision without padding.

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 rich input schema, output schema, and safety annotations, the description provides the essential missing piece: when the tool should be selected and when it must not be. It is slightly thin on what the returned results represent, but the output schema mitigates that 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?

The description adds no parameter-level meaning; all parameter knowledge is carried by the schema, which covers 63% of parameters. Since the schema already documents some fields like calendar defaults, timezone handling, and hour ambiguity, a baseline 3 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 clearly defines the tool's scope: it is for date-selection tasks (택일, 좋은 날, 계약일, 이사일, 개업일, 수술일), not for ordinary fortune readings. This specificity distinguishes it from read_fortune and other fortune-related siblings.

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 explicit when-to-use criteria with concrete examples and a clear exclusion ('Do not use it merely because a fortune request mentions this year'). It does not name the alternative sibling tool to use instead, so it is slightly less helpful than it could be.

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