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 correctly indicates this is a read-only diagnostic operation by context ('find violations'), and it explains the conceptual behavior (checks for orphaned records). However, it does not describe what happens when all checks pass (empty result vs. a summary message), whether it reports a count or full row listings, or performance implications of checking ALL tables when table is omitted.

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

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

Two sentences, zero wasted words. The first sentence states the action and the parenthetical explains the concept; the second sentence reinforces the diagnostic value case. Perfectly sized for a single-parameter tool.

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

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

For a single-parameter read-only diagnostic tool with 100% schema coverage, the description is largely complete. It explains what it checks, what the concept means, and adds an example of its practical use. The only minor gap is absence of detail about the output format behavior when no violations exist, but there is no output schema and this is a fairly self-evident diagnostic.

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

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

Schema coverage is 100% and there is only one parameter (table). The description adds meaningful context by explaining that omitting the table checks ALL tables, which supplements the schema. This is a simple tool where the single parameter's semantic meaning is fully conveyed by the schema plus the 'checks ALL tables' clarification.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb (find) and resource (foreign key violations in a table), and even elaborates with a parenthetical explanation of what that means (records referencing non-existent parent rows, orphaned data). It distinguishes itself from siblings like sql_check_nulls by focusing specifically on referential integrity. However, it doesn't explicitly name any sibling alternatives, so it stops short of a 5.

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

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

The description implies when this tool is useful ('diagnosing referential integrity issues') but does not provide explicit when-to-use vs. when-not-to-use guidance, nor does it name any alternative sibling tools. The guidance is clear on the general use case but lacks exclusions or comparisons with overlapping tools like sql_diagnose_issue or sql_inspect_table.

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

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

No annotations are provided, so the description carries full behavioral burden. It implies a read-only SELECT query (finding rows), which suggests non-destructive behavior. However, it doesn't disclose whether it returns all matching rows, respects any limit, which table context it uses, or the result shape. The non-destructive nature is implied but not explicit, and there's no detail on return size or pagination.

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

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

Two sentences, no filler. The first sentence states the action clearly, and the second adds a practical rationale. Every sentence earns its place, though a reader-facing detail like column format or return limit is absent.

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

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

The tool is a query-like operation (SELECT with IS NULL) with two fully-documented parameters and no output schema defined. For a simple data-lookup tool, the description plus schema cover the essentials adequately. However, since there's no output schema, the description could clarify what gets returned (matched row IDs, full rows, counts), and it doesn't address potential large result sets that an agent should anticipate.

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

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

Schema description coverage is 100%, so the schema documents both parameters ($table, $columns) fully. The description adds the intent ('find rows with NULL values') that ties the parameters together, but doesn't add syntax or format details beyond what the schema provides. Baseline 3 is appropriate when the schema carries the parameter documentation burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb+resource: 'Find rows with NULL values in specified columns.' It also adds the purpose ('finding missing/incomplete data that might be causing bugs'). While it doesn't explicitly distinguish from siblings, the verb phrase is specific enough to differentiate from sql_run_query, sql_count_and_sample, etc., most of which have broader or different intents.

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

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

The description implies usage ('useful for finding missing/incomplete data that might be causing bugs') by giving a diagnostic intent. However, it provides no explicit comparison to alternatives like sql_find_data or sql_run_query, nor any when-not-to-use guidance. The use case is stated but no exclusions or alternative selections are given.

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

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

No annotations are provided, so the description carries the full burden. It states it's a read-only comparison of row counts, which implies no data mutation. However, it doesn't disclose return format, whether it handles NULLs in the join, performance considerations on large tables, or what 'missing/extra' means exactly (left vs right outer join semantics). For a tool of this complexity, the disclosure 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.

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

Two sentences, zero waste. Front-loads the action ('Compare row counts between parent and child table'), then adds the purpose ('detect missing or extra records') and use case ('finding data gaps'). Every word earns its place.

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

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

