Server Quality Checklist

Tool Scores

• upload_attachmentA
  3.7/5.0
  Behavior3/5

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

  The description reveals that it decodes base64 and calls an internal API, and mentions a file size limit (10MB default). However, with no annotations, it does not disclose potential side effects, authentication requirements beyond user_token, or error handling behavior, which limits transparency.

  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 structured with a brief introductory sentence followed by sections for details, args, and returns. It is clear but could be more concise; the front-loaded purpose sentence is effective.

  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 presence of an output schema (UploadResult) and no annotations, the description adequately covers purpose, parameters, size limits, and multiple file support. Missing details like error handling and output format description are partially compensated by the output 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?

  The schema already provides detailed descriptions for each parameter (e.g., file_name, file_base64). The tool description adds value by explaining the decoding process and the size limit, which are not in the schema. This extra context justifies a score above baseline 3.

  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 '批量上传附件文件' (batch upload attachment files) with a specific verb and resource. The name and context distinguish it from siblings like check_attachment_requirement and calculate_leave_days, making its purpose 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?

  No guidance is provided on when to use this tool versus alternatives. The description does not mention any prerequisites, exclusions, or comparison to other tools, leaving the agent to infer usage context.

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

• select_organizationA
  4.1/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. It describes input and output but does not explicitly state if it is read-only or has side effects. Indexing detail is helpful.

  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?

  Description is fairly concise with Args/Returns sections. Could be slightly more compact, but structure aids clarity.

  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?

  Output schema exists, so return values are covered. Missing error handling (e.g., out-of-bounds index), but overall complete for its purpose.

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

  Parameters4/5

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

  Schema coverage is 0%, but description adds meaning: user_orgs is from init_leave_flow, selected_index is 0-based. This compensates for missing 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 it selects organization info by index from a list, specifically from init_leave_flow's result, distinguishing it from sibling tools like init_leave_flow.

  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?

  Explicitly states when to use (multiple orgs from init_leave_flow) and provides indexing conversion guidance. Does not mention when not to use, but context is sufficient.

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

• calculate_leave_daysA
  4.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries full burden. It describes calling an internal API, performing balance checks per leave type, and returning a result. However, it does not disclose potential destructive effects, side effects, or error handling (e.g., insufficient balance).

  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 Args and Returns sections, front-loading the purpose. It is clear and informative, though slightly verbose with internal API references. Every sentence adds value.

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

  Completeness4/5

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

  Given the high parameter count and lack of schema descriptions, the description covers each parameter adequately. It mentions the return type CalcDaysResult and its contents. Missing details like error conditions or constraints (e.g., date format) but still sufficient for an agent.

  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 provides detailed explanations for all 10 parameters, including their purpose (e.g., leave_type for balance check, avlb_annl_leave from init_leave_flow) and defaults (start_time_code default AM). This adds significant value 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 the tool calculates actual leave days and validates leave balance, using specific verbs ('计算', '校验') and resources ('休假天数', '假期余额'). It distinguishes from siblings like init_leave_flow and submit_leave_application by focusing on the calculation step.

  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 context on when to use (after init_leave_flow, which provides balances) and for which leave types balance checks are performed. It does not explicitly state when not to use or direct to alternatives, but the flow is implied.

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

• submit_leave_applicationA
  4.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 full burden. It discloses that the tool submits a leave process and returns an application number, indicating mutation. However, it does not detail side effects, authentication requirements, error handling, or data validation behaviors beyond the basic action.

  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 purpose statement, a workflow note, and a detailed parameter list. While it is somewhat lengthy, the structured format compensates for the complexity of 16 parameters. Every sentence adds value, but could be slightly more concise.

  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 complexity and lack of output schema in the provided data, the description includes a Returns section specifying 'SubmitResult: 包含申请单号'. It also references all necessary prerequisite tools, making it a complete guide for using this tool in the leave application workflow.

  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's Args section provides clear, tool-specific context for each parameter, including source tool (e.g., 'from init_leave_flow') and allowed values (e.g., 'file_ids: 附件 ID 列表...无附件时为 None'). This adds significant meaning beyond the schema titles.

  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 '提交请假申请' (submit leave application) and '返回申请单号' (returns application number). It distinguishes itself from sibling tools like init_leave_flow and calculate_leave_days by being the final submission step.

  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 that all information must be gathered from other tools (user info from init_leave_flow, organization from select_organization, etc.), providing implicit workflow guidance. It lacks explicit when-not-to-use or alternative tool mentions but effectively communicates the prerequisite context.

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

• init_leave_flowA
  4.6/5.0
  Behavior4/5

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

  No annotations exist, but the description discloses key behaviors: the sequential API calls, automatic token retrieval, and the has_pending_leave flag. It does not mention any side effects, but the tool is read-heavy and non-destructive.

  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 paragraphs and bullets, providing thorough information without redundancy. Every sentence adds value.

  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 an output schema exists, the description does not need to detail return values but still summarizes them (user info, positions, leave types, etc.). It covers edge cases like token fetching and pending leave.

  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 fully explains both parameters: user_token as optional but preferred, and user_code as fallback with automatic token fetch. It adds 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 the tool initializes a leave flow and distinguishes it from siblings like submit_leave_application. It mentions the specific sequence of backend steps, making its unique purpose clear.

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

  Usage Guidelines4/5

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

  The description provides explicit guidelines for two calling modes (user_token vs user_code) and mentions a special case for pending leave. However, it does not explicitly state when not to use this tool compared to siblings.

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

• check_attachment_requirementA
  4.7/5.0
  Behavior5/5

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

  No annotations are provided, so the description fully bears the burden. It discloses the logic for each leave type, including rejection conditions for 丧假>3 days, and the output action structure.

  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 bullet points and clear sections. It is slightly verbose but every sentence adds value.

  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 complexity of 7 leave type rules and the presence of an output schema, the description covers all necessary context for an agent to use the tool correctly.

  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 explains each parameter in detail: leave_type (leave type name), leave_days (from calculate_leave_days), has_attachment (user upload status). Adds 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 the tool checks attachment requirements based on leave type. It lists 7 leave types with specific rules, distinguishing it from sibling tools like upload_attachment and submit_leave_application.

  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 tells when to use the tool to determine the next action (upload or submit) based on has_attachment. It lacks explicit when-not-to-use or exclusions but provides clear context.

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