Server Quality Checklist

Tool Scores

• get_issueC
  2.6/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action ('获取') without mentioning whether this is a read-only operation, if it requires authentication, rate limits, error conditions, or what the return format looks like. For a tool with no annotations, this leaves significant behavioral gaps.

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

  Conciseness4/5

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

  The description is a single, efficient sentence in Chinese that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple retrieval tool, though it could be slightly more informative without losing conciseness.

  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's complexity (3 required parameters, no output schema, and no annotations), the description is incomplete. It doesn't explain what information is returned (e.g., issue details, comments, status), error handling, or how it integrates with sibling tools like 'update_issue'. For a tool with no output schema, more context about the return value would be helpful.

  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 description coverage is 100%, with all three parameters (owner, repo, issue_number) clearly documented in the schema. The description doesn't add any additional meaning or context about these parameters beyond what the schema provides. With high schema coverage, the baseline score of 3 is appropriate.

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

  Purpose3/5

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

  The description states the tool '获取 Gitee 仓库中的特定 Issue' (gets a specific issue from a Gitee repository), which provides a clear verb ('获取') and resource ('Issue'). However, it doesn't distinguish this tool from its sibling 'list_issues' or explain how it differs (single issue retrieval vs. listing multiple issues). The purpose is understandable but lacks 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 Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like 'list_issues' for browsing issues or 'update_issue' for modifying them. It doesn't mention prerequisites (e.g., needing repository access) or contextual constraints. Usage is implied by the name but not explicitly stated.

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

• get_userC
  2.6/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 full burden. It implies a read-only operation ('get'), but doesn't disclose behavioral traits like authentication requirements, rate limits, error handling, or what happens with invalid usernames. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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

  Conciseness4/5

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

  The description is a single, efficient sentence in Chinese, front-loaded with the core purpose. It's appropriately sized for a simple tool, with no wasted words, though it could be slightly more informative without losing conciseness.

  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's complexity (simple read operation), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what user information is returned, potential errors, or authentication needs. For a tool interacting with an external API like Gitee, more context is needed to use it effectively.

  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%, with the parameter 'username' documented in the schema. The description doesn't add any meaning beyond the schema, such as format constraints or examples. With high schema coverage, the baseline is 3, as the description doesn't compensate but also doesn't detract.

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

  Purpose3/5

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

  The description '获取 Gitee 用户信息' (Get Gitee user information) states a clear verb ('get') and resource ('user information'), but it's vague about what specific information is retrieved. It distinguishes from siblings like get_current_user, get_issue, etc., but doesn't specify how it differs from get_current_user beyond the username parameter requirement.

  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. It doesn't mention prerequisites, such as needing a valid username, or differentiate from get_current_user (which likely retrieves the authenticated user's info without a parameter). The description alone offers no usage context.

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

• list_issuesC
  2.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 full burden but offers minimal behavioral information. It doesn't disclose that this is a read-only operation (implied by 'list'), doesn't mention pagination behavior (though parameters suggest it), rate limits, authentication requirements, or what the return format looks like. The description adds almost no value beyond the tool name.

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

  Conciseness4/5

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

  The description is extremely concise - a single Chinese sentence. While this is efficient, it's arguably too brief given the tool's complexity (12 parameters, no annotations, no output schema). Every word earns its place, but more content would be justified for this tool.

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

  Completeness2/5

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

  For a tool with 12 parameters, no annotations, no output schema, and multiple sibling tools, the description is inadequate. It doesn't explain the tool's behavior, return format, error conditions, or differentiation from similar tools. The description fails to compensate for the lack of structured metadata about this non-trivial listing 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 schema fully documents all 12 parameters. The description adds no additional parameter information beyond what's in the schema - it doesn't explain relationships between parameters, provide examples, or clarify semantics. Baseline 3 is appropriate when the schema does all the parameter documentation work.

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

  Purpose3/5

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

  The description '列出 Gitee 仓库中的 Issues' (List issues in Gitee repositories) states the basic action and resource but is vague about scope and filtering capabilities. It doesn't distinguish this from sibling tools like 'get_issue' (which retrieves a single issue) or mention that this lists multiple issues with filtering options.

  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 about when to use this tool versus alternatives. The description doesn't mention that this is for listing multiple issues with filtering, while 'get_issue' is for retrieving a single specific issue, or that 'create_issue' is for creating new issues. There's no context about prerequisites or typical use cases.

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

