Server Quality Checklist

Tool Scores

• create_tableC
  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. While '创建新表' (create new table) implies a write/mutation operation, the description doesn't disclose permissions needed, whether the operation is reversible, potential side effects, error conditions, or what happens on success/failure. For a database mutation tool with zero 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.

  Conciseness5/5

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

  The description is extremely concise - a single sentence in Chinese that directly states the tool's purpose. There's zero waste or unnecessary elaboration. It's appropriately sized for a simple tool with one parameter.

  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 database mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after table creation, what gets returned, error handling, or behavioral constraints. Given the complexity of database operations and the lack of structured metadata, the description should provide more complete context about the tool's behavior and outcomes.

  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 the single 'query' parameter as '要执行的 SQL CREATE TABLE 语句' (SQL CREATE TABLE statement to execute). The description doesn't add any additional parameter semantics beyond what's in the schema. With high schema coverage, baseline 3 is appropriate when the description 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 table) and resource ('在 MySQL 数据库中' - in MySQL database), providing specific verb+resource. However, it doesn't distinguish this from sibling tools like 'execute_sql' or 'run_sql_query' which could also potentially create tables, so it doesn't fully differentiate from 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 like 'execute_sql' or 'run_sql_query'. There's no mention of prerequisites, when-not-to-use scenarios, or explicit alternatives. The agent must infer usage context 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.

• delete_dataC
  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 '删除数据' clearly indicates a destructive operation, it doesn't specify permissions required, whether deletions are reversible, transaction behavior, error handling, or what happens on success/failure. For a destructive tool with zero 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.

  Conciseness5/5

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

  The description is a single, efficient Chinese sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple tool with one parameter 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?

  For a destructive database operation with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after deletion, return values, error conditions, or safety considerations. Given the high-risk nature of data deletion and lack of structured metadata, more contextual information is needed.

  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 the single 'query' parameter as a SQL DELETE FROM statement. The description adds no additional parameter semantics beyond what's in the schema. 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 ('删除数据' - delete data) and target resource ('从 MySQL 数据库表中' - from MySQL database table). It distinguishes from siblings like insert_data and update_data by specifying deletion. However, it doesn't explicitly differentiate from execute_sql or run_sql_query which could also perform deletions.

  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 execute_sql or run_sql_query. It doesn't mention prerequisites, when-not-to-use scenarios, or compare functionality with sibling tools. 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.

• insert_dataC
  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 insert operation but reveals nothing about permissions required, whether it's idempotent, what happens on constraint violations, transaction behavior, or what the response contains. For a database mutation tool with zero annotation coverage, this leaves critical behavioral aspects unspecified.

  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 states the core purpose without unnecessary words. It's appropriately sized for a simple tool and front-loads the essential information. Every word earns its place in conveying the tool's function.

  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 database mutation tool with no annotations, no output schema, and multiple similar siblings, the description is incomplete. It doesn't address critical context like error handling, return values, transaction boundaries, or differentiation from other SQL tools. The agent lacks sufficient information to use this tool effectively in complex scenarios.

  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 single parameter 'query' documented as '要执行的 SQL INSERT INTO 语句' (SQL INSERT INTO statement to execute). The description adds no additional parameter context beyond what the schema already provides. With high schema coverage, the baseline score of 3 is appropriate - the description doesn't enhance parameter understanding but doesn't need to compensate for schema gaps.

  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 ('插入数据' - insert data) and target resource ('向 MySQL 数据库表' - to MySQL database table), making the purpose immediately understandable. It doesn't explicitly distinguish from siblings like 'update_data' or 'delete_data', but the verb 'insert' provides inherent differentiation. This is better than vague but lacks explicit sibling 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 'update_data', 'delete_data', or 'execute_sql'. There's no mention of prerequisites, appropriate contexts, or exclusions. The agent must infer usage from the tool name alone, which is insufficient given multiple SQL-related siblings.

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