For a 3-parameter tool with no output schema and no annotations, the description is reasonably complete for the selection decision: the agent knows what it does and roughly when to use it. However, given the complexity of count comparison (join semantics, NULL handling, directionality of parent/child), additional behavioral detail would improve completeness for invocation confidence.

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

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

Schema description coverage is 100% and all 3 parameters are documented with examples ('Customers', 'Orders', 'CustomerId'). The description adds context that these are parent/child/FK relationships, complementing the schema. However, the description doesn't add semantic detail beyond the schema's straightforward parameter docs; baseline 3 is appropriate given full coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Compare row counts') and resource ('parent and child table joined by FK'), and its purpose (detect missing or extra records / find data gaps). It distinguishes itself reasonably from siblings like sql_check_foreign_keys (which checks FK integrity, not counts) and sql_find_data. However, it doesn't explicitly name alternatives, so it stops short of a 5.

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

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

The description implies when to use it ('finding data gaps') but doesn't explicitly state when not to use it or name specific alternative tools. For a diagnostics-focused tool among many sql siblings, telling the agent how this differs from sql_check_foreign_keys, sql_count_and_sample, or sql_diagnose_issue would strengthen guidance.

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

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

No annotations are provided, but this is a read-only inspection tool, so the behavioral burden is low. The description notes it 'samples' rows, implying a subset rather than full data, which is useful. However, it doesn't disclose how sampling is performed (random vs first N rows), sample row ordering, or whether the count reflects the filtered set.

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

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

Two concise sentences, zero filler. The purpose and primary use case are front-loaded. It's appropriately compact for the tool's simplicity.

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

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

The tool is simple (3 params, 100% schema coverage, no output schema). The description covers the basics adequately. However, since no output schema exists, the description could have clarified return format (e.g., does it return both count and rows together?), and the sampling method (random vs sequential) is left ambiguous.

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

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

Schema description coverage is 100%, including the WHERE clause example and default sampleSize of 10, so the schema already handles parameter documentation. The description adds minimal value beyond stating the tool counts and samples, providing no extra context about how 'where' interacts with both count and sample.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns a row count and sample rows from a table, with a specific verb (get) and resource (table). It distinguishes from siblings like sql_run_query (full query execution) and sql_inspect_table (schema inspection), though it doesn't explicitly name them.

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

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

The description says it's useful for 'quickly understanding what data exists without writing a full query,' which gives clear use context. However, it doesn't explicitly state when not to use it or name alternative tools like sql_run_query or sql_inspect_table, relying on implicit differentiation.

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

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

No annotations are provided, so the description carries full burden for behavioral disclosure. The description mentions it runs 'counts, NULLs in all columns, FK violations, and recent rows' but doesn't disclose behavioral traits beyond the basic summary — no mention of read-only safety, resource usage on large tables, potential performance impact, or whether it runs write operations. For a 'comprehensive diagnostic' running multiple operations, this is a notable gap.

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

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

Two sentences, efficient and front-loaded with the most useful information (what it does) followed by contextual guidance (when to use). Zero wasted words, though it could arguably mention the output format.

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

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

With no annotations and no output schema, the description does a reasonable job describing what the tool does but leaves gaps: what the output looks like, how it handles large tables, and whether it's read-only are all undisclosed. For a complex multi-check diagnostic tool, a bit more detail about expected output or performance would help.

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

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

Schema coverage is 100% for the single 'table' parameter, which the schema describes as 'Table to diagnose.' The description reinforces that the table is the diagnostic target but adds minimal extra meaning — no guidance on table name format (schema-qualified? quoted?) or whether it accepts views or only base tables.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action ('Run a comprehensive diagnostic on a table') listing the concrete checks performed: counts, NULLs, FK violations, recent rows. It distinguishes from siblings by combining multiple diagnostic checks into one tool, though it doesn't explicitly name competing tools.

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

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

The description explicitly says this is a 'great starting point when you notice something wrong,' giving clear situational context. It implies this is the first tool to try before more targeted ones like sql_check_nulls or sql_check_foreign_keys, though it doesn't name those alternatives or spell out 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.

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