• get_branchC
  2.7/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. While '获取' (get) implies a read operation, the description doesn't specify what information is returned (commit details? protection rules? last update?), whether authentication is required, rate limits, error conditions, or response format. For a read operation with zero annotation coverage, this leaves significant behavioral gaps.

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

  Conciseness5/5

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

  The description is a single, efficient sentence in Chinese that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple read operation and front-loads the essential information.

  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 read operation with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what branch information is returned, the response format, error handling, or authentication requirements. Given the complexity of Git operations and the lack of structured output documentation, more context is needed for effective tool use.

  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%, with all three parameters (owner, repo, branch) clearly documented in the schema. The description doesn't add any parameter semantics beyond what's already in the schema - it doesn't explain the relationship between owner/repo/branch, provide examples, or clarify edge cases. Baseline 3 is appropriate when the schema does the heavy lifting.

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

  Purpose3/5

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

  The description '获取 Gitee 仓库中的特定分支信息' clearly states the action (获取/get) and resource (分支信息/branch information) with a specific scope (Gitee repository). However, it doesn't distinguish this tool from 'list_branches' which is a sibling tool - the description implies this retrieves information about a specific branch rather than listing multiple branches, but this distinction isn't explicitly stated.

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

  Usage Guidelines2/5

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

  The description provides no guidance about when to use this tool versus alternatives. There's no mention of when to use 'get_branch' versus 'list_branches' (which appears in the sibling tools), nor any prerequisites or context for usage. The agent must infer usage from the tool name alone.

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

• update_pull_requestC
  2.7/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 the action is an update but doesn't cover critical traits: required permissions (e.g., write access), whether changes are reversible, rate limits, or what happens to unspecified fields (partial vs. full updates). For a mutation tool with 10 parameters, this lack of context is a significant 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 a single, efficient sentence in Chinese ('更新 Gitee 仓库中的 Pull Request'), which translates to 'Update Pull Request in Gitee repository'. It's front-loaded with the core action and resource, with zero wasted words. This is appropriately concise for the tool's purpose.

  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 complexity (10 parameters, mutation tool, no annotations, no output schema), the description is incomplete. It doesn't address behavioral aspects like authentication needs, error handling, or return values. For a tool that modifies Pull Requests with multiple fields, more context is needed to guide an AI agent effectively.

  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%, meaning all parameters are documented in the input schema. The description adds no additional meaning beyond the generic 'update' action—it doesn't explain parameter interactions, defaults, or constraints. With high schema coverage, the baseline is 3, as the description doesn't compensate but also doesn't detract.

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

  Purpose3/5

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

  The description '更新 Gitee 仓库中的 Pull Request' clearly states the action (update) and resource (Pull Request in Gitee repository), which is better than a tautology. However, it doesn't differentiate from sibling tools like 'update_issue' or specify what aspects can be updated beyond the generic term. It's vague about the scope of updates compared to alternatives.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., existing Pull Request), exclusions, or compare to siblings like 'merge_pull_request' or 'create_pull_request'. Usage is implied from the name but not explicitly stated, leaving gaps for an AI agent.

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

