Server Quality Checklist

Tool Scores

• submit_billB
  3/5.0
  Behavior2/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 disclosing behavioral traits. It merely says 'submit' without mentioning preconditions, whether it's a write operation, potential irreversibility, required permissions, or what state the document transitions to. The lack of behavioral context is a significant gap for a mutation 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 compact and well-structured, with a one-line purpose followed by a clear Args list. It avoids fluff. However, it is quite terse and could benefit from a usage sentence, though that is more a completeness issue than a conciseness one.

  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 tool is a mutation operation with no annotations and an output schema, the description should explain the submission lifecycle, required prior states, and effects. It does not. For an ERP tool, this is insufficient for an agent to make an informed invocation, despite the output schema covering return values.

  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 input schema has 0% description coverage, but the description adds meaningful context: form_id is given with concrete examples, numbers is explained with format and examples, and ids is clarified, including the important constraint that numbers and ids are mutually exclusive. This goes well beyond the bare schema.

  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 ('提交' = submit) and resource ('金蝶云星空单据' = Kingdee Cloud documents). This clearly distinguishes it from sibling tools like audit, save, or delete. However, it doesn't explicitly differentiate 'submit' from 'submit for approval' or describe the exact workflow state change, leaving some ambiguity for non-domain users.

  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?

  There is no guidance on when to use this tool versus alternatives such as audit_bill or save_bill. The description only states what it does, not when to choose it. No exclusion criteria or alternative scenarios are mentioned.

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

• audit_billB
  3.3/5.0
  Behavior2/5

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

  With no annotations, the description carries full responsibility for behavioral disclosure. It fails to mention that this is a mutating operation that changes document approval status, nor does it address permissions, reversibility, or side effects. The only behavioral note is the mutual exclusivity of numbers and ids, which is more of a parameter constraint than a behavioral trait.

  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, consisting of a single purpose sentence followed by an Args list. It is front-loaded with the main action and avoids wasted words. However, it is very terse and could include a brief usage note without sacrificing clarity.

  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 description covers purpose and parameters but omits usage guidelines, behavioral impact, and system context. For a mutation tool with no annotations, this leaves significant gaps. The presence of an output schema lessens the need for return-value details but does not compensate for missing safety and usage information.

  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 description coverage is 0%, so the description must compensate, and it does. It explains each parameter: form_id with concrete examples, numbers with comma-separated format, and ids with format and the explicit mutually exclusive relationship to numbers. This adds meaningful semantics beyond the raw schema.

  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 '审核' (audit/approve) with the resource '单据' (documents), clearly indicating the action. It distinguishes from sibling tools like unaudit_bill and query_bill by focusing on the approval operation. Parameter examples like BD_MATERIAL and SAL_SaleOrder further clarify the scope.

  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?

  No guidance is provided on when to use this tool versus alternatives such as submit_bill or unaudit_bill. The description simply states the action and parameter details, leaving the agent reliant on sibling names to 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.

• execute_operationA
  3.5/5.0
  Behavior2/5

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

  With no annotations, the description must disclose effects, permissions, and reversibility, but it only lists parameters. It mentions operation types (禁用/反禁用) but does not explain what happens to the document, whether it requires authorization, or whether the operation can be undone.

  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: a one-line summary followed by a structured Args list. Each parameter line conveys necessary details with no redundant text.

  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 is an action-oriented operation with no annotations and only minimal context; the description lacks usage conditions, side effects, and error behavior. While the output schema exists and parameters are covered, the agent is not equipped to understand when this operation is appropriate or what consequences it carries.

  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?

  Despite 0% schema description coverage, the description comprehensively documents all four parameters with examples (form_id like BD_MATERIAL), common op_number values, and the split/selection rule for numbers vs ids. This adds essential meaning beyond the bare schema.

  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 opens with a clear action: '执行金蝶云星空单据操作（禁用、反禁用等）', specifying the resource (Kingdee Cloud Star documents) and concrete operation types. This distinguishes it from sibling tools like audit_bill/delete_bill, as execute_operation is a generic dispatch for operations such as Forbid/Enable, not covered by those specialized names.

  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?

  No guidance is provided on when to choose execute_operation over sibling tools; there are no alternatives mentioned or exclusions. The description only explains parameter values, leaving the agent to infer applicability from examples like Forbid/Enable.

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

