Server Quality Checklist

Tool Scores

• create_docC
  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 mentions support for multiple formats but doesn't cover critical aspects like required permissions, rate limits, error handling, or what happens on success (e.g., returns a document ID). For a creation 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.

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the core purpose ('创建新的语雀文档') and adds useful context about format support. Every word earns its place with no redundancy or 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 tool's complexity (7 parameters, creation operation) and lack of both annotations and output schema, the description is insufficient. It doesn't explain return values, error conditions, or behavioral nuances, leaving the agent under-informed for a mutation tool with multiple inputs.

  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 7 parameters thoroughly. The description adds minimal value beyond the schema, only implying that 'format' supports multiple types without specifying details. 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 ('创建新的语雀文档' - create new Yuque document) and resource ('在指定知识库中' - in specified knowledge base), specifying it supports multiple content formats. It distinguishes from siblings like 'update_doc' or 'delete_doc' by focusing on creation, though it doesn't explicitly contrast with 'get_doc' operations.

  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 a valid namespace or authentication), nor does it contrast with sibling tools like 'update_doc' for modifications or 'get_repo_docs' for listing documents.

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

• get_current_userC
  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 authentication ('当前认证用户') which aligns with the accessToken parameter, but doesn't describe what happens without authentication, rate limits, error conditions, or response format. For a tool with authentication requirements and 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 that front-loads the core purpose. It wastes no words and directly communicates what the tool does. However, it could be slightly more structured by separating authentication requirements from returned data.

  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 moderate complexity (authentication required, returns user data), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose and data returned but lacks details about authentication flow, error handling, and response structure that would be helpful for an 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% with one parameter (accessToken) fully documented in the schema. The description adds minimal value beyond the schema by implying authentication context ('当前认证用户'), but doesn't provide additional syntax, format, or usage details for the parameter. 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 tool's purpose: '获取当前认证用户的信息' (get current authenticated user information) with specific resources listed (user ID, username, avatar, basic Yuque account information). It distinguishes from siblings by focusing on current user data rather than documents, groups, or repositories. However, it doesn't explicitly contrast with potential similar tools like 'get_user_docs'.

  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 this tool is appropriate compared to other user-related tools (like 'get_user_docs' or 'get_user_repos'), nor does it specify prerequisites or context requirements beyond the implied authentication.

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

• get_docC
  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 that the tool retrieves detailed content and supports chunking for large documents, which adds some context. However, it lacks critical details like authentication requirements (implied by 'accessToken' parameter but not stated), rate limits, error conditions, or what happens if chunk parameters are omitted. For a tool with 5 parameters and no annotations, this is insufficient.

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

  Conciseness4/5

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

  The description is a single, efficient sentence in Chinese that front-loads the core purpose and includes key features (chunking support). It avoids redundancy and wastes no words, though it could be slightly more structured for clarity.

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

  Completeness2/5

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

  Given the tool's complexity (5 parameters, no annotations, no output schema), the description is incomplete. It covers the basic purpose and chunking but misses authentication needs, error handling, output format details, and differentiation from siblings. For a tool that retrieves detailed document data, more context is needed to guide effective 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%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema: it implies the tool handles large documents via chunking, which relates to 'chunk_index' and 'chunk_size', but doesn't provide additional syntax or format details. Baseline 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 tool's purpose: '获取语雀中特定文档的详细内容，包括正文、修改历史和权限信息' (retrieve detailed content of a specific document in Yuque, including body, revision history, and permission information). It specifies the resource (document in Yuque) and what content is retrieved, though it doesn't explicitly distinguish from siblings like 'get_doc_chunks_info' or 'get_repo_docs' beyond mentioning chunking support.

  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 mentions chunking for large documents but doesn't clarify when to use 'get_doc' vs. 'get_doc_chunks_info' for chunk-related operations or 'get_repo_docs' for listing documents. No explicit when/when-not or alternative tool references are included.

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