• add_issue_commentC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool adds a comment but doesn't describe what happens after submission (e.g., whether it returns the created comment, error handling for invalid inputs, authentication requirements, or rate limits). For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps.

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

  Conciseness5/5

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

  The description is a single, efficient sentence in Chinese that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with zero wasted 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?

  For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., comment object, success status), error conditions, or behavioral nuances like whether comments are editable after creation. Given the complexity of interacting with a Gitee API, more context is needed for effective agent use.

  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%, with all parameters clearly documented in the input schema (owner, repo, issue_number, body). The description adds no additional parameter semantics beyond what's already in the schema, such as format examples or constraints. Baseline 3 is appropriate when the schema does the heavy lifting.

  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 ('添加评论' means 'add comment') and target resource ('Gitee 仓库中的 Issue' means 'Issue in Gitee repository'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from potential alternatives like 'update_issue' which might also allow comment modifications, leaving room for 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 Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing issue), exclusions, or comparisons to sibling tools like 'update_issue' that might also handle comments. The agent must infer usage from the tool name alone.

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

• create_branchC
  2.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 full burden. It states it creates a branch but doesn't disclose behavioral traits: whether it requires specific permissions, what happens if the branch already exists, if it's idempotent, rate limits, or what the response contains. For a mutation tool with zero annotation coverage, this is a significant gap in 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 a single, efficient sentence in Chinese that directly states the tool's purpose. It's appropriately sized and front-loaded with no wasted words, making it easy for an agent to parse quickly.

  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 this is a mutation tool with no annotations, no output schema, and 4 parameters, the description is incomplete. It doesn't explain what the tool returns, error conditions, or behavioral nuances. The high schema coverage helps with parameters, but overall context for safe and effective use is lacking.

  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 schema already documents all 4 parameters thoroughly. The description adds no parameter-specific information beyond implying the tool operates on a Gitee repository. With high schema coverage, the baseline is 3 even without param details in the description.

  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 ('创建一个新分支' - create a new branch) and resource ('在 Gitee 仓库中' - in Gitee repository). It distinguishes from siblings like 'get_branch' (read) and 'list_branches' (list), but doesn't explicitly differentiate from other creation tools like 'create_issue' or 'create_pull_request' beyond the resource type.

  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 on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing repository access), when to use 'fork_repository' instead for cross-repository branching, or how it relates to 'push_files' for subsequent commits. The description provides only the basic function without contextual usage advice.

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

• create_issueC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. While '创建 Issue' implies a write operation, it doesn't disclose important behavioral aspects like authentication requirements, rate limits, whether the operation is idempotent, what happens on failure, or what the response looks like. For a mutation tool with zero annotation coverage, this is a significant 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 extremely concise - a single Chinese sentence that directly states the tool's purpose. There's zero waste or unnecessary elaboration, making it front-loaded and efficient for an AI agent to parse.

  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 mutation tool with 8 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what happens after creation, what the return value might be, error conditions, or how this tool relates to the sibling tools. The description alone doesn't provide enough context for confident tool selection and invocation.

  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 description coverage is 100%, with all 8 parameters well-documented in the schema itself. The description adds no additional parameter information beyond what's already in the schema. According to the rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description.

  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 ('创建 Issue' - create issue) and the resource ('在 Gitee 仓库中' - in Gitee repository), making the purpose immediately understandable. However, it doesn't differentiate this from sibling tools like 'update_issue' or explain how it differs from 'add_issue_comment', which would be needed for a perfect score.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. There's no mention of when to choose 'create_issue' over 'update_issue' or 'add_issue_comment', nor any context about prerequisites or appropriate situations for creating issues versus other repository actions.

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