• push_billA
  3.5/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden. It only lists parameters and examples, but does not disclose side effects, prerequisites, error behavior, or whether the operation is irreversible. 'Push' implies creating a downstream document, but no details are provided.

  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 well-structured docstring with a short purpose line and an Args list. Each parameter is one line, making it easy to scan. Slightly verbose but not excessive; it earns its place.

  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 description covers all 9 parameters effectively, and an output schema exists so return values are not needed. However, it lacks usage context and behavioral side effects (e.g., what happens on error, whether it creates a new document or updates). Given the tool's complexity, more context is needed for full completeness.

  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?

  The schema has no parameter descriptions (coverage 0%), but the description thoroughly explains every parameter, including examples (form_id: SAL_SaleOrder), relationships (numbers and ids are mutually exclusive), and JSON formatting for custom_params. This fully compensates for the schema gap.

  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 pushes Kingdee Cloud Star documents (e.g., sales order to delivery notice), with a specific verb and resource. This distinguishes it from sibling tools like query_bill or save_bill.

  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?

  No explicit guidance on when to use this tool versus alternatives. The description only explains parameters like '不填则用默认规则' (use default rule if not filled) but does not mention when to prefer this over related operations such as save_bill or execute_operation.

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

• unaudit_billA
  3.5/5.0
  Behavior2/5

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

  With no annotations provided, the description must disclose behavioral traits. It merely states the action (unaudit) without explaining side effects (e.g., that this is a state-changing operation, requires certain permissions, may fail if already un-audited, or is irreversible). It does not describe the outcome or return value. The parameter constraint about numbers/ids is helpful but does not cover the tool's behavioral impact.

  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 well-structured: a single sentence stating the purpose, followed by a formatted Args section. No unnecessary detail or fluff. The parameter documentation is organized with clear examples and constraints, making it easy to scan and understand.

  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?

  Although an output schema exists (so return value explanation is not required), the description lacks critical context for a mutation tool. It does not differentiate from sibling tools, does not explain when to use it, and does not disclose side effects or prerequisites. For a tool that alters document state, this is a significant gap. The description covers parameters well but omits the broader operational context users need.

  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?

  The schema has 0% description coverage, so the description's Args section carries the full burden. It clearly explains each parameter: form_id provides examples (BD_MATERIAL, SAL_SaleOrder), numbers is described as document numbers with comma-separated examples, and ids as internal IDs. It also explicitly states that numbers and ids are mutually exclusive (二选一), which is crucial operational semantics beyond the schema's property definitions.

  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: '反审核金蝶云星空单据' (unaudit Kingdee Cloud Starry Sky documents). It uses a specific verb ('unaudit') and resource (Kingdee Cloud documents), distinguishing it from sibling tools like audit_bill, delete_bill, and submit_bill. The purpose is immediately understandable.

  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 explicit guidance on when to use this tool versus alternatives. It does not mention that audit_bill is the inverse operation, nor does it explain scenarios where unaudit_bill is preferred over delete_bill or push_bill. The only usage hint is the parameter constraint that numbers and ids are mutually exclusive (二选一), which is parameter-level rather than tool-level guidance.

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

• delete_billA
  3.6/5.0
  Behavior2/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 states 'delete' but does not disclose that the operation is likely irreversible, whether it is a soft or hard delete, or whether audited bills can be deleted. This lack of warning is a significant gap for a destructive 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?

  The description is concise and front-loaded: one primary purpose sentence followed by a compact parameter list. Every sentence earns its place, including the mutual-exclusion note. No wasted words.

  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 destructive tool with no annotations and no schema descriptions, the description is incomplete. It omits return values, error behavior, and critical constraints (e.g., cannot delete audited documents). The output schema may define the return shape, but the description does not cover operational context needed for safe use.

  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 description adds valuable meaning beyond the bare schema: it provides examples for form_id (e.g., BD_MATERIAL, SAL_SaleOrder), clarifies comma-separated formats for numbers and ids, and explicitly states that numbers and ids are mutually exclusive. This compensates well for the 0% schema description coverage.

  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 '删除金蝶云星空单据' (Delete Kingdee Cloud Galaxy document), which identifies the verb 'delete' and the resource type 'bill/document'. This unambiguously distinguishes it from sibling tools like audit_bill or save_bill, making the purpose specific and clear.

  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 say when to use this tool versus alternatives. The purpose implies it is for deleting bills, but no guidance is given on prerequisites (e.g., bill must be unapproved) or exclusions. Usage is implied rather than stated, so it meets the minimum viable level.

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