• get_doc_chunks_infoC
  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 retrieves metadata (implying read-only), but doesn't disclose behavioral traits like authentication requirements (implied by 'accessToken' parameter but not described), rate limits, error conditions, or whether it's idempotent. For a tool with no annotations, 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.

  Conciseness4/5

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

  The description is a single, efficient sentence in Chinese that front-loads the core purpose. It avoids unnecessary words, though it could be slightly more structured (e.g., separating purpose from details). Every part earns its place, making it appropriately concise.

  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 no annotations and no output schema, the description is incomplete. It doesn't explain the return format (e.g., structure of metadata), error handling, or dependencies like authentication. For a tool with 4 parameters and no structured output, more context is needed to guide effective 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%, so the schema already documents all parameters. The description doesn't add meaning beyond the schema, such as explaining relationships between parameters (e.g., how 'namespace' and 'slug' identify a document) or usage examples. Baseline 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 ('获取' - get/retrieve) and the resource ('文档的分块元信息' - document chunk metadata), specifying what information is returned (total chunks, character count per chunk). It distinguishes from siblings like 'get_doc' (full document) and 'search' (search functionality), though not explicitly named. The purpose is specific but could be more precise about 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. It doesn't mention prerequisites (e.g., needing an existing document), exclusions, or comparisons to siblings like 'get_doc' (for full content) or 'get_repo_docs' (for listing). The description implies usage for metadata analysis but lacks explicit context.

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

• get_group_book_statisticsC
  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 mentions statistics retrieval but doesn't disclose behavioral traits like pagination behavior (implied by page/limit parameters), authentication requirements (accessToken parameter), rate limits, error conditions, or what happens when no data matches. For a read operation with 8 parameters, this is insufficient disclosure.

  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 that clearly states the tool's purpose with relevant examples. It's front-loaded with the main function and wastes no words. Every element earns its place.

  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 8 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain the return format, pagination behavior, authentication requirements, or error handling. While the schema covers parameter definitions, the description fails to provide necessary context for proper tool invocation and result interpretation.

  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 8 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema. It mentions general statistics types but doesn't explain how parameters like 'range' or 'sortField' affect which statistics are returned. Baseline 3 is appropriate when schema does all the work.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: '获取团队知识库的统计数据' (get team knowledge base statistics) with specific examples of metrics like document count, word count, and read count. It distinguishes from siblings like get_group_doc_statistics (doc-specific) and get_group_statistics (general group stats) by focusing on knowledge base-level metrics. However, it doesn't explicitly name the sibling tools for 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 like get_group_doc_statistics or get_group_statistics. It doesn't mention prerequisites, exclusions, or typical use cases. The agent must infer usage from the tool name and parameters alone.

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