• create_or_update_fileC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'create or update' which implies mutation, but doesn't specify whether this requires specific permissions, what happens on conflicts, whether changes are reversible, or any rate limits. The description is minimal and lacks critical behavioral context 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.

  Conciseness5/5

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

  The description is a single, efficient sentence in Chinese that directly states the tool's purpose. There's no wasted language or unnecessary elaboration. It's appropriately sized for a tool with comprehensive schema documentation.

  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 mutation tool with 7 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what happens when creating versus updating, what the SHA parameter does, what the return value looks like, or error conditions. The combination of sparse description and missing structured data leaves significant gaps for an AI agent.

  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%, providing good documentation for all 7 parameters. The description adds no additional parameter information beyond what's in the schema. The baseline score of 3 reflects adequate parameter documentation through the schema alone, though the description doesn't enhance understanding of parameter relationships or usage patterns.

  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 ('创建或更新文件' - create or update file) and the target resource ('在 Gitee 仓库中' - in Gitee repository). It distinguishes from siblings like 'create_repository' or 'get_file_contents' by focusing on file manipulation. However, it doesn't explicitly differentiate from 'push_files' which might have overlapping functionality.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose this over 'push_files' or 'create_branch' for related operations, nor does it specify prerequisites like authentication requirements or repository access levels.

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

• create_pull_requestC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states the action is creation but doesn't disclose permissions needed, whether it's idempotent, error conditions, rate limits, or what happens on success (e.g., PR number returned). For a mutation tool with 12 parameters, this leaves critical gaps.

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

  Conciseness5/5

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

  The description is a single, efficient sentence in Chinese that directly states the tool's purpose. It's front-loaded with the core action and resource, with zero wasted words. This is appropriately concise for a tool with well-documented parameters.

  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 complex mutation tool with 12 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns, error handling, authentication requirements, or side effects. The agent lacks critical context to use this tool effectively despite the good parameter schema.

  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%, providing clear documentation for all 12 parameters. The description adds no additional parameter semantics beyond what's in the schema (e.g., no examples, formatting tips, or constraints). Baseline 3 is appropriate when schema does the heavy lifting.

  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 ('创建' - create) and resource ('Pull Request') with the context ('在 Gitee 仓库中' - in Gitee repository). It distinguishes from siblings like 'merge_pull_request' or 'update_pull_request' by specifying creation. However, it doesn't explicitly differentiate from 'create_issue' or 'create_branch' beyond the resource name.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., existing branches), when to choose this over 'create_issue' for code changes, or how it relates to siblings like 'merge_pull_request'. The agent must infer usage from the name alone.

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

• create_repositoryC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('create') but doesn't describe what happens upon creation (e.g., whether it returns a repository object, error handling, or side effects). For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding the tool's behavior 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.

  Conciseness5/5

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

  The description is a single, efficient phrase ('创建 Gitee 仓库') that is front-loaded with the core action. There is no wasted language or unnecessary elaboration, making it highly concise and structurally sound for its purpose.

  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 complexity of a 10-parameter mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain return values, error conditions, authentication requirements, or how it differs from sibling tools. For a tool that creates resources, more context is needed to guide effective use by an AI agent.

  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 description coverage is 100%, with all 10 parameters well-documented in the schema (e.g., 'auto_init' for initialization, 'private' for visibility). The description adds no additional parameter information beyond what's in the schema. According to the rules, when schema coverage is high (>80%), the baseline score is 3 even without param details in the description.

  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 '创建 Gitee 仓库' (Create Gitee repository) clearly states the verb ('create') and resource ('Gitee repository'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'fork_repository' or 'create_or_update_file', which would require more specific language about creating a new repository from scratch.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication needs), when to choose this over 'fork_repository', or any constraints like rate limits or permissions required. The agent must infer usage solely from the tool name and parameters.

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

