Server Quality Checklist

Tool Scores

• searchC
  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 states the tool performs a search but doesn't describe how results are returned (e.g., format, pagination), what happens on no matches, or any constraints (e.g., search scope, performance limits). For a search 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 that directly states the tool's function. It's front-loaded with the core action ('搜索' - search) and target ('Things'), with no unnecessary words. However, it could be slightly more structured by explicitly listing searchable item types instead of using '等' (etc.).

  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 search operation, lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the search returns (e.g., list of items, details), how results are formatted, or any behavioral aspects like error handling. For a tool that likely returns varied 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?

  The input schema has 100% description coverage, with the 'query' parameter documented as '搜索查询文本' (search query text). The description doesn't add any meaning beyond this, such as query syntax examples or supported search operators. With high schema coverage, the baseline score of 3 is appropriate, as the schema adequately handles parameter documentation.

  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 searches for '待办事项、项目等' (todos, projects, etc.) in Things, which provides a general purpose. However, it's vague about the exact scope ('等' means 'etc.') and doesn't clearly distinguish from sibling tools like 'show' or differentiate between searching todos vs. projects. It specifies the verb '搜索' (search) and target 'Things', but lacks precision.

  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 when to prefer 'search' over sibling tools like 'show' (which might display items) or how it complements other tools (e.g., 'add_todo', 'update_project'). The description implies a general search function but offers no context for selection among similar operations.

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

• add_projectC
  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 this creates a new project but doesn't mention required permissions, whether creation is reversible, what happens on success/failure, or any side effects. For a creation tool with 11 parameters and 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 immediately states the core purpose. It's appropriately sized and front-loaded with the main action. However, the list of supported fields could be more structured, and it lacks any separation between required and optional 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 project creation tool with 11 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what a 'project' represents in this system, how it differs from a 'todo', what happens after creation, or what the response contains. The agent lacks critical context for proper 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?

  Schema description coverage is 100%, so the schema already documents all 11 parameters thoroughly. The description lists some parameter categories (title, notes, area, tags, subtasks) but doesn't add meaningful semantics beyond what's in the schema. This meets 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 verb ('创建新的' - create new) and resource ('项目' - project), making the purpose explicit. It also lists supported fields (title, notes, area, tags, subtasks), which helps distinguish it from simpler creation tools. However, it doesn't explicitly differentiate from sibling tools like 'add_todo' or 'update_project'.

  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 prerequisites, when to choose 'add_project' over 'add_todo' or 'update_project', or any context about project lifecycle. 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.

• add_todoC
  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 tool creates new todos but doesn't mention any behavioral traits: no information about permissions required, whether creation is idempotent, error conditions, rate limits, or what happens on success (e.g., returns a todo ID). For a creation tool with 14 parameters and 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.

  Conciseness4/5

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

  The description is a single, efficient sentence that directly states the purpose and enumerates key parameters. It's appropriately sized and front-loaded with the core action. While it could be slightly more structured (e.g., separating purpose from parameter highlights), it avoids unnecessary verbiage and gets straight to the point.

  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 (14 parameters, creation operation) and lack of annotations or output schema, the description is incomplete. It doesn't address behavioral aspects like what the tool returns, error handling, or dependencies. For a tool that creates resources with many optional fields, more context is needed to use it effectively, especially without structured 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%, so the schema already documents all 14 parameters thoroughly. The description adds minimal value by listing some parameter names (title, notes, tags, etc.) but doesn't provide additional semantics beyond what's in the schema descriptions. This meets the baseline of 3 when schema coverage is high, but doesn't enhance parameter understanding.

  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 todo) and resource ('待办事项' - todo), which is specific and unambiguous. It lists supported fields (title, notes, tags, etc.), providing good detail about what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'update_todo' or 'delete_todo', 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. It doesn't mention sibling tools like 'update_todo' (for modifying existing todos) or 'delete_todo' (for removal), nor does it specify prerequisites or appropriate contexts. The agent must infer usage from the tool name alone, which is insufficient for optimal selection.

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

