Server Quality Checklist

Tool Scores

• execute_updateB
  3.3/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It mentions the return value (affected rows) but does not explicitly warn about irreversible data modification, permission requirements, or that updates are limited to rows matching the WHERE clause. Minimal risk information 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?

  The description is extremely concise: one sentence with two clauses. Every word earns its place, and the return value is front-loaded, making it easy to parse.

  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?

  The description is adequate for a simple update command but lacks explicit emphasis on the WHERE-clause filtering, which is crucial for safe usage. Since the where parameter is required, the description could clarify that only matching rows are updated, but the schema conveys this. With no annotations or output schema, the description is serviceable but leaves some context implicit.

  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 covers all three parameters with descriptions, so the baseline is 3. The tool description does not add extra parameter-level meaning beyond what the schema offers; it only provides the return behavior, which is not parameter-specific.

  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 'Update data in a table' with a specific verb and resource, clearly distinguishing it from siblings like execute_query and execute_insert. The purpose is unambiguous and immediately understandable.

  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. There is no mention of prerequisites, exclusions, or comparison with execute_insert or execute_query, leaving the agent to infer usage from the name alone.

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

• get_table_statsB
  3.3/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. It transparently indicates the tool is a read-only data retrieval (get statistics), but it omits details such as whether column information covers data types, nullable flags, or other schema details, and does not mention performance implications or failure modes.

  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 front-loads the verb and resource. It wastes no words and clearly communicates 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 one simple parameter and no output schema, the description provides the key outputs (row count, column information) but omits potential additional statistics and error behavior. It is functional but leaves some ambiguity about the exact return structure.

  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 tableName parameter. The description adds 'including row count and column information' which loosely maps to the output, but it does not add new meaning to the parameter itself beyond what the schema provides.

  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 'gets statistics' about a table, naming the specific resource and outputs (row count, column information). It is a specific verb+resource combination, but it does not explicitly distinguish itself from siblings like get_table_schema or execute_query, which could also retrieve related data.

  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 given on when to use this tool over alternatives such as execute_query or get_table_schema. The description implies usage for retrieving table statistics, but it does not state exclusions or comparison with siblings.

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

• execute_insertA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description carries the transparency burden. It discloses a behavioral trait: the function returns the inserted row ID 'if available,' hinting at possible unavailability. However, it does not state side effects (e.g., data mutation), permission needs, or error conditions, leaving gaps for a write 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 two concise sentences, front-loading the core action. Every word contributes: 'Insert data into a table' states the function, and the second sentence provides a useful return detail. No redundancy or fluff.

  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 simple tool with a clear schema, the description covers the action and return value. However, with no output schema, it omits when the row ID might be unavailable and gives no hint about constraints or error behavior. It is close to complete but lacks a few contextual edges.

  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 parameters are already well documented. The description adds no extra meaning beyond the schema—it doesn't explain how the 'data' object should be structured or any special tableName considerations. Baseline 3 is appropriate.

  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 and resource: 'Insert data into a table.' This clearly distinguishes the tool from siblings like execute_query and execute_update by focusing on the insert operation. Adding the return behavior ('Returns the inserted row ID if available') further clarifies purpose.

  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?

  There is no guidance on when to use this tool versus alternatives. It does not mention when to prefer insert over update/query, nor does it state conditions like table existence or constraint requirements. The description only states what the tool 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.

• execute_queryA
  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. It mentions executing a query and returning results, and says 'Use for SELECT queries', which implies a read-only nature, but does not explicitly state that it cannot modify data, nor does it mention side effects, permissions, or return format specifics.

  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 short sentences with no unnecessary words. It conveys the primary purpose and usage context succinctly, earning a perfect score for conciseness.

  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?

  Given the tool's simplicity (one parameter, no output schema), the description is adequate: it explains the action, the return of results, and the applicable query type. It lacks a few details like explicit read-only assurance, but overall it is sufficiently complete for straightforward 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 schema has 100% parameter description coverage with 'The SQL query to execute (SELECT only)'. The description adds no significant semantic meaning beyond what the schema already provides, though it does reinforce the SELECT-only constraint. Baseline of 3 is appropriate given full schema coverage.

  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 executes SQL queries and returns results, specifically for SELECT queries to retrieve data. This distinctly separates it from siblings like execute_insert and execute_update, which handle mutations, and from metadata tools like list_tables.

  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 explicit guidance to use this tool for SELECT queries, clearly indicating the appropriate use case. It does not explicitly mention alternatives or exclusions, but the intended context is strongly implied, making it effective.

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

• get_table_schemaA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden for behavioral disclosure. It implies a read-only operation via 'Get', but it doesn't explicitly address permissions, error conditions, or side effects. However, the tool is simple and the omission isn't critical, so it stays at a baseline adequate level.

  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 filler. It efficiently conveys the tool's purpose and key output details without redundancy.

  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?

  The description explains what the tool returns (columns, types, constraints) and has a single clearly described parameter. Without an output schema or annotations, this is sufficient, though slightly more detail about error handling or return format could be useful.

  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 fully describes the tableName parameter (100% coverage), so the description does not add meaning beyond what is already provided. The description's mention of schema contents relates to the return value, not the parameter, so baseline 3 applies.

  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 retrieves a table's schema/structure, specifying the included elements (column names, types, constraints). This distinguishes it from sibling tools like list_tables or get_table_stats, which have different purposes.

  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 the tool (when you need a table's schema), but it doesn't explicitly mention alternatives or exclusions. It could have indicated use cases for sibling tools, but the context is unambiguous.

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

• list_tablesA
  4.2/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. 'List all tables' clearly indicates a read-only enumeration, but it does not disclose potential performance implications, whether system tables are included, or any other behavioral nuances. This is adequate but not rich.

  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, simple sentence of six words that precisely states the tool's function. It is front-loaded and contains no filler, earning a perfect score for conciseness.

  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 list operation with no output schema and no annotations, the description gives the essential purpose. However, it does not specify the return format (e.g., an array of table names) or whether the list is ordered or filtered. A brief note about the output would improve 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 tool has zero parameters, so there is no parameter information to convey. The baseline of 4 applies because the description needs to add nothing beyond the schema, which is empty.

  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 uses a specific verb 'List' and clearly identifies the resource as 'tables in the database'. This distinguishes it from siblings like execute_query and get_table_schema, which operate on query results or individual table schemas.

  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 the tool is for enumerating database tables, which provides clear context for when to use it. It does not explicitly exclude alternatives or mention siblings, but the purpose is self-evident in a database toolset.

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