Server Quality Checklist

Tool Scores

• describe_tableC
  2.7/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. 'Get table structure' implies a read-only operation, but it doesn't specify if this requires authentication, has rate limits, returns detailed metadata (e.g., column types, indexes), or handles errors (e.g., for non-existent tables). For a tool with zero annotation coverage, this is a significant gap in describing behavior beyond basic purpose.

  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 'Get table structure' is extremely concise and front-loaded, consisting of just three words that directly convey the tool's purpose. There is no wasted language or unnecessary elaboration, making it efficient and easy to parse for an AI agent.

  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 (a read operation with one parameter) and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'structure' includes (e.g., schema details), potential outputs, or behavioral aspects like error handling. For a tool that likely returns metadata, more context is needed to guide the agent effectively.

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

  Parameters3/5

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

  The input schema has 100% description coverage, with the 'table' parameter clearly documented as 'Table name'. The description adds no additional meaning beyond this, such as format examples (e.g., case sensitivity) or constraints. With high schema coverage, the baseline score of 3 is appropriate, as 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.

  Purpose3/5

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

  The description 'Get table structure' states a clear verb ('Get') and resource ('table structure'), but it's vague about what 'structure' entails (e.g., columns, types, constraints). It doesn't differentiate from sibling tools like 'list_tables' or 'query', which might also provide structural information. This is adequate but lacks specificity and sibling distinction.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., after connecting to the database with 'connect_db'), differentiate from 'list_tables' (which might list names only) or 'query' (which might retrieve data), or specify use cases like schema inspection. This leaves the agent without contextual usage cues.

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

• queryC
  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. 'Execute a SELECT query' implies a read-only operation, but it doesn't specify permissions required, potential side effects (e.g., read locks), rate limits, or error handling. This is a significant gap for a database query tool with zero annotation coverage.

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

  Conciseness5/5

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

  The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, clearly stating the core action without unnecessary elaboration.

  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 database queries and the lack of annotations and output schema, the description is incomplete. It doesn't address return values, error cases, or behavioral traits, which are crucial for an agent to use this tool effectively in a database 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?

  The schema description coverage is 100%, so the input schema already documents both parameters (sql and params) adequately. The description doesn't add any meaning beyond what the schema provides, such as SQL dialect or param usage examples. 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 'Execute a SELECT query' clearly states the verb ('Execute') and resource ('SELECT query'), making the purpose understandable. However, it doesn't differentiate from potential siblings like 'describe_table' or 'list_tables' that might also involve database operations, so it's not fully specific about when to use this versus those 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 the sibling tools (connect_db, describe_table, list_tables). It doesn't mention alternatives, prerequisites, or exclusions, leaving the agent to 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.

• list_tablesB
  3.1/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits like whether this requires database connection, returns paginated results, includes system tables, or has performance implications.

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

  Conciseness5/5

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

  The description is a single, clear sentence with no wasted words. It's front-loaded with the essential information and earns its place efficiently.

  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 listing tool with no annotations and no output schema, the description is insufficient. It doesn't explain what information is returned (table names only? metadata?), format, or any constraints, leaving significant gaps for an agent.

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

  Parameters4/5

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

  The tool has zero required parameters (one dummy parameter with 100% schema coverage). The description appropriately doesn't discuss parameters since none are needed for the core functionality, though it could mention the dummy parameter is optional.

  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 ('List') and resource ('all tables in the database'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'describe_table' or 'query', which prevents 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?

  No guidance is provided on when to use this tool versus alternatives like 'describe_table' (for table details) or 'query' (for executing SQL). The description only states what it does, not when it's appropriate.

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

• connect_dbB
  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 mentions the optionality based on environment variables, which adds some context, but fails to describe critical behaviors such as what happens on successful/failed connections, whether the connection persists, authentication requirements beyond parameters, or any rate limits. For a tool that establishes a database connection with security implications, 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 sentence that front-loads the core action ('Connect to MySQL database') and adds a useful note about environment variables. There is zero waste or redundancy, making it highly concise and well-structured for quick comprehension.

  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 database connection tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a connection handle, success status), error handling, or behavioral nuances like timeouts or security constraints. This leaves significant gaps for an AI agent to understand how to use the tool effectively.

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

  Parameters3/5

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

  Schema description coverage is 100%, meaning the input schema already documents all parameters clearly (e.g., 'Database name', 'Database host'). The description adds no additional meaning about parameters beyond implying that some might be optional via environment variables, but it doesn't specify which ones or how they interact. This meets the baseline of 3 since the schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the verb ('Connect to') and resource ('MySQL database'), making the purpose specific and understandable. It distinguishes from siblings like 'describe_table' or 'query' by focusing on establishing a connection rather than operating on an already connected database. However, it doesn't explicitly differentiate from 'list_tables', which might also require a connection, 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 Guidelines3/5

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

  The description provides implied usage guidance by noting that connection is 'optional if environment variables are set', suggesting when it might not be needed. However, it lacks explicit instructions on when to use this tool versus alternatives (e.g., whether to rely on env vars or manual input) or any prerequisites for successful connection, leaving gaps in decision-making context.

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