• save_billA
  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 behavioral disclosure burden. It does mention the auto-wrap behavior for Model keys, which is a positive detail, but it does not disclose permissions, side effects of overwriting data, or error handling. For a mutation tool, this is insufficient.

  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: a clear one-sentence purpose followed by a two-item Args list. Each line adds value, from the purpose to the examples and the auto-wrap note. It is front-loaded and free of unnecessary 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?

  The description covers both parameters with examples and explains the create/update nature. With an output schema present, not detailing return values is acceptable. However, it lacks mention of prerequisites (e.g., existing form IDs) or failure modes, leaving minor context gaps.

  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?

  The input schema has no parameter descriptions (0% coverage). The description compensates thoroughly by explaining both form_id and model_data, providing a concrete JSON example, and noting the automatic wrapping of data without a Model key. This goes far beyond the bare schema type declarations.

  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 '保存金蝶云星空单据（新增或更新）' (save Kingdee Cloud documents, create or update), which specifies the verb and resource. It includes concrete examples of form IDs (BD_MATERIAL, SAL_SaleOrder), distinguishing this from sibling tools like query_bill and submit_bill.

  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 for creating or updating documents but provides no explicit guidance on when to use alternatives like submit_bill or audit_bill. It lacks exclusion conditions or scenarios where this tool should not be used, relying instead on the tool name and basic context.

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

• query_billA
  4.1/5.0
  Behavior4/5

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

  Absent annotations, the description reveals essential behavior: top_count maps to TopRowCount and also acts as page size; limit is only honored when top_count=0; start_row supports pagination via next_start_row. It also states the return type. It does not mention authentication or side effects, but 'query' implies a read-only operation.

  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?

  Structured as an Args docstring, it front-loads function purpose and uses compact bullet-like entries for each parameter with examples. It is slightly long but every sentence contributes to clarification.

  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?

  Covers all 7 parameters with semantics and interaction rules, and specifies return format. Since an output schema exists, return values are handled there. The only significant absence is sibling-tool usage guidance, which is already penalized in usage_guidelines.

  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 provides only property names with zero descriptions. The description compensates by explaining form_id common values, field_keys comma-separated format, filter_string and order_string examples, top_count semantics including Kingdee TopRowCount/Limit interaction, start_row pagination, and limit condition.

  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 states '查询金蝶云星空单据数据（返回二维数组）' clearly identifying the operation (query), resource (Kingdee Cloud Star documents), and return format (2D array). It differentiates from siblings like query_bill_json (JSON output) and count_bill (count).

  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?

  Despite thorough parameter explanations, the description never mentions when to prefer query_bill over other sibling tools such as query_bill_json, view_bill, or query_bill_all. There is no alternative guidance or exclusion criteria.

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

• query_metadataA
  4.4/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 disclosing behavior. It clearly indicates this is a read-only metadata query ('查询元数据') and explains what information it retrieves (field names, types). It does not go into permissions or side effects, but the query nature is evident and the purpose is well specified.

  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 well-structured: a clear first sentence stating the purpose, a second sentence giving the use case, and a brief Args section. Every sentence earns its place, and the structure is front-loaded with the key information.

  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 (one parameter, no annotations) and the existence of an output schema, the description is quite complete. It explains what the tool does, why it is useful, and defines the parameter. It lacks mention of limitations or alternatives, but these are not critical for this straightforward metadata query.

  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 has one required parameter 'form_id' with no description, but the tool description compensates by explaining that it is the form ID and providing examples such as SAL_SaleOrder, PUR_PurchaseOrder, BD_MATERIAL. This adds significant meaning beyond the schema.

  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 that the tool queries metadata (field structure information) for Kingdee Cloud Star forms. It specifies the verb '查询' (query) and the resource '元数据' (metadata), distinguishing it from sibling tools that operate on bill data directly.

  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 the context of use: to obtain field information for constructing query and save parameters. This makes the tool's use case clear, though it does not explicitly mention alternatives or when not to use it. It is more than implied usage, but lacks explicit exclusions.

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

