Server Quality Checklist

Tool Scores

• list_proceduresA
  3.8/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 full burden of behavioral disclosure. It states the operation is a list operation and mentions optional filtering, but does not disclose details like whether system procedures are included, ordering, or return format. For a read-only listing tool, this is adequate but minimal.

  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 effectively communicates the action and optional filter in under 20 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?

  Given the simplicity of the tool (one optional parameter, no nested objects, no output schema), the description sufficiently covers the core function. It doesn't explain the return structure, but the tool name and sibling context make it obvious that it returns a list of procedures. The absence of annotations is a minor gap, but for a list operation this is acceptable.

  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 only parameter 'schema' has a complete description in the schema (100% coverage). The tool description's mention of 'optionally filtered to a single schema' simply restates the schema's meaning, adding no additional nuance beyond the structured field.

  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 stored procedures and can optionally filter by schema. This distinguishes it from sibling tools like list_tables and list_views, using a specific verb and resource with an additional filtering nuance.

  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 discovering stored procedures, and the optional schema filter suggests when to narrow results. However, it does not explicitly mention alternatives or when not to use this tool, leaving the guidance implicit rather than explicit.

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

• list_schemasA
  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 carries the burden of behavioral disclosure. It indicates a read-only operation via 'list' but does not mention return format, whether system schemas are included, pagination, or permission requirements. It is not misleading, but adds minimal behavioral context beyond the title.

  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, no-waste sentence that directly states the tool's purpose. It is appropriately sized and front-loaded, earning full marks 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 simple list tool with no parameters and no output schema, the description adequately explains the basic function. However, it could be more complete by mentioning whether the list includes system schemas or what the result contains (e.g., names only), but this is not critical for basic invocation.

  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 schema fully covers parameter semantics. The description adds no parameter-specific information, but none is needed; the baseline for 0 params 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 'List all schemas in the connected database' uses a specific verb ('list') and resource ('schemas'), clearly distinguishing it from sibling tools like list_tables, list_views, and list_functions. It fully states the operation's scope.

  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 such as describe_table or find_similar_names. There is no mention of exclusions, prerequisites, or typical scenarios, leaving the agent to infer usage solely from the name.

  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?

  Without annotations, the description discloses the output columns and the optional schema filter. It doesn't mention whether system tables are included, ordering, or permission requirements, which are potential gaps.

  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?

  Two sentences, direct, no redundant information. Both sentences provide necessary content: purpose and return format.

  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 low complexity (one optional parameter, no output schema), the description covers purpose, parameter, and return fields. It is largely complete, though it could mention naming conventions or schema default behavior more explicitly.

  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 already fully documents the 'schema' parameter (100% coverage). The description adds no new semantic information beyond saying 'optionally filtered to a single schema,' which mirrors 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?

  Clearly states the tool lists tables in the database, with optional schema filtering. Distinguishes from sibling tools like list_procedures, list_views, and list_functions by the resource type.

  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 use for listing tables, and the optional schema parameter provides a use case. However, it does not explicitly contrast with sibling listing tools or state when not to use it.

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

• describe_viewA
  4/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 discloses the output content (columns and SQL definition) but does not explicitly state read-only behavior, potential errors (e.g., if the view does not exist), or any permission requirements. This is adequate but lacks deeper behavioral context.

  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 redundant phrasing. It efficiently conveys the core purpose and outputs without wasting 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?

  For a simple two-parameter tool with no output schema, the description adequately covers what the tool returns and when to use it. It does not specify the return format (e.g., list vs. JSON), but the outputs described are straightforward enough to infer. A slight gap is the lack of mention of any edge cases or error behavior.

  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 already describes both parameters ('View name' and 'Schema name, e.g. dbo') with 100% coverage, so the description does not need to add parameter details. The description adds marginal value by hinting at what the parameters are used for, but it does not go beyond the schema.

  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 function with a specific verb ('Get') and resource ('a view'), and enumerates the two outputs: column names/types and SQL definition. This distinguishes it from sibling tools like describe_table and describe_procedure, which target other object types.

  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 phrase 'for a view' provides clear context for when to use this tool, and the inclusion of 'SQL definition' differentiates it from describe_table, which would be appropriate for tables. No explicit exclusions or alternative tools are named, but the context is clear enough for most selection scenarios.

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

