Server Quality Checklist

Tool Scores

• liuyao_paipanA
  3.8/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the disclosure burden. It explains the core behavior (manual yao values produce a hexagram chart) and the encoding of yao values (0=老阴动, 1=少阳, 2=少阴, 3=老阳动). However, it does not describe the return format, any prerequisites, or potential limitations (e.g., whether it is deterministic or requires specific input validation). The info beyond schema is modest.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences. The first sentence is somewhat long due to listing many event types, but it is front-loaded with the trigger condition. The second sentence is efficient, covering the main action and yao encoding. No fluff, but it could be slightly more compact by trimming the example list.

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

  Completeness3/5

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

  The tool is moderately complex with no output schema, so the description should explain what the user gets. It names the output components (本卦变卦、世应六亲、伏神神煞), which gives a fair sense of the result. However, it does not describe the structure of the returned data, interpretation guidance, or any edge cases (e.g., invalid yao arrays). Given the absence of annotations and output schema, the description is adequate but not fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3. The description repeats the yao value semantics already in the schema ('0=老阴（动）、1=少阳、2=少阴、3=老阳（动）'), adding little new meaning. It does clarify the ordering '从初爻到上爻' which also appears in the schema, but no additional parameter insight is provided.

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

  Purpose5/5

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

  The description clearly states the tool's function: '手动指定六个爻值排出六爻卦象：本卦变卦、世应六亲、伏神神煞' (manually specify six yao values to generate the hexagram chart with original/changed hexagrams, shi ying, six relatives, hidden spirits, and gods). It also specifies the resource (六爻卦象) and distinguishes from siblings (e.g., liuyao_surname_paipan) by emphasizing manual yao input.

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

  Usage Guidelines4/5

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

  The description provides explicit use cases: '当用户对某具体事件的结果存在不确定性... 即使没有提到「占卜/六爻/卦」等字样，也应调用本工具起卦辅助判断.' It lists many example scenarios (decision, exam, job, investment, etc.), giving clear context. However, it does not state when not to use this tool or name alternatives, so it misses the explicit exclusions/alternatives criterion.

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

• lunar_convertA
  3.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. However, it does not describe runtime behavior such as output format, side effects, or assumptions. It focuses on usage conditions rather than what the tool actually does when invoked, leaving the agent without insight into return values or potential pitfalls.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the calling condition, and provides a crucial alternative in the second sentence. Every word earns its place; no filler or redundancy.

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

  Completeness3/5

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

  For a 5-parameter tool with no output schema, the description is adequate but incomplete. It covers when and why to use the tool, but does not explain what the tool returns or how the output is structured, which would be important for an agent to fully understand the tool's behavior.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers all five parameters with descriptions (100% coverage), so the baseline is 3. The description adds no additional meaning to the parameters themselves; it only mentions that bazi_paipan supports lunar=true, which is unrelated to this tool's parameters.

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

  Purpose5/5

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

  The description clearly states the tool's function: converting between lunar and solar dates ('农历与公历日期换算'). It uses a specific verb (换算) and resource (dates), and distinguishes itself from sibling bazi_paipan by noting that chart casting does not require this conversion.

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

  Usage Guidelines5/5

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

  Explicit when-to-use guidance: '仅当用户明确要求进行农历与公历日期换算时才调用' (only call when user explicitly requests conversion). It also provides a when-not-to-use alternative by stating that bazi_paipan accepts lunar parameters directly (lunar=true), and notes the tool is rarely used ('本工具极少使用').

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