No annotations are provided, so the description carries the full burden. It discloses some behavioral traits: searches across varchar/nvarchar/int columns via the value parameter description. However, it doesn't disclose performance characteristics (full-table scans on large tables), case sensitivity, or exact-match vs substring semantics, which would matter for a search tool.

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

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

The description is two sentences and front-loaded with the core purpose before the usage guidance. No wasted words, though the second sentence about use case is somewhat redundant with the first sentence's 'across all columns' phrase.

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

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

For a 2-parameter search tool with 100% schema coverage and no output schema, the description is reasonably complete. However, it omits key behavioral details that matter for search: whether matching is case-insensitive, whether it's substring or exact match, and potential performance implications of searching across all columns on large tables. The description is adequate but not thorough.

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

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

Schema description coverage is 100%, with both parameters documented in the schema (table format examples, value as text across varchar/nvarchar/int columns). The description adds marginal value by restating the search-across-columns concept, but doesn't go beyond the schema's parameter docs with additional format or behavior details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description has a specific verb ('Search') plus a resource ('a value across all columns in a table'), and clearly states the use case: finding a value when you know it exists but don't know the column. It's a distinctive capability that differentiates from siblings like sql_run_query and sql_count_and_sample, though it doesn't explicitly name alternatives.

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

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

The description explains when to use it ('when you know a value exists but don't know which column it's in'), giving clear context. It relies on the sibling names to imply when not to use it (e.g., sql_run_query for general queries), but doesn't explicitly state exclusions or alternatives.

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

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

No annotations are provided, so the description carries the burden. It discloses that the tool returns an 'estimated execution plan' and mentions it uses SET SHOWPLAN_ALL (implying read-only, non-executing behavior). However, it doesn't disclose that estimate is non-executed, output quirks, or that SHOWPLAN_ALL may be unsupported on some SQL dialects.

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

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

Two sentences, front-loaded with the core action, minimal waste. The parenthetical SET SHOWPLAN_ALL adds useful technical precision. Slightly more could be gained from elaboration, but this is appropriately tight.

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

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

With one parameter, full schema coverage, no output schema, and no annotations, the description is reasonably complete for its simplicity. However, SHOWPLAN_ALL output format is complex text that could benefit from a hint about what the result looks like, and there's no note about non-execution of the query.

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

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

Schema coverage is 100% (the single 'sql' parameter is documented as 'The SELECT query to analyse'). The description reinforces the SELECT-only constraint but adds no meaning beyond the schema. Baseline 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.

Does the description clearly state what the tool does and how it differs from similar tools?

States specific verb+resource: 'Get the estimated execution plan for a SELECT query as text'. The technical detail '(SET SHOWPLAN_ALL)' adds precision, and 'Useful for diagnosing slow queries' contextualizes it among sibling tools like sql_diagnose_issue and sql_run_query. Effectively distinguishes itself.

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

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

Implies usage for slow query diagnosis ('Useful for diagnosing slow queries'), which distinguishes it from execution-focused tools like sql_run_query. However, no explicit exclusions or when-not-to-use guidance given, and no mention of how this compares to alternatives like sql_diagnose_issue.

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

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It states it returns 'the full definition (source code)' which is helpful, but doesn't disclose whether this is a read-only operation, whether it requires special permissions, what happens if the procedure doesn't exist (error vs empty), or whether the output is in a specific dialect. For a read operation with no annotations, some additional transparency would help.

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

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

The description is a single, efficient sentence with zero waste. It's appropriately sized for a simple single-parameter task. Could arguably add a sentence about sourcing names from sql_list_stored_procs, but as-is it's economical and clear.

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

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

The tool is low-complexity (1 param, no output schema, no nested objects), so a minimal description is somewhat acceptable. However, without annotations and with no guidance on prerequisites (e.g., does the procedure need to exist, can it be schema-qualified), and no alternative tool referral, it falls short of fully complete. The lack of any usage guidance leaves the description at minimum viable rather than complete.

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

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

