Server Quality Checklist

Tool Scores

• connectC
  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 establishes a connection but doesn't describe what that entails - whether it creates a persistent session, requires authentication, has timeout behavior, or what happens on failure. For a connection tool with zero annotation coverage, this is a significant gap.

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

  Conciseness5/5

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

  The description is a single, clear sentence with zero wasted words. It's appropriately sized for a straightforward connection tool and gets directly to the point 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?

  For a connection tool with 5 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what a successful connection returns, what happens on failure, whether connections are pooled or persistent, or how this tool relates to other database operations in the sibling set.

  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 5 parameters are documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema. The baseline 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.

  Purpose4/5

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

  The description clearly states the action ('Connect to') and resource ('a MySQL database'), making the purpose immediately understandable. However, it doesn't differentiate this from sibling tools like 'use_database' or 'status', which might also involve database connections in some way.

  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 'use_database' or 'disconnect'. There's no mention of prerequisites, when this should be called first, or what happens if called multiple times.

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

• describe_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 full burden but only states the basic function. It doesn't disclose whether this is a read-only operation, requires database connection, has rate limits, returns metadata format, or any behavioral traits beyond the minimal 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 is a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a simple tool with one parameter and is front-loaded with the essential information.

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

  Completeness2/5

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

  For a tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'structure' means (columns, types, constraints?), whether a database connection is required, or what format the output takes, leaving significant gaps for agent understanding.

  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% (the 'table' parameter is fully documented in the schema), so the baseline is 3. The description doesn't add any parameter meaning beyond what's already in the schema, but doesn't need to compensate for gaps 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 action ('Get the structure') and target resource ('a specific table'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_tables' or 'query' beyond the basic function.

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

  Usage Guidelines2/5

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

  No guidance is provided about when to use this tool versus alternatives like 'list_tables' (which lists tables) or 'query' (which might return table structure through SQL). The description only states what it does, not when it should be selected.

  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 full burden for behavioral disclosure. It states the tool executes SQL queries but doesn't mention critical behaviors: whether it's read-only or can mutate data, what permissions are required, potential side effects (e.g., data modification), error handling, or result format. For a database query tool with zero annotation coverage, this is a significant gap.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that states the core functionality without unnecessary words. It's appropriately sized for a tool with clear parameters in the schema, and every word earns its place by conveying essential information about the tool's purpose.

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

  Completeness2/5

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

  Given this is a database query tool with no annotations, no output schema, and siblings that perform related operations, the description is incomplete. It doesn't address critical context: whether queries can modify data, what happens with different SQL statements, how results are returned, or how this differs from metadata-focused siblings. The agent lacks sufficient information for 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?

  Schema description coverage is 100%, so the schema already documents both parameters ('sql' and 'params') adequately. The description doesn't add any meaningful parameter semantics beyond what the schema provides - it mentions 'SQL query' which aligns with the 'sql' parameter but offers no additional context about parameter usage, constraints, or examples.

  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 ('Execute') and target ('SQL query on the connected database'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate this from sibling tools like 'describe_table' or 'list_tables' which might also involve database queries, leaving some ambiguity 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 alternatives. It doesn't mention prerequisites (e.g., needing to connect first), exclusions (e.g., not for schema operations), or comparisons to siblings like 'describe_table' for metadata queries. This leaves the agent without context for tool selection.

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

• set_readonlyC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Enable or disable read-only mode' implies a mutation that changes system state, it doesn't specify critical details like required permissions, whether the change is reversible, side effects (e.g., on active queries), or error conditions. For a mutation 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 directly states the tool's function without any fluff. It's appropriately sized and front-loaded, making it easy to parse quickly. Every word earns its place, with no wasted information.

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

  Completeness2/5

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

  Given the tool's complexity (a mutation affecting system state), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what happens after enabling/disabling (e.g., confirmation message, error handling), nor does it cover behavioral aspects like permissions or side effects. For a state-changing tool, this leaves too much unspecified.

  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 parameter 'readonly' clearly documented in the schema as a boolean to enable/disable mode. The description doesn't add any meaning beyond what the schema provides (it only restates the tool's purpose), so it meets the baseline of 3 where 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 with a specific verb ('Enable or disable') and resource ('read-only mode'), making it immediately understandable. However, it doesn't differentiate this tool from its siblings (like 'connect', 'disconnect', 'status') which might also affect system states, so it doesn't fully distinguish itself 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. It doesn't mention prerequisites (e.g., needing to be connected first), exclusions, or how it relates to sibling tools like 'status' (which might show current mode) or 'disconnect' (which might affect access). Without such context, an agent might struggle to apply it correctly.

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