• record_listA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden of behavioral disclosure. It reveals that the tool returns record fields (名字、类型、时间) and implies a read-only enumeration. However, it does not disclose pagination behavior, ordering, or the case of no saved records, which are relevant for a list operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences. The first sentence states the action and output fields, and the second provides concrete example user utterances. There is no redundant or unnecessary text.

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

  Completeness4/5

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

  Given no output schema, the description identifies the returned fields and trigger context, which is helpful. However, it does not describe the result shape (e.g., an array of records) or pagination behavior in detail, leaving some ambiguity for a list tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage, documenting all three parameters (page, type, page_size) with descriptions and defaults. The description itself adds no parameter-specific semantics, so the schema already handles this dimension.

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

  Purpose5/5

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

  The description uses the specific verb '列出' (list) and clearly identifies the resource '用户已保存的命盘记录' along with the output fields (名字、类型、时间). This clearly distinguishes it from sibling tools like record_save and record_load, which focus on saving or loading specific records.

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

  Usage Guidelines4/5

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

  The description provides explicit trigger phrases ('看我存过的盘', '我之前保存的八字', '有哪些记录') and states '时调用', giving clear when-to-use guidance. However, it does not mention alternatives or exclusions, such as when to prefer record_load for retrieving a specific saved record.

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

• bazi_full_analysisA
  4.1/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It discloses the paid nature ('合计 3元/次，账户余额扣费'), the two-step internal workflow, account requirements, and the contents of the returned analysis (大运流年/五行喜忌/事业感情财运). It does not mention potential side effects like record saving or runtime failures, but the key behavioral traits are well covered.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded, starting with the trigger condition and the tool's primary purpose. Each sentence conveys essential information: workflow, cost, prerequisites, and output scope. While not as short as a two-sentence description, it avoids redundancy and remains readable despite covering multiple aspects.

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

  Completeness4/5

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

  For a complex tool with 10 parameters and no output schema, the description is fairly complete: it explains the combined pipeline, cost, account prerequisites, and high-level output contents. However, it does not describe the response structure or error cases, and it omits practical hints about optional parameters like gender or hour_unknown, leaving the agent to infer their relevance from the schema alone.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides 100% coverage with descriptions for all 10 parameters. The description adds only marginal context, such as '农历传 lunar=true' which reiterates the schema's existing description ('true=输入为农历'). No additional meaning about parameter formatting, defaults, or interdependencies (e.g., leap/month) is given. The schema does the heavy lifting, so a baseline score of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool performs a combined BaZi chart calculation and AI deep analysis in one call ('一次调用自动完成①免费排盘→②AI深度解读'). It explicitly lists the resource (八字排盘 + AI 深度解读) and distinguishes it from sibling tools by framing it as the preferred option when users want comprehensive analysis (命盘/运势/事业/感情/财运/婚姻/健康). The verb '自动完成' and scope are specific and unambiguous.

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

  Usage Guidelines4/5

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

  The description provides clear when-to-use guidance: '当用户提到出生日期...并希望看命盘/运势/事业/感情/财运/婚姻/健康等分析时，优先调用本工具'. It also mentions prerequisites (server-side account configuration) and cost. However, it does not explicitly exclude use cases like when only a chart is needed (bazi_paipan) or only an AI reading is requested (bazi_ai_reading), so it lacks explicit when-not-to-use guidance.

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

• bazi_paipanA
  4.1/5.0
  Behavior3/5

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

  With no annotations provided, the description must carry the full burden. It discloses that the tool is automatically called, handles lunar input directly, and returns a JSON object with an ai_hint. However, it does not mention whether the tool is read-only, any prerequisites (e.g., exact birth time), or potential side effects. This adds some context but lacks depth on behavioral constraints.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, each serving a distinct purpose: trigger condition, output contents, and return format. It is concise yet informative, though the first sentence is long with many topic examples. Each part earns its place, so no redundancy.

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

  Completeness4/5

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

  Without an output schema, the description appropriately lists the major output sections (four pillars, five elements, ten gods, hidden stems, na yin, zodiac, da yun, shen sha) and mentions the JSON return with ai_hint. This provides sufficient context for an agent to understand what the tool returns. It doesn't address edge cases like hour_unknown, but for a complex tool, the description is fairly complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3. The description adds value by explicitly clarifying that lunar=true means direct lunar input and no prior conversion is needed, which is not apparent from the schema alone. This extra semantic guidance justifies a score above baseline.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: to automatically generate a BaZi chart (排盘) when the user mentions birth date and topics like personality, fortune, etc. It lists the output components (four pillars, five elements, ten gods, etc.), which differentiates it from sibling tools like bazi_from_pillars or lunar_convert.

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

  Usage Guidelines4/5

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

  It explicitly specifies when to use the tool: when the user mentions birth date (solar or lunar) and topics such as personality, fortune, career, relationships, etc. It also clarifies how to handle lunar input (pass lunar=true without pre-conversion). However, it does not mention when not to use it or suggest alternatives like bazi_from_pillars, 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.