Schema description coverage is 100% (the 'name' parameter has a description), so the baseline is 3. The description adds little semantic value beyond the schema—'Stored procedure name' in the schema sufficiently covers the parameter meaning. The description doesn't clarify edge cases like case-sensitivity, schema qualification, or how to find valid names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb+resource: 'Get the full definition (source code) of a stored procedure.' It's specific about what it returns. However, it doesn't distinguish from sibling tools like sql_list_stored_procs (which lists procedures) and sql_inspect_table (which inspects structures), though the purpose of retrieving source code is distinct enough that sibling differentiation is mostly implicit.

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

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

No guidance on when to use this tool vs alternatives. It doesn't clarify whether the procedure name must be exactly as listed by sql_list_stored_procs, whether it requires a database selection context, or when someone should use sql_inspect_table or sql_get_query_plan instead. The tool name alone suggests its use case but the description adds no explicit context.

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

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 lists exactly what information is returned (columns, keys, indexes, row count), which is good transparency about this read operation. It doesn't explicitly state it's read-only, but the content listing strongly implies inspection rather than mutation. It's a strong disclosure for an inspection tool.

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

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

A single sentence that front-loads the purpose and immediately details the complete output contents. Zero wasted words, zero filler. Every element in the sentence earns its place.

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

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

The tool has only 1 parameter, no output schema, and no annotations. The description compensates effectively by enumerating all return contents (columns, keys, indexes, row count), which addresses the most important unknown for the agent. It's reasonably complete for a simple inspection tool, though it could mention whether there's a limit on row count performance or schema-level vs database-level details.

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

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 single 'table' parameter with a clear example ('Orders' or 'dbo.Orders'). The description explains what is done with that table parameter (shows details about it). This meets the baseline for full-coverage schemas; there's minimal additional semantic value beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Show full details') and resource ('about a table'), enumerating the specific information returned: columns with types/nullability/defaults, primary keys, foreign keys, indexes, and row count. This distinguishes it from siblings like sql_count_and_sample and sql_list_tables, which focus on narrower concerns.

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

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

The description implies when to use this tool (when you need table schema/metadata), which differentiates it from the write/query siblings. However, it doesn't explicitly state when NOT to use it or name alternative tools, and there are no exclusions or prerequisites mentioned. The context is clear but 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.

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. 'List' implies a read-only operation, but the description doesn't state whether this is safe/non-destructive, how many results are returned, what columns/format the output contains, or performance implications for large databases. For a read tool with zero annotation coverage, this is a notable gap.

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

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

The description is a single, concise sentence with zero wasted words. It front-loads the core action and scope clearly. Nothing extraneous exists.

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

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

For a simple one-parameter list tool with 100% schema coverage, the description is mostly adequate. However, with no annotations and no output schema, it could add value by noting the output format or result set characteristics. The tool is straightforward enough that this is a mild gap rather than a critical one.

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

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

Schema coverage is 100% — the single parameter 'filter' is fully described in the schema with a clear example ('Get%'). The description adds no additional meaning beyond the schema, so baseline 3 applies. The schema does the heavy lifting here, and the parameter semantics are adequately covered.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('List'), resource ('stored procedures'), and scope ('in the active database'). It's specific and distinguishes from siblings like sql_get_stored_proc_def, which retrieves a single procedure definition rather than listing all procedures.

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

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

The description implies when to use it (when you need an overview of stored procedures in the database), but it doesn't explicitly contrast with siblings like sql_get_stored_proc_def (for a single definition) or provide guidance on when not to use it. The active-database scoping is stated, which adds context, but no exclusions or alternatives are named.

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

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

No annotations are provided, so the description carries full behavioral burden. It discloses that row counts are included and that views are excluded by default — useful behavioral detail. However, it doesn't disclose whether this is a read-only operation, performance implications of row counts on large tables, or result ordering/limits.

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

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

A single, tightly written sentence that conveys purpose, scope, filtering capability, and one behavioral detail (row counts). Zero wasted words; front-loaded with the primary action.

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

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