• delete_projectC
  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 tool marks projects as cancelled rather than physically deleting them, which is valuable behavioral context. However, it doesn't mention permissions needed beyond the auth token, whether the action is reversible, what happens to associated data, or any rate limits/constraints. For a destructive operation with zero annotation coverage, this leaves significant 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 extremely concise - just one sentence in Chinese that directly states the action, method, and required parameters. Every word earns its place with no wasted text. It's front-loaded with the core purpose immediately.

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

  Completeness2/5

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

  For a destructive operation with no annotations and no output schema, the description is incomplete. While it clarifies the 'mark as cancelled' behavior, it doesn't address what the tool returns, error conditions, side effects on related data, or permission requirements beyond the token. Given the complexity of a deletion operation, more contextual information 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?

  Schema description coverage is 100%, so the schema already fully documents both parameters (id and authToken). The description mentions both parameters by name but adds no additional semantic meaning beyond what's in the schema descriptions. The baseline of 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.

  Purpose4/5

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

  The description clearly states the action ('删除项目' - delete project) and specifies the method ('通过将其标记为已取消' - by marking it as cancelled). It distinguishes this from a physical deletion, which is helpful context. However, it doesn't explicitly differentiate from sibling tools like 'update_project' or 'delete_todo' in terms of when to use each.

  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 mentions that a project ID and authorization token are required, which provides basic prerequisites. However, it offers no guidance on when to use this tool versus alternatives like 'update_project' (which might have a status field) or other deletion tools. There's no explicit 'when' or 'when not' context provided.

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

• delete_todoC
  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. It mentions the action marks the todo as cancelled rather than permanent deletion, which is useful context. However, it lacks details on permissions needed, error handling, rate limits, or what happens if the ID doesn't exist. For a mutation tool with zero annotation coverage, this is insufficient.

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

  Conciseness5/5

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

  The description is a single, efficient sentence in Chinese that states the action, method, and required inputs. Every word serves a purpose with zero waste, making it appropriately concise and front-loaded.

  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 return values, error conditions, or behavioral constraints. While concise, it lacks necessary context for safe and 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?

  Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds no additional meaning about parameters beyond what's in the schema (e.g., no examples or format details). 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 ('删除待办事项') and resource ('待办事项'), specifying it works by marking as cancelled. It distinguishes from siblings like 'delete_project' by focusing on todos, but doesn't explicitly contrast with 'update_todo' which might also handle status changes.

  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 is provided. It doesn't mention when to choose 'delete_todo' over 'update_todo' for status changes, or prerequisites beyond the required parameters. The description only states what it does, not when to use it.

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

• json_importC
  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 performs imports (implying write operations) and supports complex nested structures, but fails to mention critical aspects like required permissions, error handling, rate limits, or whether it's idempotent. 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.

  Conciseness4/5

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

  The description is concise with two sentences that efficiently convey the core functionality and a key feature (support for complex nested structures). It's front-loaded with the main purpose, though it could be slightly more structured.

  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 lacks information about return values, error conditions, authentication requirements (beyond the authToken parameter), and how it differs from sibling tools. The mention of nested structures is helpful but insufficient.

  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 thoroughly. The description adds no additional parameter semantics beyond what's in the schema (e.g., no examples of nested structures or format details). 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 ('JSON批量导入' - JSON batch import) and target resources ('待办事项和项目' - to-dos and projects), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'add_project' or 'add_todo' that handle individual creations, though the batch nature is implied.

  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 'add_project' or 'add_todo'. It mentions support for complex nested structures, which hints at usage for bulk operations, but lacks explicit when/when-not instructions or named alternatives.

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