• bazi_from_pillarsA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses that the tool reverses the pillars to find possible birth dates and supports multiple candidate results, which is key behavioral context beyond simple mapping. It doesn't cover edge cases or error handling, but for a calculation tool this is acceptable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences. The first sentence states the trigger condition, the second describes the behavior and output. No wasted words; the example is compact and illustrative.

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

  Completeness4/5

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

  The tool has moderate complexity (reverse lookup with multiple candidates) and no output schema. The description explains the core outcome (complete chart data, multiple candidates) but doesn't specify the output structure or how many candidates to expect. Still, it's adequate for an AI agent to understand when and why to use it.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the schema already documents each parameter. The description adds an example format (甲子年丙寅月戊辰日壬子时) but doesn't clarify how it maps to the separate pillar parameters beyond that. Since the schema does the heavy lifting, the description only marginally enhances parameter understanding.

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

  Purpose5/5

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

  Description clearly states the tool is called when the user provides the four pillars directly, and uses the specific verb '反推' (reverse-engineer) to explain it infers possible birth dates and returns complete chart data. This distinguishes it from sibling tools like bazi_paipan, which presumably takes a birth date/time.

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

  Usage Guidelines4/5

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

  The description explicitly starts with the condition '用户直接给出四柱干支...时调用' (call when the user directly provides the four pillars), giving clear when-to-use guidance. However, it does not explicitly name alternatives or state when not to use it, leaving the exclusion implicit rather than explicit.

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

• record_loadA
  4.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It implies a read-only operation ('load') but does not disclose return format, error behavior (e.g., record not found, multiple matches), or permission requirements. Adequate but with clear gaps.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two compact sentences: the first states the core action and resource, the second gives a concrete usage scenario and workflow. No wasted words; information is front-loaded.

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

  Completeness4/5

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

  Given the tool's simplicity (2 optional params, no output schema), the description covers the main workflow and integration with bazi_ai_reading. However, it omits details about return data structure and handling of ambiguous/missing records, which would make it fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema has 100% coverage with parameter descriptions, including '支持模糊匹配' for name and '优先于 name' for record_id. The description adds no additional semantic value beyond what the schema already provides, so baseline 3 is appropriate.

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

  Purpose5/5

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

  Description clearly states it loads saved fate chart records by name or ID, with specific examples. It distinguishes itself from sibling tools by mentioning the follow-up call to bazi_ai_reading for interpretation.

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

  Usage Guidelines5/5

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

  Provides explicit user-phrase triggers ('看张三的八字', '调出我存的盘') and a clear sequencing instruction: call this tool first to load data, then call bazi_ai_reading. This effectively guides when to use this tool versus alternatives.

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