• fork_repositoryC
  2.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 full burden for behavioral disclosure. It states the action ('fork') but doesn't describe what happens during forking (e.g., creates a copy under the user's account, inherits content), potential side effects, authentication requirements, rate limits, or error conditions. This leaves significant gaps 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.

  Conciseness5/5

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

  The description is extremely concise ('Fork Gitee 仓库') with no wasted words, making it easy to parse. It's front-loaded with the core action and resource. Every word earns its place, though this conciseness comes at the cost of completeness.

  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 this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain the fork operation's behavior, what is returned (e.g., new repository details), error handling, or usage context. For a tool that modifies data, more detail is needed to guide the agent effectively.

  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%, with clear descriptions for all three parameters (owner, repo, organization). The description doesn't add any parameter semantics beyond what's in the schema, such as explaining the relationship between owner and organization or providing examples. Baseline 3 is appropriate since the schema does the heavy lifting.

  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 'Fork Gitee 仓库' clearly states the action (fork) and resource (Gitee repository) in a concise manner. It distinguishes from siblings like 'create_repository' which creates a new repository rather than forking an existing one. However, it doesn't specify what 'fork' entails (creating a copy under user's account).

  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 doesn't mention prerequisites (e.g., needing access to the source repository), when forking is appropriate versus cloning or creating new repositories, or any limitations. Sibling tools include related operations but no comparison is offered.

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