• use_databaseC
  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 only states the action without behavioral details. It doesn't disclose whether switching databases requires existing connections, affects ongoing queries, has permission requirements, or provides confirmation feedback. This leaves significant behavioral gaps for a mutation operation.

  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 wasted words. It's appropriately sized for a simple tool and front-loads the essential information 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?

  For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'switch' entails operationally, what happens to existing connections/queries, what success/failure looks like, or how it relates to sibling tools. The context demands more behavioral disclosure than provided.

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

  Parameters3/5

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

  Schema description coverage is 100% with one well-documented parameter, so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides ('Name of the database to switch to'), maintaining but not enhancing the 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 ('Switch') and target resource ('different database'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'connect' or 'list_databases', 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?

  The description provides no guidance on when to use this tool versus alternatives like 'connect' (for initial connection) or 'list_databases' (for discovery). It lacks context about prerequisites, timing, or exclusions, offering only the basic function without usage context.

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

• list_databasesB
  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 states it's a read operation ('Get'), but doesn't cover aspects like whether it requires authentication, if it's rate-limited, what the output format is (e.g., list of names or detailed info), or if it's paginated. This leaves significant gaps for a tool that interacts with server resources.

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

  Conciseness5/5

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

  The description is a single, clear sentence that directly states the tool's purpose without any fluff or redundancy. It's front-loaded and efficiently conveys the essential information, making it easy to parse quickly.

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

  Completeness2/5

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

  Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'accessible' means (e.g., permissions-based), what the return value includes, or behavioral traits like error handling. For a tool that lists server resources, more context is needed to use it effectively.

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

  Parameters4/5

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

  The input schema has 100% description coverage, documenting the single parameter as a 'Dummy parameter for no-parameter tools'. The description doesn't add any parameter details beyond this, which is acceptable since the schema fully covers it and the tool effectively has zero meaningful parameters. 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 ('Get') and resource ('list of all accessible databases on the server'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_tables' or 'describe_table', which would require mentioning it's about databases rather than tables or schema details.

  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 to connect first), exclusions, or how it relates to siblings like 'list_tables' (which lists tables within a database) or 'use_database' (which selects a database).

  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 the full burden of behavioral disclosure. It states the tool lists tables but doesn't cover critical aspects like whether it's read-only, if it requires specific permissions, what the output format is, or if there are limitations (e.g., pagination). This leaves significant gaps for a tool that interacts with a database.

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

  Conciseness5/5

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

  The description is a single, clear sentence that directly states the tool's purpose without any wasted words. It's front-loaded and efficiently communicates the essential action, making it easy to parse and understand quickly.

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

  Completeness2/5

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

  Given the complexity of database interactions and lack of annotations or output schema, the description is incomplete. It doesn't address behavioral traits, output format, or usage context, which are crucial for an AI agent to effectively invoke this tool in a database environment with multiple siblings.

  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 input schema has 100% coverage, documenting the single dummy parameter. The description correctly implies no meaningful parameters are needed for the core functionality, adding value by not cluttering with unnecessary details. However, it doesn't explain why a dummy parameter is required, which could confuse users.

  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 a list') and resource ('tables in the current database'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_databases' or 'describe_table', which would require more specific scoping or 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. It doesn't mention prerequisites (e.g., needing to be connected to a database), exclusions, or comparisons to siblings like 'list_databases' for broader scope or 'describe_table' for detailed info, leaving usage context unclear.

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

• statusB
  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 states the tool checks status but doesn't reveal what information is returned (e.g., connection health, latency, error details), whether it's safe to call repeatedly, or if it has side effects. This leaves significant gaps for a tool that might inform critical decisions.

  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 directly states the tool's purpose without any fluff. It's front-loaded with the core action and resource, making it easy to parse quickly.

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

  Completeness2/5

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

  Given the lack of annotations and output schema, the description is incomplete for a status-checking tool. It doesn't explain what the status check entails (e.g., returns a boolean, detailed metrics, or error messages), leaving the agent uncertain about the tool's behavior and output format in a context with multiple database-related siblings.

  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 input schema has 100% description coverage, documenting the single parameter as a dummy for no-parameter tools. The description doesn't add parameter details beyond this, but since the schema fully covers it and the tool effectively has zero functional parameters, a baseline of 4 is appropriate—it's clear no meaningful inputs are needed.

  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 with a specific verb ('Check') and resource ('database connection status'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'connect' or 'disconnect', which also relate to database connections.

  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 'connect' or 'disconnect'. It doesn't mention prerequisites (e.g., whether a connection must already exist) or typical use cases (e.g., verifying connectivity before queries).

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

• disconnectA
  3.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 closes a connection but does not disclose behavioral traits such as whether this is reversible, if it requires specific permissions, what happens to pending queries, or error handling. This leaves significant gaps for a mutation tool.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence with zero waste. It efficiently conveys the core purpose without unnecessary details, 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 simplicity (closing a connection) and no output schema, the description is adequate but lacks depth. Without annotations, it should ideally mention implications like termination of active sessions or confirmation of closure, leaving room for improvement in completeness.

  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 input schema has 1 parameter with 100% coverage, documenting it as a 'Dummy parameter for no-parameter tools'. The description adds no parameter semantics, but since the tool effectively has 0 functional parameters, a baseline of 4 is appropriate as no additional clarification is needed.

  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 specific action ('Close') and resource ('current MySQL database connection'), distinguishing it from sibling tools like 'connect' or 'status'. It precisely defines what the tool does without ambiguity.

  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 implies usage context by specifying 'current MySQL database connection', suggesting it should be used when a connection is active. However, it does not explicitly state when to use it versus alternatives like 'connect' or provide exclusion criteria.

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