Server Quality Checklist

Tool Scores

• release_game_assetB
  3.3/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. It does disclose the tag precondition, but it never states that the file will be uploaded/attached to the release, whether existing assets are overwritten, what token scopes are required, or what success/failure looks like. For an externally mutating tool this is a significant transparency gap.

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

  Conciseness5/5

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

  The description is two short sentences with the purpose front-loaded and the critical prerequisite immediately after. There is no redundancy or filler; every clause 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 schema fully documents all seven parameters, so invocation-level information is largely covered. However, with no annotations and no output schema, the description omits expected return behavior, overwrite semantics, token permission expectations, and selection guidance relative to full_upload_game. It is adequate but not complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description adds no additional parameter meaning beyond the schema; the tag mapping, default upload target, and extension rules are already documented in the input 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 clear action and target: publish the game installation package to GitHub/GitCode Release. It also adds the key precondition that the Release tag v{version} must already exist. It does not explicitly distinguish this step from the sibling full_upload_game, so it falls short of full sibling differentiation.

  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 an explicit precondition: the corresponding Release tag must already exist. This implies the tool should not be used when the tag has not been created, and it suggests the tag must be prepared beforehand. However, no alternatives are named, and it does not compare against full_upload_game or other upload-related tools.

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

• add_game_entryA
  3.5/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 behavioral burden. It discloses that this tool mutates config.json, pushes to two repositories, and automatically writes publish_time, which goes beyond the obvious 'add' side effects. It does not cover error cases or failure behavior, but the key mutation facts are clearly declared.

  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 names the operation, the target, the side effect, and the special publish_time behavior. Every phrase carries useful signal with no filler or repetition.

  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 mutation tool with 7 required parameters, one nested object, no output schema, and no annotations, the description covers the core behavior but leaves gaps: no return value description, no duplicate/conflict handling, and no indication of what a successful invocation returns. The schema supplies paramter details, but the description alone is not fully self-sufficient for invoking this tool safely in a complex flow.

  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 100% parameter description coverage, so the schema already documents tokens, shas, config, library, and the game object. The description adds no new parameter-level meaning; mentioning publish_time mirrors the schema's default-current-time semantics rather than extending them.

  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 and target: adding a game entry to config.json and pushing it back to both repositories. It also mentions the automatic publish_time write, which clarifies the tool's specific responsibility. It does not explicitly compare itself to siblings like full_upload_game, but the config-focused operation is still distinguishable from upload/asset tools.

  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 full_upload_game or release_game_asset. The description implies the use case (adding a game entry), but it does not state prerequisites, exclusions, or how this tool fits into the larger workflow.

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

• full_upload_gameA
  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 responsibility for behavioral disclosure, and it explicitly lists the five side-effecting steps: verifying tokens, getting config, adding a game entry, uploading a cover, and publishing a release. This makes clear that the tool performs mutating publishing actions. It does not mention partial-failure behavior, but the numbered pipeline is strong evidence of what the tool will do.

  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?

  One lead sentence plus a five-step numbered list is compact and front-loaded with the core purpose and the action sequence. The phrase '最常用的完整流程' is slightly promotional but not wasteful.

  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?

  Inputs and the high-level process are well covered, and the tool is callable from the provided information alone. However, there is no output schema and the description never states what the call returns (e.g., release URLs, success status) or how to handle partial failures in a multi-step flow—these are meaningful gaps for an orchestration tool.

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

  Parameters3/5

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

  Schema description coverage is high at 86%, so the schema already documents most parameters, setting the baseline at 3. The description only maps high-level steps to concepts like tokens and cover upload, and adds nothing about upload_target, file_path, image_path, or nested game fields beyond what the schema provides.

  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 opens with '一键完整上传游戏' and enumerates the five concrete steps, making it clear this is a composite upload workflow rather than a single sibling tool. It doesn't explicitly contrast itself with siblings, but the numbered step list and '完整流程' signal its scope well.

  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?

  '最常用的完整流程' implies this is the default when the user wants the whole pipeline from token verification to release publishing. It gives no explicit when-not-to-use guidance and does not name the granular sibling tools as alternatives, so usage context is implied rather than fully stated.

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

• check_tokensA
  3.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 states the core behavior (validating tokens) and that it is a pre-check, but it does not disclose return semantics, failure behavior, or whether it makes external network calls. Not contradictory, but minimal beyond the obvious.

  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, efficient sentence that front-loads the primary purpose and adds the key usage context. There is zero filler or redundancy.

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

  Completeness3/5

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

  The tool is simple with only two documented parameters, but there is no output schema and the description does not specify what the tool returns (e.g., boolean, status, error). An agent knows what it validates and when to call it, but not how to interpret the result, which is a notable gap.

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

  Parameters3/5

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

  Schema description coverage is 100%: both token_gh and token_gt are already fully described in the schema. The description adds no additional meaning or syntax details for the parameters, so the baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description uses a specific verb '验证' (validate) with clear resources: GitHub and GitCode access tokens. It also describes the tool as a pre-check for all upload operations, which clearly sets it apart from the sibling tools that perform uploads, config, or asset management.

  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 states when to use this tool: before all upload operations ('所有上传操作的前置检查'). It does not name alternatives or give when-not conditions, but no sibling tool performs token validation, so the usage context is clear without exclusions.

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