• get_group_doc_statisticsC
  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 mentions the types of statistics returned but doesn't disclose critical traits like whether this is a read-only operation (implied by 'get'), authentication requirements (only hinted via accessToken parameter), rate limits, pagination behavior (implied by page/limit parameters), or what happens with invalid inputs. For a tool with 9 parameters and no annotation coverage, this 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.

  Conciseness4/5

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

  The description is a single, efficient sentence in Chinese that front-loads the core purpose. It wastes no words but could be slightly more structured (e.g., separating purpose from data details). Every part earns its place, though it might benefit from brevity in English contexts.

  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 high complexity (9 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the return format (e.g., list of documents with stats?), error conditions, authentication needs beyond the accessToken parameter, or how to interpret results. For a statistical query tool with multiple filters and sorting options, more context is needed to guide effective 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%, providing detailed documentation for all 9 parameters including enums and defaults. The description adds no parameter-specific semantics beyond implying statistics include 'word count, read count, comment count' which loosely relates to sortField options. It doesn't explain parameter interactions (e.g., how bookId, name, and range combine) or provide examples. Baseline 3 is appropriate since the schema does 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 verb ('获取' meaning 'get') and resource ('团队文档的统计数据' meaning 'team document statistics'), specifying what data is included (word count, read count, comment count, etc.). It distinguishes from siblings like get_doc (single document) or get_group_statistics (general group stats) by focusing on document-level metrics. However, it doesn't explicitly differentiate from get_group_book_statistics or get_repo_docs, which might overlap in scope.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like get_group_book_statistics (for book-level stats), get_doc (for single document details), or get_repo_docs (for document listings). It lacks context about prerequisites (e.g., needing team access) or exclusions (e.g., not for user-specific docs). Usage is implied only by the name and parameters, with no explicit instructions.

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

• get_group_member_statisticsC
  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 describes a read operation ('获取' - get) but doesn't mention authentication requirements (though 'accessToken' is in the schema), rate limits, pagination behavior (implied by 'page' and 'limit' but not explained), or what happens on errors. For a tool with 8 parameters and no 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 that front-loads the core purpose. It avoids redundancy and wastes no words, though it could be slightly more structured (e.g., by explicitly listing key metrics). Every part earns its place by specifying what statistics are included.

  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 (8 parameters, no annotations, no output schema), the description is incomplete. It lacks details on authentication, pagination, error handling, and output format (e.g., what data is returned beyond the mentioned metrics). Without annotations or an output schema, the description should compensate more to guide effective 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%, so the schema fully documents all 8 parameters with descriptions, enums, and defaults. The description adds no additional parameter semantics beyond implying statistics include '编辑次数、阅读量、点赞量等' (edit count, read count, like count, etc.), which loosely relates to 'sortField' options but doesn't clarify parameter usage or interactions. Baseline 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 tool's purpose: '获取团队成员的统计数据，包括各成员的编辑次数、阅读量、点赞量等' (Get team member statistics, including each member's edit count, read count, like count, etc.). It specifies the verb ('获取' - get) and resource ('团队成员统计数据' - team member statistics) with concrete examples of metrics. However, it doesn't explicitly differentiate from sibling tools like 'get_group_statistics' or 'get_group_doc_statistics', which appear related.

  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_group_statistics' or 'get_group_doc_statistics', nor does it specify prerequisites (e.g., needing an access token) or exclusions. Usage is implied by the purpose but lacks explicit context for selection among similar tools.

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

• get_group_statisticsC
  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 this is a read operation ('获取' - get/retrieve) which implies non-destructive behavior, but doesn't disclose authentication requirements (though the schema shows accessToken parameter), rate limits, error conditions, or what happens if the team doesn't exist. For a tool with no 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.

  Conciseness4/5

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

  The description is a single, efficient sentence that states the purpose and enumerates key metrics. It's appropriately sized for a read operation with clear parameters. Every element serves a purpose, though it could be slightly more structured by separating purpose from metric examples.

  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 read-only statistics tool with 100% schema coverage but no output schema, the description adequately covers what metrics are returned. However, without annotations and with multiple sibling tools offering similar functionality, it should provide more context about when to choose this comprehensive tool versus more specific alternatives. The lack of output schema means the description should ideally hint at return format.

  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 both parameters (login and accessToken) with descriptions. The tool description adds no parameter-specific information beyond what's in the schema. With complete schema coverage, the baseline is 3 even without additional 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 tool's purpose: '获取团队的汇总统计数据' (get team summary statistics) and lists specific metrics like member count, document count, reading volume, and interaction data. It distinguishes from siblings like get_group_book_statistics or get_group_member_statistics by covering multiple aggregated metrics rather than specific subsets. However, it doesn't explicitly name the sibling tools for 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 siblings like get_group_book_statistics, get_group_doc_statistics, and get_group_member_statistics that retrieve specific subsets of statistics, there's no indication of when this comprehensive tool is preferred over those more targeted tools. No prerequisites or exclusions are mentioned.

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

• update_docC
  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 this is an update operation ('更新'), implying mutation, but doesn't disclose behavioral traits like authentication requirements (though accessToken parameter hints at this), rate limits, whether changes are reversible, what happens to unspecified fields, or error conditions. 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.

  Conciseness4/5

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

  The description is a single, efficient sentence in Chinese that front-loads the core purpose. It wastes no words but could be slightly more structured (e.g., separating scope from modifiable fields). Every part earns its place, making it appropriately concise.

  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 8 parameters, no annotations, and no output schema, the description is incomplete. It doesn't cover authentication needs (implied by accessToken but not stated), response format, error handling, or behavioral constraints. For a tool of this complexity with no structured safety hints, the description should provide more contextual guidance.

  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 8 parameters thoroughly. The description mentions '标题、内容或权限设置' (title, content, or permission settings), which maps to title, body, and public parameters, but adds no additional semantic context beyond what the schema provides. With high schema coverage, baseline 3 is appropriate.

  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 verb ('更新' meaning 'update') and resource ('语雀中已存在的文档' meaning 'existing documents in Yuque'), and specifies what can be modified ('标题、内容或权限设置' meaning 'title, content, or permission settings'). It distinguishes from create_doc by specifying '已存在的' (existing), but doesn't explicitly differentiate from other update operations if they exist.

  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 create_doc or delete_doc. It doesn't mention prerequisites (e.g., needing an existing document ID) or contextual constraints (e.g., user permissions). The only implied usage is for updating existing documents, but no explicit alternatives or exclusions are stated.

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

• get_repo_docsB
  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 the full burden of behavioral disclosure. It mentions returning '文档标题、更新时间等信息' (document titles, update times, and other information), which hints at a read-only list operation, but doesn't specify whether this is paginated, rate-limited, requires authentication (though the schema shows an optional accessToken), or what 'other information' includes. For a 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 that front-loads the core purpose ('获取特定知识库中的所有文档列表' - get all documents in a specific knowledge base) and adds useful detail ('包括文档标题、更新时间等信息' - including document titles, update times, and other information). Every word earns its place with zero redundancy or waste.

  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 moderate complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and return data types but lacks details on authentication behavior, error handling, pagination, or sibling differentiation. Without annotations or output schema, the description should do more to compensate, but it meets the bare minimum for a read-only list 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?

  The schema description coverage is 100%, with both parameters ('namespace' and 'accessToken') fully described in the schema. The description adds no additional parameter semantics beyond implying the tool operates on a '特定知识库' (specific knowledge base), which aligns with the 'namespace' parameter. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but doesn't detract either.

  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 verb ('获取' - get/retrieve) and resource ('特定知识库中的所有文档列表' - all documents in a specific knowledge base), making the purpose unambiguous. It distinguishes from siblings like 'get_doc' (single document) and 'get_user_docs' (user-specific documents) by specifying 'all documents in a specific knowledge base'. However, it doesn't explicitly contrast with 'get_user_repos' or 'search', which slightly limits 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 when to choose 'get_repo_docs' over 'get_user_docs' (for user-specific docs) or 'search' (for filtered queries), nor does it indicate prerequisites like authentication needs. The lack of usage context leaves the agent to infer from tool names alone.

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

• get_user_reposB
  3.1/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 states the tool retrieves a list but doesn't disclose behavioral traits like pagination, rate limits, error handling, or whether it requires authentication (though the accessToken parameter hints at this). For a read operation with no annotation coverage, this leaves significant gaps in understanding how the tool behaves.

  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 core purpose. It wastes no words and is appropriately sized for a simple list-retrieval tool, making it easy for an AI agent to parse quickly.

  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 moderate complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It explains what the tool does but lacks details on behavior, output format, or usage context. Without annotations or an output schema, more completeness would be helpful, but it meets the bare minimum for a read 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?

  The schema description coverage is 100%, with both parameters (login and accessToken) fully described in the schema. The description adds no additional meaning beyond what the schema provides, such as explaining the format of login or when accessToken is required. Since the schema does the heavy lifting, 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.

  Purpose4/5

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

  The description clearly states the tool's purpose: '获取指定用户的知识库列表' (get a specified user's repository list), specifying the verb '获取' (get) and resource '知识库列表' (repository list). It distinguishes from siblings like get_user_docs (which gets documents) by focusing on repositories. However, it doesn't explicitly differentiate from get_repo_docs (which gets docs within a repo), so it's not a perfect 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?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use get_user_repos instead of get_user_docs or get_repo_docs, nor does it specify prerequisites like authentication requirements. The context is implied but not explicit.

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

• searchB
  3.1/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. The description mentions filtering capabilities but doesn't disclose important behavioral traits like whether this is a read-only operation (implied but not stated), whether it requires authentication (implied by the accessToken parameter but not explicitly stated), pagination behavior (implied by the page parameter but not explained), rate limits, or what the response format looks like. For a search tool with 6 parameters and no annotations, 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.

  Conciseness4/5

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

  The description is a single, efficient Chinese sentence that states the core purpose and key capabilities. It's appropriately sized and front-loaded with the main function. However, it could be slightly more structured by separating purpose from features for better readability.

  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, search functionality) and the absence of both annotations and an output schema, the description is incomplete. It doesn't explain what the tool returns (search results format), authentication requirements, pagination behavior, or error conditions. For a search tool with no structured output documentation, the description should provide more context about the expected response.

  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 6 parameters thoroughly. The description adds minimal value beyond the schema by mentioning '范围和作者筛选' (scope and author filtering), which corresponds to the 'scope' and 'creator' parameters, but doesn't provide additional semantic context beyond what's in the schema descriptions. With high schema coverage, the baseline is 3 even without parameter 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 tool's purpose: '在语雀平台中搜索文档或知识库内容' (search for documents or knowledge base content in the Yuque platform). It specifies the verb '搜索' (search) and resources '文档或知识库内容' (documents or knowledge base content). However, it doesn't explicitly distinguish this from sibling tools like 'get_doc' or 'get_repo_docs', which appear to be retrieval tools rather than search tools.

  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 provides some implied usage context by mentioning '支持范围和作者筛选' (supports scope and author filtering), suggesting this tool is for filtered searches. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_doc' (which likely retrieves specific documents) or 'get_user_docs' (which likely lists user documents without search). No explicit when-not-to-use guidance or named alternatives are provided.

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