• count_billA
  4.5/5.0
  Behavior4/5

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

  The description discloses the return format including estimated_rows, is_exact, and hint, and explains the implication of is_exact=false (actual rows >= estimated). It also states that no data content is returned, which is a key behavioral trait. Given no annotations, this covers the main behavioral aspects.

  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 organized with a clear purpose, usage, return format, and attributes. Each section provides useful info without unnecessary fluff, though it is somewhat verbose for a simple count tool.

  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?

  The tool has 2 parameters (both explained), an output schema, and the description covers the return fields, the estimation caveat, and usage guidance. Considering the moderate complexity, the description is fully sufficient.

  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?

  The input schema provides no descriptions (coverage 0%), but the description gives concrete examples for both form_id (e.g., SAL_SaleOrder) and filter_string (e.g., FDate condition), adding essential meaning beyond the schema.

  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 it estimates the number of rows for a query condition (估算某查询条件下的数据行数) and explicitly notes it does not return data content (不返回数据内容), distinguishing it from sibling query tools.

  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 states the intended use as probing before large data volume queries (用于大数据量查询前的探测) and advises monthly/weekly sharding when the estimate is not exact (建议按月/周分片查询). It does not name alternatives explicitly but provides clear context for when to use this tool.

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

• view_billA
  4.5/5.0
  Behavior4/5

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

  Without annotations, the description carries the full burden. It explicitly states '查看' (view), indicating a read-only behavior, and promises '所有字段信息' (all field information), describing what the agent can expect. No side effects or prerequisites are mentioned, but for a straightforward view operation this is reasonable transparency.

  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 structured. The main purpose is stated in two brief sentences, followed by a compact parameter list with examples. Every sentence contributes value and there is no redundant information.

  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 description covers purpose, usage, and all parameters effectively. Since an output schema exists, the absence of return-value explanations is acceptable. The only notable gap is the lack of explicit sibling differentiation, but the 'single record' focus already suggests the tool's niche, making it 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%, but the description fully compensates. It defines form_id with examples (BD_MATERIAL, SAL_SaleOrder), explains number as the document number with an example, and clarifies bill_id as the internal ID, plus the mutual exclusivity rule. This adds substantial semantic meaning beyond the bare schema.

  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: '查看金蝶云星空单条记录的完整详情' (view complete details of a single record). It specifies a precise verb (view), a resource (bill record), and a scope (single record), which distinguishes it from sibling tools like query_bill that likely handle lists or broader queries.

  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 explains how to use the tool: by number or internal ID, with the constraint that number and bill_id are mutually exclusive. It implies the appropriate context (when you need complete details of one specific record) but does not explicitly name alternatives or state when not to use it, so it falls slightly short of full exclusions.

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

• query_bill_rangeA
  4.7/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. It discloses key behaviors: automatic date slicing, independent pagination per chunk, the 1 MB inline limit, streaming write behavior when output_path is set, and error handling with partial row counts. This is exceptionally transparent.

  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 well-structured with a one-line summary, behavior explanation, output format examples, and a parameter list. It is slightly long but every section earns its place. The return format examples are slightly redundant given the output schema exists, but they provide valuable concrete context.

  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?

  For a complex tool with 9 parameters and chunking logic, the description is complete. It covers all parameters, behavioral nuances, output modes, error handling, and format details. An agent can confidently select and invoke this tool correctly based on this description alone.

  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?

  The input schema has zero description coverage, but the description compensates fully. Every parameter is explained with meaning and examples: form_id (e.g., SAL_SaleOrder), field_keys (comma-separated), date_field (e.g., FDate), date_from/to (inclusive/exclusive), extra_filter (AND-combined), chunk (month/week/day), output_path (empty vs absolute path), and page_size (default 2000).

  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: it automatically slices a date range into chunks and paginates through each chunk, making it suitable for cross-month/year queries. This distinguishes it from siblings like query_bill (likely single-range) and query_bill_all (likely without chunking).

  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 specifies that it is suited for cross-month/year queries and explains the trade-off between inline return (MCP 1 MB limit) and streaming to file for large spans. It does not explicitly name alternative tools, but the context is clear enough for an agent to decide when to use it.

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