• get_file_contentsC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'gets' content, implying a read-only operation, but doesn't specify whether it requires authentication, rate limits, error handling (e.g., for non-existent paths), or output format (e.g., raw text vs. structured data). This leaves significant gaps for a tool with no annotation coverage.

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

  Conciseness5/5

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

  The description is a single, efficient sentence in Chinese that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse quickly. Every part of the sentence contributes essential information.

  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 complexity (a read operation with 4 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain behavioral aspects like authentication needs, error cases, or what the return value contains (e.g., file content, directory listing). This makes it inadequate for a tool with no structured safety or output information.

  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%, with clear descriptions for all parameters (owner, repo, path, branch). The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.

  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 ('获取' meaning 'get') and resource ('Gitee 仓库中文件或目录的内容' meaning 'contents of files or directories in a Gitee repository'), making the purpose immediately understandable. It doesn't explicitly differentiate from siblings like 'get_branch' or 'get_issue', but the resource focus (file/directory contents vs. branch/issue metadata) provides implicit distinction.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention related tools like 'get_branch' (for branch metadata) or 'create_or_update_file' (for modifying files), nor does it specify prerequisites such as needing repository access. Usage is implied only by the action and resource.

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

• get_pull_requestC
  2.9/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 only states the retrieval action without mentioning whether it's read-only, requires authentication, has rate limits, or what the return format includes. This is inadequate for a tool with no annotation coverage.

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

  Conciseness5/5

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

  The description is a single, efficient sentence in Chinese that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with zero wasted 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?

  Given the lack of annotations and output schema, the description is incomplete. It doesn't address behavioral aspects like authentication needs, error handling, or return structure, which are critical for a retrieval tool in a version control context with sibling tools.

  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 description coverage is 100%, with all three parameters clearly documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints, meeting the baseline for high schema coverage.

  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 ('获取' meaning 'get') and resource ('特定 Pull Request' meaning 'specific Pull Request'), specifying it retrieves a particular PR from a Gitee repository. However, it doesn't distinguish this tool from its sibling 'list_pull_requests' which likely lists multiple PRs, missing explicit differentiation.

  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 doesn't mention prerequisites like authentication, nor does it contrast with 'list_pull_requests' for bulk retrieval or 'update_pull_request' for modifications, leaving usage context implied.

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

• list_branchesC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('list') but doesn't describe behavioral traits such as pagination behavior (implied by 'page' and 'per_page' parameters but not explained), rate limits, authentication requirements, or what the output looks like. For a tool with 6 parameters and no annotation coverage, this leaves significant gaps in understanding how the tool behaves beyond basic functionality.

  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 in Chinese that directly states the tool's purpose without any fluff or redundancy. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place, and there's no wasted verbiage.

  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's complexity (6 parameters, no annotations, no output schema), the description is incomplete. It lacks information on behavioral aspects like pagination, output format, error handling, or authentication needs. While the schema covers parameter details, the description doesn't compensate for missing annotations or output schema, leaving gaps in understanding how to effectively use the tool in practice.

  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 description coverage is 100%, with all parameters well-documented in the schema (e.g., 'owner' as repository owner path, 'per_page' with maximum 100). The description adds no additional meaning beyond the schema, such as explaining parameter interactions or providing examples. According to guidelines, with high schema coverage (>80%), the baseline is 3 even without param info in the description, which fits here.

  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 ('列出' meaning 'list') and resource ('Gitee 仓库中的分支' meaning 'branches in Gitee repository'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'get_branch' (which retrieves a single branch), but the verb 'list' implies a collection operation. The description is specific enough to convey the core function without being tautological.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_branch' (for single branch details) or 'create_branch' (for creating new branches), nor does it specify prerequisites or contextual cues for selection. Usage is implied only by the tool name and description, with no explicit when/when-not instructions.

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

• merge_pull_requestC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. While '合并' implies a write/mutation operation, it doesn't mention permissions required, whether the merge is reversible, rate limits, or what happens on failure. This leaves significant gaps for an agent to understand the tool's behavior safely.

  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, clear sentence that directly states the tool's purpose without any fluff or redundant information. It's front-loaded and efficiently communicates the core function, making it easy for an agent to parse quickly.

  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 complexity of merging a pull request (a mutation with potential side effects like branch deletion), no annotations, and no output schema, the description is insufficient. It doesn't cover error conditions, return values, or important behavioral aspects like what 'merge' entails in Gitee's context, leaving the agent with incomplete context for safe invocation.

  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 description coverage is 100%, with all parameters well-documented in the schema itself (e.g., merge_method with enum values, prune_source_branch meaning). The description adds no additional parameter semantics beyond what's already in the schema, so it meets the baseline score of 3 for high schema coverage.

  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 ('合并' meaning 'merge') and the resource ('Gitee 仓库中的 Pull Request'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential alternatives like 'update_pull_request' or other PR-related tools in the sibling list, which would require explicit comparison.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'update_pull_request' and 'list_pull_requests' available, there's no indication of whether this is the primary method for merging PRs or if there are specific prerequisites (e.g., PR must be in a mergeable state).

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

• push_filesC
  2.9/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 the action ('提交' implying a write operation) but lacks critical details: it doesn't mention authentication requirements, potential side effects (e.g., overwriting existing files), error handling, rate limits, or what the tool returns (since no output schema exists). For a mutation tool with zero annotation coverage, this is a significant gap in 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 a single, efficient sentence in Chinese that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every part of the sentence earns its place by conveying essential information succinctly.

  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 complexity of a mutation tool (committing multiple files to a repository) with no annotations and no output schema, the description is incomplete. It lacks behavioral details (e.g., auth, side effects), usage guidelines, and return value information. While the schema covers parameters well, the overall context for safe and effective use is insufficient, especially compared to siblings that might handle similar operations.

  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 description coverage is 100%, meaning all parameters are documented in the input schema itself. The description adds no additional semantic context beyond the schema—it doesn't explain parameter interactions, default behaviors (e.g., branch defaults), or usage examples. Given the high schema coverage, a baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.

  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 ('提交' meaning 'submit' or 'commit') and resource ('多个文件' meaning 'multiple files' to 'Gitee仓库' meaning 'Gitee repository'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish itself from sibling tools like 'create_or_update_file' which might handle single files or different workflows, leaving some ambiguity in differentiation.

  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 offers no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication needs), compare to siblings like 'create_or_update_file' for single files or 'create_branch' for branch management, or specify scenarios (e.g., batch updates vs. individual edits). This lack of context makes it hard for an agent to choose appropriately among related tools.

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

• update_issueC
  2.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 full burden for behavioral disclosure. '更新' (update) implies a mutation operation, but the description doesn't disclose permissions required, whether partial updates are allowed, error conditions (e.g., invalid issue number), or what happens on success/failure. For a mutation tool with 9 parameters and no annotation coverage, this minimal description is inadequate.

  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 Chinese sentence ('更新 Gitee 仓库中的 Issue') that directly states the tool's function. There's zero wasted verbiage or unnecessary elaboration. It's appropriately sized for a tool with comprehensive schema documentation.

  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 this is a mutation tool with 9 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what happens when the tool succeeds (e.g., returns updated issue object), what error conditions exist, or how it interacts with the Gitee API. The combination of mutation complexity and lack of structured metadata requires more descriptive context than provided.

  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%, with all 9 parameters well-documented in the schema (e.g., assignees='Users assigned to the issue', state='Issue state' with enum values). The description adds no parameter information beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.

  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 '更新 Gitee 仓库中的 Issue' clearly states the action (update) and resource (Gitee repository issue) in Chinese. It distinguishes from siblings like create_issue (creation) and get_issue (retrieval), though it doesn't explicitly mention what aspects can be updated. The purpose is clear but could be more specific about the scope of updates.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing issue), when to choose update_issue over create_issue for modifications, or how it differs from update_pull_request. With multiple sibling tools for issue/pull request management, this lack of contextual guidance is a significant gap.

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

• list_pull_requestsB
  3.1/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but offers minimal behavioral insight. It doesn't mention pagination behavior (implied by 'page' and 'per_page' parameters), rate limits, authentication requirements, or whether it's read-only (though listing suggests it is). More context is needed for a mutation-heavy environment like Gitee.

  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, clear sentence in Chinese that directly states the tool's function without unnecessary words. It's front-loaded and wastes no space, making it highly efficient for an AI agent to parse.

  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 list operation with 9 parameters (2 required) and no output schema, the description is minimal but not fully complete. It lacks context on return format, pagination defaults, or error handling. However, the high schema coverage (100%) and read-only nature of listing mitigate some gaps, making it adequate but with clear room for improvement.

  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 parameters are well-documented in the schema itself. The description adds no additional parameter semantics beyond implying filtering/scoping (via '列出'), which the schema already covers with fields like 'state', 'labels', etc. Baseline 3 is appropriate when schema does the heavy lifting.

  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 ('列出' meaning 'list') and resource ('Pull Requests'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_pull_request' (singular) or 'list_issues', which would require explicit comparison for a score of 5.

  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 like 'get_pull_request' (for a specific PR) or 'list_issues' (for issues instead of PRs). The description only states what it does, not when it's appropriate.

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

• get_current_userB
  3.2/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. While it indicates this is a read operation ('获取'), it doesn't mention authentication requirements (though implied by '当前认证的'), rate limits, response format, or error conditions. For a tool with zero annotation coverage, this represents significant gaps in behavioral 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 a single, efficient sentence in Chinese that directly states the tool's purpose without any unnecessary words. It's appropriately sized for a simple tool with no parameters and gets straight to the point with zero wasted verbiage.

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

  Completeness3/5

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

  Given the tool's simplicity (no parameters, no output schema, no annotations), the description is minimally adequate. It tells the agent what the tool does but lacks important context about authentication requirements, response format, and differentiation from the similar 'get_user' tool. For a user information retrieval tool in an API context, more guidance would be helpful despite the tool's simple structure.

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

  Parameters4/5

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

  The tool has zero parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and it correctly indicates this tool requires no inputs to retrieve the current authenticated user's information.

  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 '获取当前认证的 Gitee 用户信息' clearly states the tool's purpose: retrieving information about the currently authenticated Gitee user. It specifies both the verb ('获取' - get/retrieve) and resource ('当前认证的 Gitee 用户信息' - current authenticated Gitee user information). However, it doesn't explicitly differentiate from its sibling 'get_user', which likely retrieves information about other users rather than the current authenticated one.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention the sibling 'get_user' tool or explain that this tool specifically returns information about the authenticated user making the request, while 'get_user' likely requires a username parameter to retrieve information about other users. No context about prerequisites or when-not-to-use scenarios is provided.

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