• find_similar_namesA
  4/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 of behavioral disclosure. It reveals the use of the Jaro-Winkler algorithm and the fuzzy nature of the search, which are valuable details. But it does not mention return format, ordering, case sensitivity, or any side effects, leaving room for ambiguity about result structure.

  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, well-structured sentence that front-loads the core functionality and immediately follows with a usage hint. Every word earns its place; no unnecessary elaboration or repetition.

  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 moderate complexity (3 parameters, no output schema), the description covers key aspects: what it searches, how (fuzzy, Jaro-Winkler), and when to use it. It does not describe the return value structure, but for a search tool the expected result (matching names) is fairly inferable from the name and description. Overall, it is adequately complete for an agent 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?

  Schema description coverage is 100%, and each parameter (searchTerm, kinds, limit) has a clear description. The tool description adds context about which object types are searched, complementing the schema's 'kinds' parameter, but no additional parameter syntax or behavior is explained. Baseline 3 is appropriate as the schema already effectively documents parameters.

  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 identifies the tool's purpose: 'Jaro-Winkler fuzzy search over table/view/column/procedure/function names'. It uses a specific verb ('search') and resource scope (object names), and distinguishes itself from sibling list tools like list_tables and query_table by highlighting fuzzy matching for when exact spelling is unknown.

  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 instruction 'use this when you don't remember the exact spelling of an object' gives explicit context for when to choose this tool over exact-match alternatives. However, it does not name specific alternative tools or state when not to use it, which would have made the guidance stronger.

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

• list_viewsA
  4.1/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 burden of behavioral disclosure. It clearly indicates the read-only nature via 'List' and discloses the return fields (table_schema, table_name). It does not mention potential side effects or edge cases, but for a simple listing tool, this level of transparency is adequate.

  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 concise and well-structured, consisting of two short sentences that state the purpose, the optional filter, and the returned columns. There is no redundancy or unnecessary detail.

  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 tool with a single optional parameter and no output schema, the description is complete. It specifies the resource (views), the optional filtering behavior, and the returned fields (table_schema and table_name). No additional context seems necessary for correct invocation.

  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 the schema parameter already described as 'Optional schema name to filter by'. The description reinforces this by mentioning 'optionally filtered to a single schema', but it adds little beyond what the schema already provides. The 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 clearly states 'List views in the database' with a specific verb and resource, and it distinguishes the tool from siblings like list_tables and list_procedures by specifying 'views'. It also mentions optional schema filtering, making the scope precise.

  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 when to use the tool (when you need to list views, optionally in a schema) but does not explicitly contrast it with alternatives or state exclusions. Sibling context suggests alternatives, but the description itself lacks direct when-to-use vs when-not-to-use guidance.

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

• describe_functionA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It explicitly states the tool is read-only and never executes the function, which is a key behavioral disclosure. It also enumerates what data is returned, adding context about the tool's operation. However, it does not discuss error handling, required permissions, or output formatting, so it's good but not exhaustive.

  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?

  Two short sentences, front-loaded with the main verb and object. Every word earns its place, and the read-only caveat is a single clause. 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 the tool's simplicity (2 required params, no output schema, no annotations), the description covers all the essential aspects: what data is returned (parameters, return type, SQL definition) and the behavioral guarantee (never executes). It could be more exhaustive about edge cases, but for its complexity, it's sufficient.

  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 already contains descriptions for both parameters (schema and function) at 100% coverage. The description does not add any additional meaning about the parameters themselves; it only describes what the tool returns, not how to specify the arguments. Therefore, it sits at the baseline.

  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 'Get' and clearly identifies the resource ('a function') and the scope of what is returned (parameters, return type, SQL definition). It distinguishes from sibling tools like describe_procedure and list_functions by focusing on the function's metadata and definition, plus adding a read-only note.

  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 function's parameters, return type, or SQL body. It also effectively says 'when not' by stating it never executes the function, implying that execution is out of scope. It does not explicitly name alternatives, but the read-only caveat is a usage guideline.

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

• describe_tableA
  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. The verb 'Get' and the listing of metadata elements make it clear this is a read-only operation, which is the primary behavioral trait. It does not mention potential errors or permissions, but for a describe operation of this simplicity, the description sufficiently communicates the 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, concise sentence that delivers the essential information immediately. No filler or redundant content, earning a perfect score for conciseness and structure.

  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, the description is reasonably complete. It lists what information is returned (column names, data types, nullability, primary key info) and does not require an output schema to explain return values. Slight gaps include no mention of whether the table must exist or ordering of results, but these are not critical for a basic describe operation.

  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 coverage is 100%, as both 'table' and 'schema' have descriptions in the input schema. The tool description does not add any additional meaning to the parameters beyond what the schema already provides, so the baseline score of 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's function with a specific verb ('Get') and resource ('for a table'), and lists the exact information returned: column names, data types, nullability, and primary key info. This distinguishes it from sibling tools like describe_view, describe_procedure, and describe_function, 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 Guidelines4/5

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

  The phrase 'for a table' provides clear context that this tool is specifically for tables, implying it should be used when you need schema information about a table. While it does not explicitly exclude views or procedures, the sibling tool names (describe_view, etc.) make the intended usage clear, and there are no misleading statements about 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.

