Server Quality Checklist

Tool Scores

• describe_tableB
  3.1/5.0
  Behavior3/5

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

  With no annotations, the description must carry the transparency burden. 'Return column metadata' implies a safe, read-only operation, but no explicit statement about side effects, permissions, or behavior on missing tables is provided.

  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?

  One sentence, no filler, front-loaded with the action verb. It is as concise as possible while communicating the core function.

  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?

  With an output schema present and only one parameter, the tool is inherently simple. The description is nearly sufficient, but lacks usage context relative to sibling tools and any note about table name qualification, leaving a small gap.

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

  Parameters2/5

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

  The single required parameter table_name has no schema description (0% coverage). The description only says 'a table' and does not add detail about expected format, qualification, or allowed values, so the agent gets little beyond the parameter name.

  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 identifies a specific action ('Return') and object ('column metadata for a table'), making the tool's purpose immediately clear. It does not explicitly call out sibling tools, so it stops short of the top 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 describe_table rather than siblings like list_tables or generate_query. There is no mention of use cases, prerequisites, or exclusion conditions.

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

• run_readonly_queryA
  3.6/5.0
  Behavior3/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 discloses key behavior: the operation is read-only and returns query rows. It doesn't cover permissions, dialects, limits, or error behavior, but the core safety-relevant trait is explicit.

  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?

  One sentence with no filler; the operative verb and key constraints ('read-only', 'single', 'SELECT or WITH') come first and the result is stated.

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

  Completeness4/5

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

  For a one-parameter tool with an output schema, the description captures the input constraint and the output shape. It doesn't need to restate the schema's return format. The main gap is no explicit sibling-selection guidance, but that is already accounted for under usage guidelines.

  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's query parameter has no description, so the description must compensate. It adds meaning by restricting the string to a single read-only SELECT or WITH query, but it gives no syntax hints, examples, or statement-termination expectations.

  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?

  States an explicit action ('Execute') and a constrained resource ('single read-only SELECT or WITH query'), plus the result ('return its rows'). It doesn't name sibling tools, but the read-only SELECT/WITH restriction helps an agent distinguish it from execute_generated_query.

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

  Usage Guidelines3/5

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

  The description implies usage for read-only query execution, but never states when to prefer this over execute_generated_query, generate_query, or not to use it. There are no explicit alternatives or exclusion conditions.

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

• generate_queryA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It discloses that the tool produces one read-only SQL statement and does not claim to execute it, which are useful behavioral traits. However, it does not elaborate on potential constraints, validation behavior, or how it relates to execution beyond that implication.

  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 no wasted words. Every phrase adds value: 'natural-language request' defines the input, 'read-only' signals safety, and 'SQL statement' defines the output.

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

  Completeness4/5

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

  For a single-parameter generation tool with an output schema, the description is nearly complete: it defines the input, the output, and the read-only nature. It would be more complete with an explicit note about not executing the generated SQL and when to choose this over the sibling execution tools.

  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 schema has zero description coverage, so the description must clarify the parameter. It does this by identifying the input as a 'natural-language request,' which adds meaning to the bare 'prompt' property. It also defines what the output will be, helping the agent understand the transformation.

  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 states a specific action ('turn ... into') and resource/outcome: a natural-language request becomes one read-only SQL statement. It clearly distinguishes generation from the sibling execution tools by describing the output as a statement rather than a run operation, though it does not explicitly name an alternative.

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

  Usage Guidelines3/5

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

  The description implies the tool is used when a natural-language request needs to be converted into SQL, and the read-only qualifier signals a safe generation context. It does not explicitly say when to use this tool instead of run_readonly_query, execute_generated_query, or the table-introspection siblings.

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

• list_tablesA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description must carry the behavioral disclosure burden. It does note the database is 'read-only', implying this is a safe read operation, but it does not disclose potential edge behaviors like whether views or system tables are included, whether sorting is applied, or any error conditions. The read-only hint provides some context but not comprehensive behavioral detail.

  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, tightly worded sentence with no redundant phrases. Every word contributes meaning: 'List' gives the action, 'tables' gives the object, and 'configured read-only database' gives the scope.

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

  Completeness4/5

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

  For a zero-parameter listing tool with a provided output schema, the description is nearly complete. It tells the agent what the tool does, and the output schema can document the return structure. It lacks only a brief note about when to use it in the broader tool workflow, but that is already captured by the low usage_guidelines score.

  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 zero parameters, so parameter documentation is not needed. With 0 parameters, the baseline is 4, and the description correctly omits parameter explanations because none exist.

  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 states a specific verb ('List') and a specific resource ('tables available in the configured read-only database'). It clearly distinguishes itself from sibling query and description tools because it enumerates all tables rather than running a query or describing one table.

  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 gives no explicit guidance on when to use this tool versus alternatives such as describe_table or run_readonly_query. The context signals list sibling tools, but the description does not reference them or define conditions for choosing this tool over them.

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

• execute_generated_queryA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It warns 'DANGEROUS' and explains that model-generated SQL is executed immediately without review, which conveys the primary risk profile. It could be more explicit about potential write/destructive effects, but the warning is substantial.

  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 two sentences with no filler. It front-loads the most critical information ('DANGEROUS') and each sentence adds essential context about behavior and alternatives.

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

  Completeness4/5

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

  For a one-parameter tool with an output schema, the description covers the core behavior, risk, and alternatives. It is slightly lacking in explicit details about prompt semantics and side effects, but overall the agent has enough to call it correctly and safely.

  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 0%, so the description must explain the 'prompt' parameter. It says 'generate SQL from a prompt,' which clarifies that the prompt is the natural-language input for SQL generation, but it does not specify prompt expectations, format, or constraints. This is minimal compensation for a complete lack of schema descriptions.

  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 states a precise action: generate SQL from a prompt and execute it immediately. It clearly distinguishes itself from siblings by noting that it executes without a separate review step, unlike generate_query and run_readonly_query.

  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 explicitly steers agents toward safer alternatives: 'Use generate_query and run_readonly_query instead when possible.' This gives a clear preference order, though it does not define exact conditions for when this tool must be used.

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