Server Quality Checklist

Tool Scores

• explainQueryA
  4.7/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, destructiveHint, idempotentHint, openWorldHint. The description adds value by specifying the output format (JSON array of EXPLAIN QUERY PLAN rows) and explaining how it works under the hood. No contradictions.

  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 efficiently structured with clear sections (main purpose, usecase, when_not_to_use, examples, what_it_returns), no wasted words, and key information front-loaded.

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

  Completeness5/5

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

  Given the simple tool (1 param, output schema present, annotations complete), the description fully covers purpose, usage, return format, and context for selecting among 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?

  Schema coverage is 100% for the single 'query' parameter. The description's example section reinforces correct parameter usage (e.g., 'explainQuery(query="SELECT ...")'), adding context beyond the schema description.

  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 returns execution plans to diagnose performance, with a specific verb ('explain') and resource ('SQL query'). It distinguishes from siblings like readQuery by noting it provides structured output via EXPLAIN QUERY PLAN.

  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 'usecase' and 'when_not_to_use' sections explicitly state when to use (slow queries, understanding scans/indexes, index decisions) and when not (running queries via readQuery/writeQuery, checking schemas via getTableSchema), with examples.

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

• listTablesA
  4.7/5.0
  Behavior4/5

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

  Beyond the annotations (readOnlyHint, idempotentHint), the description adds that the result is a sorted JSON array of table names and describes pagination behavior with nextCursor. This is valuable context not captured by annotations.

  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 well-structured with front-loaded main sentence and separate sections for use cases, examples, return value, and pagination. Every section adds value without unnecessary repetition.

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

  Completeness5/5

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

  The description fully covers the tool's behavior for its simplicity: it lists tables, returns sorted array, and supports pagination. Given the presence of an output schema and no parameters, the description is complete.

  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 schema coverage is 100%. The description does not need to add parameter semantics; it correctly omits parameter details. The baseline score for zero parameters is 4.

  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 'List all tables in the connected SQLite database.' The verb 'list' and resource 'tables' are specific. The examples and usage guidelines differentiate it from siblings like getTableSchema, making the purpose unambiguous.

  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 includes a <usecase> section explicitly stating when to call the tool (e.g., ALWAYS call this tool FIRST when exploring tables) and provides examples of correct and incorrect usage, demonstrating when to use alternatives like getTableSchema.

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

• listTriggersA
  4.8/5.0
  Behavior5/5

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

  Annotations already show readOnly, destructive, idempotent hints. Description adds pagination behavior and return format (sorted JSON array of trigger name strings), which adds value beyond annotations.

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

  Conciseness4/5

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

  The description is well-structured with sections, but somewhat verbose with usecase and examples. It is front-loaded with main purpose.

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

  Completeness5/5

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

  Given no parameters and output schema exists, description explains return format (sorted JSON array) and pagination. It covers purpose, usage, and output completely.

  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?

  No parameters are defined, so baseline is 4. The description does not need to add parameter info, and it doesn't attempt to.

  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 'List all triggers in the connected SQLite database.' It uses a specific verb and resource, and distinguishes from sibling tools like listTables and listViews.

  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 usecase section explicitly lists when to use: investigating side-effects, auditing coverage, user asking. Examples include correct and incorrect uses, with alternative tool for getting trigger body.

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

• getTableSchemaA
  4.9/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is known to be safe. The description adds value by detailing what the tool returns (column types, nullable, keys, defaults, foreign keys) and the exact structure, which is beyond the annotations.

  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 well-structured with separate sections (usecase, examples, what_it_returns) and is front-loaded with the main purpose. Every sentence is informative and no redundant content exists.

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

  Completeness5/5

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

  Given the output schema exists (as indicated by context signals), the description covers all necessary aspects: purpose, usage prerequisites, parameter example, and return structure. It is complete and leaves no ambiguity.

  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 sole parameter 'table' is fully described in the input schema with coverage at 100%. The description reinforces the prerequisite 'use listTables first' and provides concrete examples of usage, adding more context than the schema alone.

  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 'Get column definitions and foreign key relationships for a table', using a specific verb and resource. It distinguishes itself from sibling tools like listTables (which lists tables) and explainQuery, making its purpose unambiguous.

  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?

  Explicit guidance is provided: 'ALWAYS call this before writing queries' and 'Requires `table` — call `listTables` first.' The <usecase> section and examples further clarify when and how to use the tool, including what to do before invoking it.

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

• listViewsA
  4.9/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds pagination details and return format, providing complete behavioral picture without contradiction.

  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?

  Well-structured with clear sections (usecase, examples, what_it_returns, pagination). Core statement is front-loaded, each sentence provides value, no redundancy.

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

  Completeness5/5

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

  For a simple no-parameter tool with output schema, description covers return format (sorted JSON array of view name strings) and pagination, making it fully complete.

  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?

  Tool has zero parameters and schema coverage is 100%. With no parameters, the description doesn't need to add parameter info; baseline 4 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 clearly states 'List all views' with specific verb and resource. Use cases and examples distinguish it from siblings like getTableSchema and listTables, making purpose unambiguous.

  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?

  Explicitly provides when to use (exploring views, verifying existence) and when not to (see columns → getTableSchema). Examples with checkmarks and crosses give clear guidance.

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

• readQueryA
  4.9/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by specifying allowed statements, describing the return format (<what_it_returns>), explaining pagination behavior (<pagination>) including that EXPLAIN ignores cursor, and showing examples. No contradiction with annotations.

  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 well-structured with clear sections using XML-like tags (usecase, when_not_to_use, examples, what_it_returns, pagination). It is concise but comprehensive, with no redundant information. Every sentence adds value.

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

  Completeness5/5

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

  Given the complexity of the tool (SQL queries with pagination), the description covers all necessary aspects: allowed statements, usage guidance, examples, return structure, and pagination details. The presence of an output schema further reduces the need to describe return values in depth.

  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?

  Schema coverage is 100% with both cursor and query described in the input schema. The description adds extra context: the pagination section explains cursor usage in detail, and examples illustrate valid queries. While the schema already provides good baseline, the description complements it effectively.

  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 'Execute a read-only SQL query. Allowed statements: SELECT, EXPLAIN.' It uses a specific verb and resource, and distinguishes from siblings by referencing writeQuery, explainQuery, listTables, and getTableSchema in the when_not_to_use section.

  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 includes explicit <usecase> and <when_not_to_use> sections listing when to use the tool and when not to, with clear references to sibling tools. It also provides examples of correct and incorrect usage, making it easy for an agent to decide when to invoke this tool.

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