• join_tablesA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries full behavioral disclosure. It states validation of every table/column against the real schema, rejection of raw SQL fragments, and hard limits (max 200 rows, up to 6 joins). These are meaningful behavioral constraints beyond what the schema shows, though it does not describe output format or error cases.

  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?

  Two efficient sentences: the first states the core purpose, the second adds key constraints. No filler, front-loaded, and every sentence earns its place.

  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 tool with 5 parameters, nested objects, and no output schema, the description covers the essential high-level behavior and limitations. The schema provides detailed parameter semantics, and the description fills in the validation and limit context. It lacks explicit note about join ordering or column defaults, but those are captured in the schema descriptions, so the overall completeness is strong.

  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 baseline is 3. The description mostly reiterates schema facts (max rows, join limit) and adds the validation/no-raw-SQL context, but does not add deeper meaning to parameters beyond what the schema already provides.

  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 selects across multiple tables/views with explicit join conditions. It uses a specific verb (select) and resource (multiple tables/views), and distinguishes itself from single-table tools like browse_table/query_table by highlighting joins.

  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 gives strong context: it validates against the real schema (same as browse_table/query_table) and explicitly forbids raw SQL fragments, implying this is for structured multi-table queries rather than raw SQL (run_query). It does not explicitly name alternatives or state 'use this when...', but the context and sibling names make the intended use clear.

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

• describe_procedureA
  4.3/5.0
  Behavior5/5

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

  With no annotations provided, the description takes full responsibility and explicitly states 'This tool only reads the procedure's metadata — it never executes it.' This is a crucial safety guarantee for a database tool and goes beyond basic 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 two sentences with the main purpose front-loaded and a concise safety clarification. No unnecessary words or 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?

  For a simple two-parameter tool with no output schema, the description fully covers purpose, scope, and safety. It is complete enough for an agent 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?

  The input schema already documents both required parameters with examples (e.g., 'dbo' for schema), achieving 100% coverage. The description adds no extra parameter meaning beyond what the schema provides.

  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 parameters and the SQL definition (CREATE PROCEDURE body) for a stored procedure', specifying the verb and resource. It also distinguishes from sibling describe tools by focusing on procedures specifically.

  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 by stating what it retrieves, but does not explicitly say when to use this over alternatives like describe_table or list_procedures. There is no mention of exclusions or alternative tools.

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

• fuzzy_search_columnA
  4.3/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries full burden. It discloses the key non-obvious behavior: it samples up to sampleSize distinct values server-side and ranks them client-side. However, the wording ambiguously mentions 'rows' versus 'distinct values', and doesn't specify return format.

  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?

  Two sentences, front-loaded with purpose, then method. No filler or redundant information.

  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?

  No output schema exists, so the description should explain return values. It explains the algorithm but not what fields are returned or whether results are distinct values or actual rows. This is a notable gap for an agent deciding whether to use this tool.

  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 descriptions cover all 6 parameters 100%. The description adds context around sampleSize (sampling server-side, client-side ranking) which explains its effect on result quality. It doesn't add meaning for other parameters, but the schema already explains them well.

  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 ('fuzzy search'), names the resource ('distinct values of a single text column'), and clarifies the goal ('find rows whose value is close...'). It clearly differentiates from exact-match search, 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 Guidelines4/5

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

  It explicitly says 'use this to find rows whose value is close to (but not an exact match for) a search term', providing a clear when-to-use context. It doesn't mention alternatives or exclusions, but the guidance is sufficient for most cases.

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