• get_user_docsB
  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 full burden. It states what the tool does but lacks behavioral details: it doesn't mention pagination, rate limits, sorting, what fields are returned, error conditions, or whether this is a read-only operation. The description is functional but misses important operational context.

  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?

  Single sentence in Chinese that efficiently conveys the core functionality. No wasted words, appropriately front-loaded with the main purpose. Every word earns its place in this compact description.

  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 retrieval tool with 1 parameter (100% schema coverage) but no annotations and no output schema, the description is minimally adequate. It covers what the tool does but lacks important context about return format, pagination, and operational constraints. The absence of output schema means the description should ideally mention something about the response structure.

  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 one parameter (accessToken) fully documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema. With high schema coverage, the baseline is 3 even without additional 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 verb ('获取' - get/retrieve) and resource ('所有知识库文档列表' - all knowledge base document list) with scope ('当前用户' - current user, '包括私人和协作文档' - including private and collaborative documents). It distinguishes from siblings like get_doc (single document) and get_repo_docs (repository-specific), but doesn't explicitly mention these distinctions.

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

  Usage Guidelines3/5

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

  The description implies usage context ('当前用户' - current user) but doesn't explicitly state when to use this tool versus alternatives like get_repo_docs (repository-focused) or search (filtered search). No exclusions or prerequisites are mentioned, though the accessToken parameter suggests authentication is required.

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

