Server Quality Checklist

Tool Scores

• kdy_customer_debtC
  2.7/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 explicitly notes '（只读）' (read-only), which informs the agent that this operation does not mutate data. Beyond that, it reveals nothing about the returned data shape, authorization requirements, or any side effects. For a simple read operation, the read-only note adds some value, but significant behavioral context is missing.

  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 compact sentence with the read-only note front-loaded before the endpoint. It is efficient with no filler words, achieving maximal brevity. This is good conciseness, though the content itself is minimal.

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

  Completeness2/5

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

  The tool has only one optional parameter and no output schema, so it is simple, but the description still omits any explanation of the parameter's meaning, potential default behavior when omitted, or the shape of the response. An agent calling this tool would lack necessary information to correctly supply or interpret the customer_id, making the description inadequate for full comprehension.

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

  Parameters1/5

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

  Schema description coverage is 0% and the description does not mention the customer_id parameter at all. The input schema only shows a string with a default of '', leaving its purpose entirely unexplained. The description fails to compensate for the lack of schema documentation, so an agent cannot infer what customer_id represents or how to use it.

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

  Purpose4/5

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

  The description clearly states the operation ('查询客户欠款余额' – query customer debt balance) and explicitly marks it as read-only. However, it does not differentiate this tool from sibling tools like kdy_list_ar_receive or kdy_list_ap_pay, which may also involve customer balances. The verb and resource are specific, but the distinction from related tools is absent.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives, no context about filtering or scoping, and no mention of required prerequisites. It simply states the action and the endpoint. There is no explicit or implicit usage scenario.

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

• kdy_list_accountC
  2.7/5.0
  Behavior2/5

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

  With no annotations, the description must carry the full burden of behavioral disclosure. It states '只读' (read-only), which is a key trait, but it does not mention pagination behavior, sorting, or any side effects beyond read-only. The '对账基准' phrase is more about purpose than behavior. This is minimal disclosure.

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

  Conciseness3/5

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

  The description is a single concise sentence that front-loads the main purpose, which is good. However, it omits essential details (parameter semantics, pagination, etc.), making it under-specified rather than appropriately concise. It is not bloated, but it does not fully serve the agent's needs.

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

  Completeness2/5

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

  For a list tool with two parameters, no annotations, and no output schema, the description should at least mention the parameters and clarify the return value. It only gives a high-level purpose and an API endpoint. Pagination is not addressed, and the meaning of '对账基准' is left to inference. This is incomplete.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description does not mention the 'page' or 'size' parameters at all. Since the schema provides no descriptions and only defaults, the agent has no guidance on how to use these parameters effectively. The description fails to compensate for the schema's gap.

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

  Purpose4/5

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

  The description clearly states it queries the list of accounting subjects (会计科目) and marks it as read-only and a reconciliation benchmark. The resource is specific, but it does not explicitly name its closest sibling (kdy_list_account_type) or differentiate them, so it falls short of a perfect score.

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

  Usage Guidelines3/5

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

  The description labels the tool as '对账基准' (reconciliation benchmark), which implies its use in reconciliation workflows, but it does not provide explicit when-to-use or when-not-to-use guidance relative to other list tools like kdy_list_account_type or kdy_list_voucher. The intent is inferable but not explicit.

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

• kdy_auth_fetch_tokenC
  2.9/5.0
  Behavior3/5

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

  无注解提供行为信息，描述中说明了自动退回第三方实例ID并走push_app_authorize的行为，算是一个行为透明度。但未披露副作用、返回格式或权限要求，对于无注解的工具来说，描述承担了较多责任，但信息仍不完整。

  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?

  描述仅一句话，简洁明了，没有冗余信息。但是结构上缺乏对核心行为的展开，不过作为简短描述，效率较高。

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

  Completeness2/5

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

  工具简单，仅一个参数且无输出schema，但描述未说明返回结构、使用前提或失败情况。结合无注解，描述内容不足以让智能体完全理解如何正确使用该工具，因此2分。

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

  Parameters1/5

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

  唯一参数uid在schema中仅有默认值，schema描述覆盖率为0%，描述中也未提及uid的用途或格式。描述完全没有补偿参数语义，导致调用方无法理解uid的作用，因此评分很低。

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

  Purpose4/5

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

  描述明确说明工具作用是'换取 app-token'，动词和资源清晰。但未解释'app-token'的具体用途，且与兄弟工具（如业务查询类）区分不够明显，不过认证类工具本身独特，因此给4分。

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

  Usage Guidelines3/5

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

  描述提到了当缺少app_key/app_secret时的自动替代流程，这提供了一定的使用场景说明。但没有明确说明何时应该主动调用此工具，也没有提及与其他认证或业务工具的先后顺序，使用指南不够充分。

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