• list_functionsA
  4.3/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 clearly indicates a read-only listing action, notes the optional schema filter, and adds that the return data type is included. This goes beyond the schema without overstating side effects.

  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?

  Two concise sentences, front-loaded with the core action and resource. The second sentence adds a meaningful detail about return data type without redundancy or filler.

  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?

  This is a simple, low-complexity tool with one optional parameter and no output schema or annotations. The description adequately conveys the listing behavior, optional filtering, and a notable return column, making it sufficiently complete for an agent to select and invoke 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?

  The single parameter 'schema' already has a 100% descriptive schema entry ('Optional schema name to filter by, e.g. 'dbo''). The tool description adds the notion of filtering to a 'single schema' but does not materially extend parameter meaning beyond the schema.

  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 the specific verb 'List' with the resource 'functions in the database', and mentions an optional schema filter. This clearly distinguishes it from sibling tools like list_tables and list_procedures.

  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 clearly states what the tool does and that the schema filter is optional, providing context for when to use it. It does not explicitly name alternatives or exclusion criteria, but the sibling tool names and focused wording make the appropriate use case evident.

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

• query_tableA
  4.4/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 burden of disclosing behavior. It reveals that column and operator are validated against the real schema, and that results are limited to 200 rows. This provides meaningful operational context beyond the raw schema, though it does not detail error handling or return format.

  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 superfluous content. It front-loads the core purpose and key constraints, making it quick to parse and directly informative.

  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 moderate tool complexity (6 params, all documented in schema) and no output schema, the description adequately covers purpose, key limitation (single condition), validation behavior, and row limit. It omits explicit return format details, but for a row-returning query tool this is generally inferable.

  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%, so parameters are fully documented. The description adds semantic value by explaining that column and operator are validated against the real schema, which clarifies execution behavior. It also contextually links column, operator, and value as a single WHERE condition.

  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 ('Select rows') and the specific scope ('from a table with a single WHERE condition'), which distinguishes it from sibling tools like join_tables or browse_table. The use of 'single WHERE condition' explicitly limits the tool's functionality, making its purpose unmistakable.

  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 imparts clear context that this tool is for simple, single-condition queries without explicitly naming alternatives or exclusions. The phrase 'single WHERE condition' implies that more complex queries should use run_query or join_tables, but it does not state this directly.

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

• browse_tableA
  4.5/5.0
  Behavior4/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 key behaviors: 'SELECT TOP N *' implies read-only, 'Max 200 rows' imposes a limit, and 'no filtering' sets expectations. However, it doesn't detail edge cases like missing tables or exact return shape, but for a simple preview tool this is largely sufficient.

  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?

  Single sentence, front-loaded with the core purpose, and provides constraints and differentiation without waste. Every word earns its place.

  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 nature of the tool (preview rows), the description covers the key behavioral constraints (max 200 rows, no filtering) and provides a pointer for filtered needs. The schema fully documents parameters, and no output schema exists, so nothing essential is missing.

  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 coverage is 100%, so parameters are already well-documented. The description adds context that the limit is used as TOP N, but does not add additional meaning beyond the schema's description of the limit (default 50, max 200) and table/schema names.

  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 states the exact action: 'Preview rows from a table (SELECT TOP N *)' – a specific verb and resource. It also distinguishes itself from sibling tools by explicitly noting 'no filtering' and referencing query_table, 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?

  Directly states when to use the alternative: 'use query_table for filtered results.' This clearly delineates when this tool is appropriate (unfiltered previews) and when to choose a sibling for filtering.

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

• run_queryA
  4.6/5.0
  Behavior5/5

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

  With no annotations, the description carries full burden and does so admirably: it discloses read-only enforcement, rejection of multi-statement/write/DDL/EXEC queries before the database, transaction rollback as a second defense, and a 500-row cap. This gives agents precise expectations of safety and limitations.

  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 sentences, front-loaded with purpose, then safeguards and limits. No filler; every clause adds operational value.

  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 covers purpose, allowed syntax, safety mechanics, and result cap, which is substantial for a read-only query tool. It doesn't describe output structure (e.g., row format), but given no output schema is present, a mention of column/row return format would round it out; still, this is a minor gap versus the otherwise thorough disclosure.

  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 has 100% coverage for the single 'query' parameter, but the tool description enriches semantics by elaborating what 'single SELECT' entails (CTE-led, rejection conditions, rollback, row cap). This adds meaning beyond the schema's terse description, though the core parameter semantics are schema-provided.

  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 clearly states it runs arbitrary read-only SQL with a specific verb ('Run') and resource ('raw SQL query'), enumerating supported constructs (CTEs, subqueries, aggregates, window functions, UNION, ORDER BY). It distinguishes from sibling tools by emphasizing arbitrary single-SELECT capability versus specialized table/join tools.

  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 establishes when to use it: for any read-only query expressible as a single SELECT, including advanced SQL. It doesn't explicitly name alternative tools like query_table or join_tables, but the scope implicitly frames it as the general-purpose SQL tool. Lacks explicit exclusions or alternative references, so not a 5.

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