• get_configA
  4/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 behavioral disclosure burden. It clearly indicates a read-style retrieval operation ('获取') and states what will be returned. It does not explicitly say it is side-effect-free or describe token failure behavior, but for a simple getter this is reasonably transparent.

  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 sentence, front-loaded with the action and resource, and it explicitly names the key outputs. There is no filler 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, fully parameter-documented getter, the description is nearly complete: it identifies the target config file, the library dimension, and the returned fields. Since there is no output schema, a brief note on token requirements or error behavior would add completeness, but the required token parameters already signal those prerequisites.

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

  Parameters3/5

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

  The input schema already documents all three parameters at 100% coverage, including the library enum and token meanings. The description adds no meaningful parameter-level detail beyond restating the desktop/mobile distinction, so the baseline of 3 applies.

  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 a specific verb ('获取'), resource ('config.json'), scope ('指定游戏库（桌面/移动）'), and return contents ('games 列表以及配置 sha'). This makes it clearly distinguishable from sibling tools like get_cover_image or get_apk_id without requiring schema inspection.

  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 intended use is implied: call this when you need the config.json or games list for a desktop or mobile library. However, there is no explicit when-to-use guidance, exclusions, or any mention of alternatives among the sibling tools.

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

• get_cover_imageA
  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 disclosure burden and does meaningful work: it reveals the CDN-first download strategy with fallback to the GitHub Contents API, and the write-to-local-file-then-return behavior. It stops short of stating what happens when both sources fail, but the disclosed flow is substantive.

  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 terse sentences with no filler: purpose, download strategy, and return value each occupy one sentence. The most important fact (what the tool does) is front-loaded.

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

  Completeness4/5

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

  For a 5-parameter tool with no annotations and no output schema, the description covers the core contract: source, fallback order, write destination, and return payload (path and size). The only notable gap is error behavior when both CDN and GitHub API fail, which neither the schema nor the description specifies.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline applies — every parameter (game_id, library, use_cdn, token_gh, output_path) is already described in the schema. The description reinforces the {game_id}.webp naming link to game_id and explains why token_gh is conditional, but adds little beyond what the schema's parameter descriptions already state.

  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 a specific verb and resource: downloading the cover image for a given game, with the exact file pattern {game_id}.webp. It also names the deliverable (local file plus returned path and size), which cleanly distinguishes it from the sibling upload_cover_image.

  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 when to use the tool: whenever a cover image needs to be fetched from the remote library. However, it never names an alternative or states when not to use it, so the agent must infer selection from the purpose alone rather than from explicit routing.

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

• upload_cover_imageA
  4/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden and does well by disclosing that images are automatically resized to a 640x480 maximum, converted to WebP, and synchronized across two repositories. This goes beyond a simple 'upload cover' statement and gives the agent concrete expectations about side effects.

  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 with no filler: the first states the action and target, the second lists the transformations, and the third mentions the sync behavior. Every sentence adds distinct value.

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

  Completeness4/5

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

  For a moderately simple 5-parameter upload tool, the description covers the core behavior, transformations, target branch, and sync. It does not describe the return value or failure modes, but with no output schema and no annotations, those are notable but not critical gaps given the clarity of the operation.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description does not add much parameter-level meaning beyond the schema, though the mention of WebP conversion and two-repo sync helps explain why image_path and the two tokens are needed.

  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 ('上传或更新'), resource ('游戏封面图片'), and target ('data 分支'), distinguishing it from sibling read-only tool get_cover_image and broader tool full_upload_game. It also adds key transformation details that define what the tool uniquely does.

  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 when to use the tool: when uploading or updating a game cover image rather than retrieving it. However, it does not explicitly name alternatives or state when not to use it, such as when a full game release is needed (full_upload_game) or when only reading the cover is needed (get_cover_image).

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

• get_apk_idA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral burden. It discloses the read/parse nature of the operation, the dot-to-underscore transformation, and the AUL rule compliance of the generated ID. It does not discuss error conditions or non-APK inputs, but the core behavior is clearly and honestly described.

  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 dense sentences: the first states the operation and transformation, the second gives the exact usage context. Every clause earns its place, and the most important behavioral info is front-loaded.

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

  Completeness4/5

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

  For a single-parameter tool with no output schema, the description adequately explains the input, the processing, the output format, and the intended usage point in the upload flow. It could be slightly more complete by noting error/failure behavior, but nothing essential is missing for an agent to invoke it correctly.

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

  Parameters3/5

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

  Schema description coverage is 100%: the single parameter apk_path is already described as the absolute path to a local APK file. The description reinforces this by saying '本地 APK 文件', but adds no new parameter-level detail beyond what the schema already provides, so the baseline of 3 applies.

  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 names a specific verb ('解析' / parse), a specific resource (APK package name), and the exact output transformation (dots replaced with underscores to produce an AUL-compliant game ID). This cleanly distinguishes it from sibling tools like upload_cover_image or release_game_asset, which operate on different resources and outputs.

  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 states when the tool is used: before mobile (library=mobile) game upload for automatic ID generation. It provides clear context but does not explicitly mention when not to use it or name alternatives, so it stops short of a 5.

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