• update_dataC
  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 updates data, implying a mutation operation, but does not disclose critical traits such as whether it requires specific database permissions, if changes are reversible, potential side effects on related data, or error handling. 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, concise sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and efficiently communicates the core functionality, making it easy to understand at a glance while avoiding redundancy or fluff.

  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 insufficient. It does not explain what the tool returns (e.g., success status, affected rows), error conditions, or behavioral nuances like transaction handling. Given the complexity of database updates and the lack of structured data, more context is needed to ensure safe and 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 clearly documented as '要执行的 SQL UPDATE 语句' (the SQL UPDATE statement to execute). The description does not add any meaning beyond what the schema provides, as it only reiterates the general purpose without detailing parameter usage or constraints. Given the high schema coverage, a 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 action ('更新' meaning 'update') and the target resource ('MySQL 数据库表中的数据' meaning 'data in MySQL database tables'), providing a specific verb+resource combination. However, it does not distinguish this tool from its sibling 'execute_sql' or 'run_sql_query', which could also potentially update data, leaving some ambiguity about its unique role.

  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 'execute_sql' or 'delete_data'. It lacks explicit instructions on prerequisites, such as requiring a valid SQL UPDATE statement, or context for when it is appropriate compared to other data manipulation tools in the sibling list.

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

• run_sql_queryA
  3.7/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the tool is read-only and limited to SELECT statements, which is helpful context. However, it lacks details on potential behavioral traits like error handling, result formatting, timeouts, or authentication requirements, leaving gaps for an AI agent.

  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 and front-loaded with a single sentence in Chinese that directly states the tool's function and limitations. There is no wasted text, and every word earns its place by clarifying the scope (read-only, SELECT-only).

  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 complexity (SQL execution), lack of annotations, and no output schema, the description is minimally adequate. It covers the basic purpose and restrictions but misses details like return format, error cases, or performance considerations. For a tool with no structured output documentation, more context would be beneficial.

  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 '要执行的 SQL SELECT 查询语句' (SQL SELECT query statement to execute). The description doesn't add any additional meaning beyond what the schema provides, such as syntax examples or constraints. Given the high schema coverage, a 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 as '执行只读 SQL 查询（仅限 SELECT 语句）', which translates to 'execute read-only SQL queries (only SELECT statements)'. This specifies both the verb ('execute') and resource ('SQL queries') with a clear restriction to SELECT statements. However, it doesn't explicitly differentiate from sibling tools like 'execute_sql', which might handle other SQL operations.

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

  Usage Guidelines4/5

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

  The description provides clear context for when to use this tool by specifying '只读' (read-only) and '仅限 SELECT 语句' (only SELECT statements). This implicitly guides usage for read operations versus siblings like 'insert_data' or 'update_data' for writes. However, it doesn't explicitly name alternatives or state when not to use it, such as for non-SELECT queries.

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

• execute_sqlA
  3.8/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 it indicates this executes SQL statements (implying write/mutation operations), it doesn't disclose important behavioral traits like authentication requirements, transaction handling, error behavior, or whether changes are reversible. For a tool that can execute destructive operations like DROP, 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 (one sentence) and front-loaded with all essential information. Every word earns its place by specifying the tool's scope (non-SELECT SQL), providing examples, and distinguishing from alternatives. There's zero waste or redundancy.

  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 that can execute potentially destructive SQL operations (DROP, ALTER TABLE) with no annotations and no output schema, the description is incomplete. It doesn't address critical context like what permissions are required, whether transactions are supported, what happens on errors, or what the return format looks like. The description does well on purpose and usage but misses important behavioral context.

  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 single 'query' parameter well-documented in the schema. The description doesn't add any meaningful parameter semantics beyond what the schema already provides ('要执行的 SQL 语句'). The baseline score of 3 is appropriate when the schema does the heavy lifting for parameter documentation.

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

  Purpose5/5

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

  The description clearly states the tool's purpose with specific verbs ('执行任意非 SELECT 的 SQL 语句') and resources (SQL statements like ALTER TABLE, DROP). It explicitly distinguishes from SELECT operations, which helps differentiate from sibling tools like 'run_sql_query' that likely handles SELECT queries.

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

  Usage Guidelines5/5

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

  The description provides explicit usage guidelines by stating '非 SELECT 的 SQL 语句' (non-SELECT SQL statements) and giving examples like ALTER TABLE and DROP. This clearly indicates when to use this tool versus alternatives like 'run_sql_query' (likely for SELECT) and other siblings that handle specific operations (create_table, delete_data, etc.).

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