• delete_docA
  3.9/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the tool performs a deletion and that it's irreversible ('此操作不可撤销'), which is critical behavioral information. However, it does not mention authentication requirements, rate limits, or error handling, leaving some 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 that front-loads the key information: the action, resource, and critical warning about irreversibility. Every word earns its place with no redundancy or unnecessary details.

  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 destructive tool with no annotations and no output schema, the description is moderately complete. It covers the core purpose and irreversible nature but lacks details on authentication (implied by 'accessToken' in schema), response format, or error scenarios. Given the complexity, it should provide more behavioral context to be fully adequate.

  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 three parameters ('namespace', 'id', 'accessToken') with descriptions. The description does not add any additional meaning or context beyond what the schema provides, such as format examples or usage tips, meeting the baseline for high coverage.

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

  Purpose5/5

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

  The description clearly states the action ('删除' meaning 'delete'), the resource ('文档' meaning 'document'), and the system context ('从语雀知识库中' meaning 'from Yuque knowledge base'). It distinguishes from siblings like 'create_doc', 'update_doc', and 'get_doc' by specifying the destructive delete operation.

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

  Usage Guidelines3/5

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

  The description implies usage for deleting documents in Yuque, but does not explicitly state when to use this tool versus alternatives (e.g., 'update_doc' for modifications or 'get_doc' for retrieval). It mentions the operation is irreversible, which provides some contextual guidance but lacks explicit comparisons or prerequisites.

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