• query_bill_jsonA
  4.8/5.0
  Behavior5/5

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

  With no annotations, the description carries full responsibility. It thoroughly explains pagination via start_row and next_start_row, the dual role of top_count (TopRowCount and page size), and the conditional behavior of limit. This exceeds typical transparency for a 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?

  The description is well-structured: a one-sentence purpose, a one-sentence distinction, then a clear Args list. Each sentence earns its place, and the parameter details are dense but readable. No filler or redundancy.

  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?

  For a 7-parameter tool with no annotations and no schema descriptions, this description is unusually complete. It covers return format, pagination, parameter semantics, and sibling differentiation. The presence of an output schema means the return structure doesn't need further explanation, so the description is sufficient.

  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 coverage is 0%, but the description compensates fully. Every parameter is explained with concrete examples: form_id lists common values, field_keys shows a sample, top_count explains its Kingdee mapping and edge cases, and limit's conditional behavior is clarified. This goes far beyond what the bare schema properties provide.

  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 Kingdee Cloud document data and returns JSON format with field names as keys. It explicitly differentiates from the sibling query_bill by highlighting the output format difference, making the purpose specific and distinct.

  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 contrasts with query_bill, explaining when the JSON format is preferable. However, it does not list all alternative tools or provide explicit exclusions for when not to use this tool, so it stops short of full usage guidance.

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

• query_bill_to_fileA
  4.8/5.0
  Behavior5/5

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

  With no annotations provided, the description carries full responsibility. It discloses auto-pagination, streaming writes, no in-memory accumulation, return format with row_count/bytes, error behavior with partial rows, and max_rows truncation—all beyond what the schema shows.

  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 front-loaded with purpose and use case, followed by a concise return-format spec and a clearly structured Args list. Every section earns its place given the tool's complexity (7 parameters and rich behavior).

  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 output schema is included in the description (@return/error shape) and the parameters are fully documented, the description covers the entire invocation lifecycle: when to use, how to call, and what to expect on success/failure. No major gaps remain.

  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 compensate fully. It explains every parameter with concrete examples (e.g., form_id like 'SAL_SaleOrder', filter_string like "FDate >= '2025-01-01'"), defaults, and the output_path example. This is exemplary.

  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 opens with a specific verb+resource+outcome: '自动翻页并流式写入本地文件' (auto-paginate and stream-write to local file). It clearly distinguishes from siblings like query_bill and view_bill by emphasizing file output for large exports.

  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 states suitability for large data exports ('适合大数据量导出（万行以上）') and explains the streaming/no-memory-accumulation advantage. It mentions the file can be read by Read tool or pandas/polars, but does not explicitly state when to avoid this tool or name alternatives.

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

• query_bill_allA
  5/5.0
  Behavior5/5

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

  No annotations are provided, so the description carries full burden. It discloses the pagination loop, early termination via max_rows, exhausted flag semantics, next_start_row continuation, and the MCP response limit rationale. This is rich behavioral context beyond a simple 'query' 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 well-structured with clear sections: purpose, usage guidance, return format, and parameter breakdown. It is front-loaded with the core behavior, and every line adds value with no filler content. The use of bullets and examples enhances readability.

  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?

  The tool has moderate complexity (auto-pagination), but the description covers all aspects: purpose, when to use, parameter semantics, return format, and edge cases (exhausted=false, next_start_row). It is self-contained and sufficient for a correct invocation, especially given the absent annotations and schema descriptions.

  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 coverage is 0%, but the description thoroughly explains all 6 parameters with concrete examples (e.g., form_id: SAL_SaleOrder, field_keys: FBillNo,FDate,FAmount, filter_string: FDate >= '2025-01-01'). It also clarifies default values and constraints for max_rows and page_size, fully compensating for the lack of schema 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 tool performs auto-paginated queries until all records are fetched or max_rows is reached. It distinguishes itself from siblings by explicitly naming alternatives for large datasets (query_bill_to_file, query_bill_range) and defines the exact resource (bills) and operation (query).

  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?

  The description explicitly states that this tool is suitable for estimating ≤ 5000 rows and directs users to query_bill_to_file or query_bill_range for larger datasets, citing the MCP 1 MB return limit. This provides clear when-to-use and when-not-to-use guidance with alternatives.

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