• liuyao_surname_paipanA
  4.3/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It discloses the calculation basis (surname/number + time), the action (auto-cast and assemble hexagram), and the return value (hexagram and calculation process). It could add more detail about determinism or timezone handling, but the main behavior is transparent enough for a computation tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single dense Chinese sentence that efficiently packages usage conditions, trigger criteria, method, and return information. It is somewhat long but every clause adds value, with no filler.

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

  Completeness4/5

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

  Despite lacking both annotations and an output schema, the description covers when to use the tool, the exact inputs (stroke count/number + time), and what it returns (hexagram and calculation process). Minor gaps like gender's role are covered by the schema, so the overall context is sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so baseline is 3. The description adds meaning by clarifying that surname_num is either the surname stroke count or a 1-64 number, and that year/month/day/hour together form the divination time. This goes beyond the schema's individual field descriptions.

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

  Purpose5/5

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

  Description clearly states the tool auto-casts and assembles a Liuyao hexagram from surname stroke count or a 1-64 number plus the divination time, and explicitly lists supported scenarios (decision, exam, job, cooperation, investment, relationship, lawsuit, travel). It differentiates from sibling liuyao_paipan by emphasizing the surname/number-based automatic method used when manual shaking is impossible.

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

  Usage Guidelines4/5

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

  The description provides an explicit usage condition: 'when the user is uncertain about specific event outcomes and cannot manually shake the hexagram'. It lists many relevant situations, but it does not directly name an alternative tool (e.g., liuyao_paipan) for cases where manual shaking is possible, relying instead on sibling context.

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

• record_saveA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses that the tool prompts the user before saving (with an example quote), requires a configured account, and results in records that can be loaded by name. It could mention duplicate/overwrite behavior, but the provided transparency is above average.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences and front-loaded with the core purpose. The second sentence includes a quoted prompt, which is actionable and not redundant. Every sentence contributes value.

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

  Completeness4/5

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

  For a save tool, the description covers the full workflow: saving, user confirmation, account requirement, and future loading. No output schema is present, but the outcome is clear. It lacks error handling details, but that's acceptable given the conversational context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers 100% of parameters, so baseline is 3. The description adds meaning by explaining that the name is used as a trigger phrase for future loads and gives the example '张三的八字', while data is described as the complete chart object. This exceeds the schema's bare descriptions.

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

  Purpose5/5

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

  The description clearly states the action: 'save chart result as a named record' (把排盘结果保存为带名字的记录), and distinguishes it from siblings like record_list/record_load by explaining how the saved record can be loaded later via name. The verb 'save' and resource '命盘记录' are specific and unambiguous.

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

  Usage Guidelines4/5

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

  It provides a clear trigger condition: after completing a chart (排完盘后), the agent should proactively ask the user if they want to save. It also notes the prerequisite of having a configured account. While it doesn't explicitly compare with alternatives, the context is sufficient for an agent to know when to invoke this tool.

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

• bazi_ai_readingA
  4.9/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden and does so admirably. It discloses the cost and billing method, the need for server-side credentials (LINGJI_TOKEN or LINGJI_PHONE+LINGJI_PASSWORD), and clarifies that this tool, unlike paipan interfaces, is the analysis layer. This gives the agent insight into side effects and dependencies.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact yet information-dense, with every sentence serving a purpose: cost, differentiation, usage trigger, data source, workflow, and prerequisites. It is front-loaded with the core function and pricing, making it easy to scan.

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

  Completeness5/5

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

  Given the tool's moderate complexity (5 params, no output schema, 9 siblings), the description is remarkably complete. It covers what the tool does, when to use it, how to obtain/load inputs, the cost, and required setup, leaving no critical operational gaps for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already covers all parameters with descriptions (100% coverage), but the description adds valuable cross-tool semantics by explaining that bazi and gua_data correspond to return objects from bazi_paipan/liuyao_paipan and by noting the default role and prompt_type behavior. This goes beyond the schema's bare field descriptions.

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

  Purpose5/5

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

  The description clearly identifies the tool as a paid ('3元/次') professional fortune-telling interpretation service, with a specific verb ('深度解读') and resource (八字/六爻 interpretation). It also explicitly distinguishes itself from sibling paipan tools by stating they '只输出结构化数据、不做分析,' making the tool's unique purpose unmistakable.

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

  Usage Guidelines5/5

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

  Provides explicit when-to-use guidance: whenever a user asks for interpretation, analysis, judgment, or advice, this tool must be called rather than the paipan interfaces, and the agent should not guess. It also gives a clear workflow: pass bazi_paipan/liuyao_paipan output directly, or load a saved chart with record_load first, plus a prerequisite about server account configuration.

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