• kdy_calc_invoice_taxC
  2.9/5.0
  Behavior3/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 key behaviors: it's a local engine (no remote Kingdee call), returns tax/untaxed/deductibility/compliance info, and auto-infers 'kind' when empty. However, it doesn't describe failure modes, input validation behavior, or what happens on inconsistent inputs, leaving some behavioral uncertainty for a 9-parameter calculation 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 two concise sentences with no filler. It front-loads the core purpose and the local-engine distinction, then lists return fields and the optional-kind behavior. Efficient and scannable, though its brevity comes at the cost of parameter coverage.

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

  Completeness2/5

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

  For a tool with 9 parameters, 0% schema coverage, no annotations, and no output schema, the description is markedly incomplete. It explains overall purpose and outputs but leaves the majority of parameter semantics undocumented, and provides no guidance on how the calculation handles edge cases. An agent would struggle to construct a correct call beyond the two required fields (invoice_no, total).

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

  Parameters1/5

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

  Schema description coverage is 0% and the description only mentions the 'kind' parameter (auto-inferred when empty). The remaining eight parameters (fuel, title, total, face_net, face_tax, passenger, invoice_no, category_hint) are completely unexplained in both schema and description. With zero coverage and 9 parameters, the description fails to compensate, leaving agents to guess at meaningful semantics like the distinction between 'total' vs 'face_net' vs 'face_tax'.

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

  Purpose4/5

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

  Purpose is clear: calculate invoice tax (发票税额计算). The description states it uses a local engine (not calling Kingdee) and lists exact return fields (税额/不含税/是否可抵扣/说明/合规问题). This distinguishes it from sibling tools, which are all Kingdee data CRUD/list operations, so an agent can tell it apart from the others.

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

  Usage Guidelines3/5

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

  The description implies usage context (local tax calculation when you don't want to call Kingdee), and the sibling set clarifies the boundary since all siblings are Kingdee data operations while this is a computation. However, there is no explicit when-to-use vs. when-not-to-use guidance, no mention of alternatives, and no prerequisite conditions (e.g., whether invoice data must already exist).

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

• kdy_list_voucherC
  2.9/5.0
  Behavior3/5

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

  No annotations are provided, so the description must disclose behavior. It correctly states the operation is read-only (只读) and includes the HTTP GET method, both useful safety hints. However, it does not disclose pagination behavior, response format, date filtering semantics, or any potential edge cases. The read-only mention adds value beyond nothing, but the coverage is thin.

  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, short sentence that gets to the point efficiently. It is not over-verbose and front-loads the core action. However, it omits necessary details, so it is not perfectly structured for completeness, but for what it contains, it is concise.

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

  Completeness1/5

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

  With four parameters, no output schema, and no annotations, the description is severely incomplete. It provides no parameter guidance, no expected return format, no pagination rules, and no mention of date formats or required scopes. An agent would struggle to call this tool correctly without external knowledge.

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

  Parameters1/5

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

  Schema description coverage is 0%, so the description must explain the four parameters (page, size, start_date, end_date). It does not mention any of them, leaving agents to guess format, meaning, or constraints. This is a critical gap for a tool with four parameters.

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

  Purpose4/5

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

  Description clearly states it queries a list of accounting vouchers (查询会计凭证列表) and notes it is read-only and for reconciliation (进销项/账面对账). The verb 'list' and resource 'voucher' are explicit, and the reconciliation purpose distinguishes it from other list tools like list_invoice. However, it does not explicitly differentiate from sibling tools such as kdy_get_voucher, so it doesn't achieve a 5.

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

  Usage Guidelines3/5

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

  The description gives a use context ('进销项/账面对账' – for input/output & account reconciliation), implying when to use it. But it provides no explicit exclusion or mention of alternatives, such as kdy_get_voucher for individual vouchers or other list tools. The usage guidance is implied rather than explicit.

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

• kdy_reconciliationC
  2.9/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 of behavioral disclosure. The description explicitly states '只读' (read-only) and includes the GET method, which is a positive disclosure of the operation's side-effect-free nature. However, it does not mention whether authentication is required, whether pagination exists, or any potential rate limits. For a simple query tool, this partial disclosure is acceptable but not comprehensive.

  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 extremely concise, consisting of a single statement and an HTTP endpoint. It is front-loaded with the primary purpose. There is no redundancy or filler. However, it is so terse that it sacrifices essential detail, which slightly reduces its effectiveness, but as a structural assessment, it is appropriately minimal.

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

  Completeness1/5

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

  Despite being a simple tool with only three optional parameters and no output schema, the description is fundamentally incomplete for correct invocation. The absence of any parameter explanation means the agent cannot know how to construct the request (e.g., date range format, whether customer_id is optional or required for filtering). No information about the response structure is given, but that is secondary. The tool is not callable correctly without additional context about parameters.

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

  Parameters1/5

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

  Three parameters (end, start, customer_id) are present in the schema, all without descriptions or types beyond 'string'. The description does not explain the purpose or format of any parameter, nor does it clarify how they relate to the reconciliation statement query. With 0% schema description coverage, the description was expected to compensate, but it does not. An agent cannot correctly populate these parameters based on the given information.

  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 purpose: '查询往来对账单（只读）' which means 'Query reconciliation statement (read-only)'. It specifies the resource (往来对账单 / reconciliation statement) and the verb (查询 / query). The HTTP method GET and path are also provided, further clarifying the intended operation. This distinguishes it from sibling tools like kdy_list_ar_receive or kdy_customer_debt, which focus on different accounting entities.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It does not mention any specific scenarios or conditions that would select this tool over other query tools (e.g., kdy_list_invoice, kdy_list_voucher). There is no explicit 'when not to use' or reference to sibling tools. The agent is left to infer from the name and the read-only note, which is insufficient for clear decision-making.

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

• kdy_list_ar_receiveB
  3/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 behavioral burden. It does disclose read-only status explicitly ('只读') and reveals the HTTP GET method, which signals a safe query operation. However, it fails to mention pagination behavior, authentication requirements (despite a sibling kdy_auth_fetch_token existing), or what the response contains, leaving meaningful gaps given the zero annotation coverage.

  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 efficient sentence that front-loads the core purpose ('查询收款单列表') before the endpoint reference. There is no wasted text, though one might argue it errs on the side of under-specification rather than genuine conciseness.

  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 simple paginated list tool with only two optional parameters and no output schema, the description conveys the essential navigation (read-only, endpoint, resource). Yet it lacks sibling differentiation and parameter context, and with no annotations or output schema it leaves the agent to infer behavior, making it merely adequate rather than complete.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate for parameter meaning, but it adds nothing about page or size. Although these names are somewhat self-explanatory (pagination), the description offers zero elaboration on bounds, defaults behavior, or interaction between them, so it does not compensate for the schema's silence.

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

  Purpose4/5

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

  The description states a specific verb and resource ('查询收款单列表' = query receipt list) and identifies itself as read-only, citing the exact endpoint GET /jdy/v2/arap/ar_credit. However, it does not differentiate from the many sibling list tools (kdy_list_voucher, kdy_list_invoice, kdy_list_ap_pay), so an agent might struggle to pick this over those without domain knowledge.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus the alternatives. With siblings like kdy_list_ap_pay (accounts payable), kdy_list_invoice, and kdy_list_voucher all doing similar list operations, there is no statement of when this AR receipt list is appropriate, nor any exclusions or conditions.

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

• kdy_list_expenseB
  3.1/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 full behavioral disclosure. It discloses the read-only nature and a critical uncertainty (endpoint may return 404). However, it does not mention response format, pagination behavior, or other operational details that an agent might need.

  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 concise, with two sentences that each serve a purpose: one states functionality, the other adds a crucial warning. It is front-loaded with the core purpose and is free of redundancy, though it could be slightly more informative without sacrificing brevity.

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

  Completeness2/5

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

  Given the simple tool with two parameters and no output schema, the description should explain the parameters and expected return, but it does not. The warning about 404 is helpful, but the lack of parameter semantics makes the description incomplete for reliable invocation.

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

  Parameters2/5

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

  The schema defines page and size with defaults but no descriptions. The tool description does not explain these parameters at all. With 0% schema coverage, the description should compensate but fails to do so, leaving the agent to guess that these are pagination controls.

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

  Purpose4/5

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

  The description clearly states the action (query) and the resource (expense report list), and explicitly marks it as read-only. While it does not explicitly differentiate from sibling list tools, the name and resource are distinct enough for an agent to identify its purpose.

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

  Usage Guidelines3/5

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

  The description mentions 'read-only' implying it is safe for queries, but it does not specify when to use this tool over alternatives or any prerequisites. The warning about potential 404 errors is useful context but does not guide selection decisions.

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

• kdy_healthB
  3.2/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 disclosing side effects or safety. The word 'health check' implies a read-only operation, but the description never explicitly states that it does not modify state or require special permissions. It also does not explain what 'ready' means, whether errors can occur, or if any side effects exist. The list of returned items gives some transparency but lacks explicit behavioral guarantees.

  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 a single, concise sentence that leads with the purpose ('health check') and immediately lists the key output items. There is no filler, and every part of the sentence carries meaning. This is an exemplary level of conciseness.

  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 simple, parameterless tool, the description covers what it returns but omits usage context and return format. It does not specify whether the output is a flat object, a list, or contains nested structures, and there is no output schema to fill this gap. It also lacks guidance on when to call it. While it is adequate for a trivial health check, an agent would benefit from knowing that this is a safe preflight check and what the expected response structure looks like.

  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 tool has zero parameters, so the schema covers everything trivially. According to the calibration, a baseline of 4 is appropriate when there are no parameters. The description does not need to add parameter semantics, and it correctly avoids describing any.

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

  Purpose4/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 health check and lists the specific status items it returns (environment, base address, read-only switch, credentials, token readiness). This distinguishes it from the sibling tools, which are all about data retrieval or authentication, but the description does not explicitly name a sibling or differentiate itself. It is straightforward 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 Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It does not mention typical use cases, prerequisites, or when a health check is appropriate. Without any context, an agent cannot infer when to call this tool before others. Sibling tools like kdy_auth_fetch_token suggest this might be a preliminary check, but that is left to inference.

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

• kdy_list_invoiceB
  3.3/5.0
  Behavior2/5

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

  没有提供注释，因此描述必须完全承担行为透明度的责任。描述仅提到“只读”，没有说明返回格式、分页行为、可能需要的认证或其他副作用。对于无注释的工具，这明显不足，无法让代理充分了解调用该工具的影响。

  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?

  描述简短且直接，前三句分别说明核心功能、端点和过滤方式，没有冗余。信息密度高，结构清晰，易于快速理解。

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

  Completeness2/5

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

  没有输出模式，描述需要提供返回相关上下文。但描述仅给出端点和过滤参数，未提及响应结构、分页细节、日期格式或其他必要信息。对于有6个参数且无注释的工具，这种描述不足以让代理成功调用和解析结果。

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

  Parameters2/5

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

  Schema描述覆盖率为0%，描述必须补偿。它解释了bill_type和invoice_type的用途（用于过滤），但其他参数（page、size、start_date、end_date）都没有在描述中说明。虽然参数有默认值，但代理无法从描述中理解这些参数的含义和格式，参数语义不完整。

  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?

  描述明确说明这是一个发票列表查询（只读），并给出具体端点，同时指出销项/进项不是不同端点，而是通过过滤参数区分，这让它与其他工具（如kdy_get_invoice、kdy_list_voucher）清楚区分。目的明确，动词和资源具体。

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

  Usage Guidelines3/5

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

  描述提供了关于如何使用bill_type和invoice_type过滤的指导，并澄清了销项/进项不需要单独端点，这有助于选择。但它没有明确说明何时使用此工具与其他替代工具（如kdy_get_invoice），也没有给出排除条件。使用指引部分隐含，但不完整。

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

• kdy_fill_reimbursementA
  3.5/5.0
  Behavior3/5

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

  Since no annotations are provided, the description carries the full burden of behavioral disclosure. It explains that dry_run defaults to true, meaning the tool only constructs and passes guards without actual submission, which is important behavioral context. However, it does not state what the tool returns (e.g., the constructed draft object or an ID), nor whether any side effects occur when dry_run=false. The safety info is partially conveyed but incomplete.

  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 concise and front-loaded with the core purpose. It uses two sentences and a compact parameter list, avoiding any filler. Every piece of information serves a functional role, from the controlled-write label to the dry_run default. It is appropriately sized for the tool's complexity.

  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 has several parameters, including a nested structured array, and no output schema. The description provides enough insight into the main data structure (invoices) and the dry_run behavior, but it omits details about the other three parameters and the expected return value. Given the complexity, an agent might struggle to correctly populate 'trip_form_id' or 'cost_category_id' without further clarification. Overall, the description is adequate but leaves notable gaps.

  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?

  With 0% schema description coverage, the description must compensate. It provides detailed semantics for the 'invoices' array by listing expected fields (invoice_no, total, category_hint, etc.) and clarifies the 'dry_run' parameter's role. However, it gives no explanation for 'applicant', 'trip_form_id', or 'cost_category_id', leaving agents to infer their meaning from names alone. While it covers some parameters well, it misses others.

  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 a specific verb and resource: 'fill reimbursement draft' (发票代填报销单草稿). It also labels the operation as 'controlled write' (受控写入), which distinguishes it from read-only tools like kdy_list_invoice or kdy_get_reimb_detail. The purpose is unambiguous and not a mere restatement of the name.

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

  Usage Guidelines2/5

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

  The description provides minimal guidance on when to use this tool versus alternatives. It mentions the default dry_run behavior and that payment/submission remains manual, but it does not explain when an agent should choose this tool over others, nor does it specify conditions that make it inappropriate. There is no explicit 'use this when...' or 'avoid if...' guidance.

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

• kdy_get_invoiceA
  3.6/5.0
  Behavior3/5

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

  No annotations were provided, so the description carries the full burden. It explicitly declares read-only (只读) and the GET method, which is valuable safety context. However, it doesn't disclose what happens on a missing/invalid id, authentication requirements, or response shape. The read-only claim is honest and consistent, so no contradiction.

  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 brief sentences with zero filler: the purpose is front-loaded ('按 id 查询发票详情'), the read-only flag is included, and the endpoint is appended. Every character earns its place, and the description is appropriately short for a single-parameter read tool.

  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 simple single-parameter read-only tool with no output schema, the description covers the essential surface: what it does, by what key, that it's non-destructive, and the underlying endpoint. Details like not-found behavior or auth are absent, but given the tool's low complexity, the coverage is nearly 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 0%, so the description must compensate. It ties the single parameter invoice_id to the 'by id' lookup purpose, confirming the parameter's role as the record identifier. But it adds no format, source, or constraint details beyond what the id-type field already implies — adequate but minimal.

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

  Purpose4/5

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

  The description states a specific verb+resource: '按 id 查询发票详情' (query invoice detail by id), which clearly distinguishes it from the sibling kdy_list_invoice (list vs. single-by-id). It also discloses the REST endpoint GET /jdy/v2/fi/invoice_detail, reinforcing the operation. It doesn't explicitly name the sibling, but the 'by id' scope makes differentiation immediate.

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

  Usage Guidelines3/5

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

  Usage is implied: the 'by id' phrasing signals this is for fetching one invoice when an identifier is known, which contrasts with kdy_list_invoice for searching/listing. However, no explicit when-to-use, when-not-to-use, or alternative-naming guidance is provided. An agent must infer the selection rule from the sibling names rather than being told.

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

• kdy_list_ap_payA
  3.6/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 of behavioral disclosure. It explicitly states the tool is read-only and that writing payments is permanently forbidden ('付款写入永久禁止'), which is critical safety information. It also mentions the endpoint as a technical reference. While it doesn't cover auth, rate limits, or failure modes, the read-only and no-write disclosure is strong 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 exceptionally concise: a single sentence with the purpose and read-only constraint, followed by the endpoint. Every word carries meaning; the prohibition on writes is immediately clear. No fluff or 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?

  For a simple paginated list tool with only two optional parameters and no output schema, the description covers the essential operational context: what it does, that it's read-only, and its endpoint. It doesn't describe return format or pagination specifics, but given the simplicity of the tool and the absence of additional requirements, it is sufficient. The lack of explicit output documentation is a minor gap.

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

  Parameters2/5

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

  Schema description coverage is 0%, meaning the description provides no explanation for the two parameters (page and size). While the names are self-explanatory for pagination, the description does not compensate for the lack of schema descriptions. It neither elaborates on pagination behavior, defaults, or any specific usage guidance for parameters, so agents must infer meaning solely from names.

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

  Purpose4/5

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

  The description clearly states the action: query a payment list ('查询付款单列表'), specifies the resource (付款单/payment order), and adds that it is read-only. It also provides the endpoint for reference. While it doesn't explicitly contrast it with sibling list tools like kdy_list_ar_receive, the resource is distinct enough that an agent can understand its purpose.

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

  Usage Guidelines3/5

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

  The description implies a use case ('付款核对' - payment reconciliation) and emphasizes read-only nature, but it does not explicitly state when NOT to use the tool or mention alternative tools (e.g., for writing payments, it says writing is permanently forbidden but doesn't point to a write tool). The context is present but without explicit routing guidance.

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

• kdy_current_userA
  3.7/5.0
  Behavior3/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 read-only behavior and zero parameters, which are important. However, it does not mention how authentication is handled, potential error responses, or what happens if the user is not authenticated. The lack of behavioral detail beyond these basics leaves gaps for an agent relying solely on the description.

  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 a single, compact sentence that conveys the purpose, key behavioral traits, and the API endpoint. It is front-loaded with the most critical information (current user info, read-only, zero params) and includes the endpoint for reference. Every word earns its place with 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?

  Given the tool's extreme simplicity (no params, no output schema, likely a trivial GET), the description is nearly complete. It states what the tool returns (current user info) and its role as a connectivity probe. The only minor gap is lack of explicit comparison to the sibling 'kdy_health', which could help an agent decide which probe to invoke. Otherwise, the description suffices for correct invocation.

  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 tool has zero parameters, and the schema is empty (100% schema coverage). The description reinforces this by stating '零参数' (zero parameters). Since no parameters exist, the baseline is 4, and the description appropriately adds no extra parameter details beyond confirming the absence, which is sufficient.

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

  Purpose4/5

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

  The description clearly states the tool retrieves current user information via a specific GET endpoint. The phrase '只读' (read-only) and '连通性探针' (connectivity probe) add context, but it does not explicitly distinguish it from the sibling tool 'kdy_health', which likely serves a similar diagnostic purpose. Purpose is clear, but sibling differentiation is left implicit.

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

  Usage Guidelines3/5

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

  The description implies this is a lightweight connectivity probe, suggesting it could be used to verify connectivity or authentication. However, it does not explicitly state when to use this over alternatives like 'kdy_health' or 'kdy_auth_fetch_token'. The usage context is present but not formalized with exclusions or alternative routing.

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

• kdy_get_voucherA
  3.7/5.0
  Behavior3/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 it does disclose the read-only nature ('只读') and the HTTP method (GET). However, it does not mention authentication requirements, error behavior (e.g., invalid ID), or response format. For a simple read operation, this is a moderate level of transparency, but it misses some behavioral context an agent might need.

  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 a single, concise sentence that front-loads the core purpose and includes the endpoint for reference. There is no fluff or redundancy; every word contributes to understanding the tool's function.

  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?

  Given the simplicity (one parameter, no output schema, no nested objects), the description is adequate but not complete. It does not mention what the response contains (beyond 'details'), likely error cases, or authentication nuances. Since annotations are absent, an agent might need more context to handle edge cases, but the core operation is clear.

  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 schema has one required string parameter (voucher_id) with no description, and the schema description coverage is 0%, so the description must compensate. It does indicate that the tool operates 'by id', which implies voucher_id is the identifier, but it does not explain the format, constraints, or where to obtain the ID. This adds minimal semantic value beyond the schema's type and required flag.

  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 queries voucher details by ID, specifying the verb (query), resource (voucher details), and the identifier. The 'by id' scope distinguishes it from list-type siblings like kdy_list_voucher, and the read-only note reinforces its non-mutating nature. It is 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 Guidelines3/5

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

  The description does not explicitly state when to use this tool versus alternatives like kdy_list_voucher or kdy_get_invoice. The usage is implied by the 'by id' phrasing, but there is no guidance on preconditions (e.g., having a voucher_id) or exclusions (e.g., when not to use). The agent must infer the appropriate context.

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

• kdy_list_account_typeA
  3.8/5.0
  Behavior3/5

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

  没有提供任何注释，因此描述承担全部行为披露责任。描述明确声明'只读'，但未披露返回格式、错误处理、分页或任何副作用。对于零参数的简单查询，'只读'提供了一定透明度，但整体信息有限。

  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?

  描述仅一句话，但包含了核心目的、只读属性、参数信息以及HTTP端点，信息密度高且无冗余，结构清晰、重点前置。

  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?

  对于零参数只读操作，描述已经提供了足够的信息来调用API，但缺少返回结构的说明（无输出schema）以及可能的错误场景。考虑到工具简单性，基本完整，但可稍加补充返回数据格式。

  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?

  参数为0，schema覆盖率100%，描述无需解释任何参数。按照基线，零参数工具的描述在参数语义维度上应得4分，因为不存在需要补充的参数信息。

  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?

  描述明确给出了动作（查询）、资源（科目类别）以及只读和零参数的信息，并提供了HTTP端点。这足以让agent准确理解工具用途，并与其他账户/发票类工具区分开。

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

  Usage Guidelines2/5

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

  描述没有任何关于何时使用此工具、何时使用替代方案的说明。虽然零参数和只读属性暗示了简单查询场景，但未显式说明与其他列表工具（如kdy_list_account）的区别或适用条件。

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

• kdy_get_reimb_detailA
  4.5/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. The description explicitly labels the operation as '只读' (read-only), which is critical behavioral information. It also mentions the API endpoint. However, it does not disclose return format, potential errors, or that the operation is safe (though read-only implies it). Overall, it provides essential transparency for a simple query tool.

  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?

  Three short sentences contain only essential information: purpose, API endpoint, and parameter guidance. No fluff, and the key semantic distinction (which parameter to use) is front-loaded. Perfectly concise for a simple lookup tool.

  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 is simple with two optional string parameters and no output schema. The description provides the API path and parameter semantics, which covers the core usage. However, it omits any indication of what the response contains (e.g., full reimbursement record details) or whether the input must be exactly one of the two parameters (though it says '择一传入'). Given the tool's simplicity, this is still fairly complete.

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

  Parameters5/5

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

  Schema description coverage is 0%, so the description must explain parameters. It does so clearly: reimb_id is the internal document code, number is the document number, and it explicitly notes that either one should be passed ('择一传入'). This adds meaning far beyond the schema's bare property definitions, making parameter usage clear.

  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 action (查询报销单详情) and resource (reimb_detail), and adds '只读' to distinguish it as a read-only operation. The API endpoint is explicitly provided, making the purpose unambiguous and distinct from sibling tools like kdy_list_expense or kdy_fill_reimbursement.

  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?

  Provides guidance on parameter usage: states that reimb_id is the internal code and number is the document number, and advises that either one should be passed based on sandbox testing. However, it doesn't explicitly mention when to use this tool versus the similar list tools (e.g., kdy_list_expense), though the 'detail' nature implies singular retrieval.

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