• showC
  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. It states the tool '显示' (displays) items, implying a read-only operation, but doesn't disclose behavioral traits like whether it requires authentication, how it handles errors, if it's idempotent, or what the output format is. For a tool with no annotations, 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, concise sentence that efficiently states the tool's purpose. It's front-loaded with the core action and resources, with no unnecessary words. However, it could be slightly more structured by explicitly mentioning the parameters or usage context.

  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 (3 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain how the tool behaves, what it returns, or how to use it effectively with siblings like 'search'. For a navigation/display tool with multiple parameters, more context is needed to ensure proper usage.

  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 description doesn't add any parameter-specific information beyond what's in the input schema, which has 100% description coverage. It mentions the types of items (areas, projects, tags, todos, built-in lists) that can be shown, but this doesn't clarify the semantics of the three parameters (id, query, filter). With high schema coverage, the baseline is 3, and the description doesn't compensate with additional insights.

  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: '导航到并显示区域、项目、标签、待办事项或内置列表' (Navigate to and display areas, projects, tags, todos, or built-in lists). It specifies the verb '显示' (display) and lists the resources it can show. However, it doesn't explicitly differentiate from sibling tools like 'search', 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 use 'show' versus 'search' (a sibling tool) or other tools like 'add_todo'. There's no context about prerequisites, exclusions, 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.

• update_projectC
  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 this is an update operation (implying mutation) and mentions auth token requirements, but doesn't describe what happens when fields are omitted (partial updates?), whether changes are reversible, error conditions, or what the tool returns. For a mutation tool with 15 parameters and 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 extremely concise with just one sentence in Chinese. It's front-loaded with the core purpose and immediately states the two required parameters. There's no wasted text, though some might argue it's too brief given the tool's complexity. Every word 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 mutation tool with 15 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what happens during updates, how partial updates work, what the tool returns, or error handling. The agent must rely entirely on the input schema without behavioral context, which is insufficient for safe and effective tool 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?

  Schema description coverage is 100%, so all parameters are documented in the schema itself. The description adds minimal value beyond the schema by emphasizing that project ID and auth token are required, but doesn't provide additional context about parameter interactions, constraints, or usage patterns. The baseline of 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 verb ('更新' meaning 'update') and resource ('现有的项目' meaning 'existing project'), making the purpose immediately understandable. It distinguishes itself from siblings like 'add_project' by specifying it updates existing projects rather than creating new ones. However, it doesn't explicitly differentiate from 'update_todo' which might be a similar update operation for different resources.

  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 'update_todo' or 'add_project'. It mentions the required parameters (project ID and auth token) but doesn't explain prerequisites, use cases, or when other tools might be more appropriate. The agent receives no contextual decision-making help.

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

• update_todoC
  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 requirements (auth token) which is valuable, but doesn't describe important behavioral aspects: whether this is a partial or complete update, what happens to unspecified fields, whether the operation is idempotent, error conditions, or what the response contains. For a mutation tool with 16 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 that states the core purpose and mentions two key parameters. There's no wasted language, though it could be slightly more informative given the tool's complexity. It's appropriately sized for a basic description.

  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 16 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns, error conditions, field update behaviors (replace vs append), or how it differs from similar tools. The agent would struggle to use this effectively without trial and error.

  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 16 parameters thoroughly. The description mentions two parameters (id and authToken) but doesn't add meaningful semantic context beyond what's in the schema. The baseline of 3 is appropriate when the schema does the heavy lifting, though the description could have explained parameter interactions (e.g., notes vs prependNotes vs appendNotes).

  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 ('更新' - update) and resource ('现有的待办事项' - existing todo item). It specifies the verb+resource combination effectively. However, it doesn't differentiate from sibling tools like 'update_project' or explain what distinguishes updating a todo from updating a project.

  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 'add_todo' or 'update_project'. It mentions required parameters (ID and auth token) but doesn't explain use cases, prerequisites, or when this tool is appropriate versus other mutation tools in the sibling set.

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

• get_versionB
  3.2/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 tool retrieves version info but doesn't describe traits like whether it's read-only (implied by 'get'), requires authentication, has rate limits, returns structured data, or handles errors. 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.

  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 unnecessary details. It's appropriately sized and front-loaded, with every word contributing to clarity, making it highly concise and well-structured.

  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 low complexity (0 parameters, no output schema, no annotations), the description is minimally adequate. It explains what the tool does but lacks details on behavioral traits, output format, or usage context. With no output schema, it should ideally hint at return values, but for a simple version check, it's just sufficient to avoid being incomplete.

  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 0 parameters, and schema description coverage is 100% (as there are no parameters to describe). The description doesn't need to add parameter semantics, so it meets the baseline of 4 for tools with no parameters, as it doesn't introduce confusion or redundancy.

  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: '获取Things应用和URL Scheme的版本信息' translates to 'Get version information for the Things application and URL Scheme.' It specifies the verb ('get') and resource ('version information'), and distinguishes it from siblings by focusing on version retrieval rather than project/todo management or search operations. However, it doesn't explicitly differentiate from hypothetical sibling tools like 'get_status' or 'get_config,' keeping it at a 4 rather than a 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 prerequisites (e.g., needing app access), exclusions (e.g., not for operational data), or direct comparisons to siblings like 'show' (which might display other info). Usage is implied only by the purpose, with no explicit context for selection.

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