Server Quality Checklist

Tool Scores

• list_tablesA
  3.8/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full burden. It discloses read-only guarantee, prohibition on raw SQL, and return format. This is appropriate transparency for a list operation, though it doesn't cover edge cases like limit 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?

  Three short sentences, all informative: purpose, return metadata, and safety constraints. No fluff.

  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?

  Covers purpose, return type, and safety, but lacks parameter usage details, making it slightly incomplete for invoking with optional filters. However, given the simple nature, it's mostly adequate.

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

  Parameters1/5

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

  The description makes no mention of the 'limit' and 'schemas' parameters, and schema description coverage is 0%. The tool name and description imply schemas are pre-allowlisted, but the schemas parameter's filtering role is not explained. This fails to compensate for the low 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 lists tables in allowlisted MySQL schemas and returns metadata (schema, name, type). This distinguishes it from siblings like describe_table (single table details) and get_rows (row data).

  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?

  Provides clear context: always read-only, no raw SQL, operates only on allowlisted schemas. This guides safe usage and sets expectations, though it doesn't explicitly name alternative tools or when-not-to-use.

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

• describe_tableA
  4.1/5.0
  Behavior4/5

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

  No annotations are present, so the description carries the full burden. It discloses that the operation is read-only, that sensitive columns may be redacted, and that only allowlisted tables are accessible. These are meaningful behavioral traits that go beyond a simple 'describe' statement.

  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 three short sentences, front-loaded with the core purpose followed by two concise caveats. No wasted words.

  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?

  With no output schema, the description clearly lists the returned metadata (columns, types, nullability, key metadata) and covers key behavioral caveats (redaction, read-only, allowlisting). It omits details like error behavior or permission enforcement, but for a simple describe tool, it is fairly complete.

  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 two parameters (schema, table) have no descriptions in the schema, and the description's only mention is 'single allowlisted MySQL table', which does not clarify what the schema parameter represents or how the two parameters relate. With 0% schema description coverage, the description should compensate by explaining each parameter, but it does not.

  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 action (describe), the target (a single allowlisted MySQL table), and the specific metadata returned (columns, types, nullability, and key metadata). This distinguishes it from sibling tools like list_tables (listing tables) and get_rows (retrieving rows).

  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 when to use the tool (to get schema details for one table) via the word 'single', but does not explicitly mention alternatives or exclusions. No 'use this instead of X' guidance is provided, though the purpose statement makes the context clear.

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

• get_rowsA
  4.4/5.0
  Behavior5/5

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

  Since no annotations are provided, the description carries the full burden and does so well. It discloses read-only nature, sensitive column masking, a row cap (MCP_MAX_ROWS), and supported filter/pagination behaviors, which are critical behavioral traits not apparent from the schema alone.

  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?

  Three concise sentences, front-loaded with the core action. Each sentence provides distinct value (purpose, requirements/capabilities, safety/limits) with no 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?

  Given 7 parameters, no output schema, and no annotations, the description covers essential usage constraints and safety behaviors. It does not explain the return payload structure or fully clarify the 'columnAllowlist' parameter, but it gives an agent enough context to select and invoke the tool correctly.

  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?

  With 0% schema description coverage, the description must compensate. It adds meaning to columns (explicit list required), filters (equality/IN/range), and pagination (limit/offset). However, the 'columnAllowlist' parameter is not mentioned, and 'schema' is only implied via 'MySQL table', leaving gaps.

  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?

  Description uses a specific verb ('Read rows') and resource ('single allowlisted MySQL table'), clearly distinguishing from sibling tools like describe_table and list_tables. The scope and action are unambiguous.

  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?

  Description provides clear context for when to use (reading row data) and specifies prerequisites ('Requires an explicit column list') and capabilities (filter types, pagination). However, it does not explicitly name alternatives or exclusions relative to sibling tools, so it stops short of a 5.

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

• health_checkA
  4.4/5.0
  Behavior4/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 the success response (ok=true, latencyMs) and explicitly states what is NOT exposed (host, user, password, version). It does not describe failure behavior, but for a health check with no side effects, this is reasonable.

  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, front-loaded with the core purpose, and every word earns its place. It includes a useful disclaimer about sensitive data without any 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 parameterless health check, the description is almost complete. It states the success condition and output, and the limitation about not exposing credentials. The only gap is the unreachable case, but the tool is simple enough that this does not significantly impair understanding.

  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 the description needs no parameter details. The baseline of 4 applies, and the description adds context about the tool's scope without needing to explain parameter semantics.

  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's purpose: 'Report server/database reachability.' It specifies the return values (ok=true, latencyMs) and explicitly distinguishes itself from the sibling table tools by focusing on connectivity rather than data operations.

  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 when to use this tool (to check server/database reachability) and clearly, if implicitly, differentiates from the sibling tools. It lacks explicit exclusions or alternative tool references, 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.