This is a relatively simple list tool with full schema parameter coverage and no output schema (so no return format to document). Given its simplicity, the description covers the essential aspects: what's listed, row counts included, and optional views. It could add a note about performance on large databases but is otherwise complete for a listing utility.

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

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

Schema coverage is 100%, so the two parameters (schema, includeViews) are fully documented in the schema. The description adds 'with row counts' context and clarifies views are optional, but doesn't add meaningful semantics beyond what the schema already provides. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb+resource ('List all user tables') and specifies scope ('in the active database, with row counts'). It clearly distinguishes itself from siblings like sql_list_stored_procs and sql_inspect_table by being the table-listing tool specifically.

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

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

The description implies usage — list tables in the active database. It notes views are optional, but does not explicitly state when to prefer this over alternatives like sql_count_and_sample or sql_inspect_table, or when it should NOT be used. No exclusionary guidance given.

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

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

No annotations provided, so the description carries the full burden but does add useful behavioral context: the read-only nature (SELECT only) and the maxRows auto-add TOP N behavior. It doesn't disclose return formatting details, error behavior, or performance considerations, but the core safety profile (read-only) is conveyed.

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

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

Two concise sentences with zero waste. Front-loaded with the primary action, then immediately the critical constraint and alternative for writes. Every sentence earns its place.

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

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

For a query execution tool with 2 fully-documented parameters and no output schema, the description adequately covers usage. It captures the key behavioral traits (SELECT-only, row limits). Minor gap: it doesn't mention whether results are tabular, JSON, or another format, though this is arguably minor for a simple query tool.

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

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

Schema description coverage is 100%, so the schema documents both parameters fully. The description adds the behavioral note that 'Query will auto-add TOP N if not present' for maxRows, which is slightly beyond the schema. Baseline 3 is appropriate since schema handles parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clear verb+resource: 'Execute a SELECT query against the configured SQL Server database and return formatted results.' It explicitly restricts to SELECT statements, distinguishing it from the write sibling (sql_run_write). Differentiates from inspection/analysis siblings by focusing on raw query execution.

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

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

Explicitly states 'Only SELECT statements are allowed here — for writes, use sql_run_write.' This gives clear when-to-use vs when-not-to guidance with a named alternative. However, it doesn't discuss when to prefer this over other read tools like sql_find_data or sql_count_and_sample, though the read vs query distinction is largely self-evident.

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

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 clearly discloses the destructive/mutating nature of the tool, explains the dry-run behavior when confirm=false vs actual execution when confirm=true, and emphasizes the safety gate. The only minor gap is not describing the return format or what the preview output looks like.

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

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

The description is well-organized with a clear header, bolded permission rule, and bulleted sub-points. The protocol for confirm usage is front-loaded and emphasized. Minor redundancy exists between the schema description and the description's confirm explanation, but the description's value-add justifies the length for a high-risk destructive tool.

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

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

For a high-risk mutating tool with no annotations and no output schema, the description is thorough: it enumerates supported statement types, explains the two-phase execution safety mechanism, and details the confirm flag semantics. It handles the risk profile exceptionally well, leaving little ambiguity for an agent deciding how and when to invoke it.

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

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

Schema coverage is 100%, so the schemas document both parameters, but the description adds substantial value beyond the schema. It explains the critical behavioral difference of the confirm parameter (dry-run vs execute) in detail, including the exact protocol for safely invoking it. This goes well beyond the schema's 'Set to true ONLY after preview and approval'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb (Execute) plus resource (write SQL statement) and enumerates the exact statement types (INSERT, UPDATE, DELETE, DROP TABLE, ALTER TABLE, CREATE, TRUNCATE, EXEC stored proc). It clearly distinguishes from sql_run_query (read) and other sibling tools like sql_list_tables/sql_inspect_table which are structural inspection tools.

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

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

The description includes an explicit two-phase usage protocol: always call with confirm=false first to show a dry-run preview, then call with confirm=true only after explicit user approval. This is exceptionally clear operational guidance that prevents accidental destructive actions and directly addresses when this tool should be used vs alternatives.

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