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

No annotations are provided, so the description must disclose behavioral traits. It mentions what outputs to expect but does not state whether the operation is read-only, whether it modifies anything, or whether it requires specific permissions or connectivity to both databases. This is a significant gap for a tool with no annotation safety hints.

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 with the core purpose front-loaded and a practical example in parentheses. Only a minor issue: the em dash and parentheses are slightly informal, but the text is efficient and free of fluff.

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 tool with no output schema and no annotations, the description is moderate. It specifies what differences are shown (tables, columns, indexes) but omits details on return format, error cases, prerequisites (e.g., server access), or any side effects. Given the tool's complexity (comparing two databases), more context would improve completeness.

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 each parameter. The description adds minimal parameter-specific meaning; it mentions comparing schemas but does not clarify how the parameters (schema filter, server) interact. Baseline 3 applies because the schema handles parameter documentation adequately.

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 verb 'compare' and resource 'schemas between two databases' are specific, and the description lists concrete outputs (tables, columns, indexes that differ). It clearly differentiates from sibling tools like list_schemas or describe_table by focusing on cross-database differences and the dev vs prod use case.

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 provides a context ('useful for dev vs prod comparison') that implies when to use it, but it does not explicitly state when not to use it or mention any alternative tools. It gives a clear scenario but lacks routing away from siblings.

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 clearly implies a read-only operation ('Get'), which is transparent. However, it doesn't mention any limitations, error behavior, or permission requirements—acknowledge that these are minor for a simple read operation.

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, efficient sentence that directly states what the tool does without any filler. It is front-loaded and leaves no room for ambiguity.

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?

Given the tool's moderate complexity (4 parameters, only 1 required) and the lack of an output schema, the description adequately covers what the tool does. It could mention that source code is returned as text or provide a sample output, but the current description is sufficient for an agent to know what to expect.

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 all four parameters are already documented in the input schema. The tool description does not add any extra meaning about the parameters (e.g., format, constraints, or how they interact), but that is not strictly necessary given the high 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?

The description states a specific verb ('Get') and resource ('stored procedure'), and clarifies exactly what is returned (parameter information and source code). This clearly distinguishes it from sibling tools like list_procedures, describe_table, or get_query_plan.

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 purpose is clear enough to imply when to use it (when you need details of a specific procedure), but no explicit guidance is given about when not to use it or which alternatives to prefer. No sibling tools are mentioned, so the agent must infer usage from 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?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states 'Get' which implies a read-only operation, but it does not explicitly state that it makes no modifications, requires no special permissions, or has no side effects. It also does not discuss how defaults are resolved beyond what the schema already covers. This is a notable gap for a tool with zero annotation support.

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 that front-loads the primary action and immediately lists the scope of returned data in parentheses. There is no redundant language, and every word contributes to clarifying the tool's function. Structure is excellent.

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 read-only metadata tool with one required parameter and no output schema, the description is mostly complete. It specifies the resource type (table or view) and enumerates the details returned. It does not mention potential errors or performance implications, and because there are no annotations, it could better clarify that it is a non-mutating operation. Overall, it covers the essential aspects an agent needs to call it correctly.

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?

The input schema already provides descriptions for all four parameters (100% coverage), including the default schema behavior. The tool description adds no extra meaning to the parameters—it merely lists the returned information. Since the schema covers semantics completely, a baseline score of 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 ('Get') and clearly identifies the resource ('a table or view'), and enumerates the exact information returned (columns, types, defaults, nullability, identity, computed). This distinguishes it from describe_procedure and other schema tools like get_indexes or get_constraints. The purpose is unambiguous and specific.

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 it is meant for tables and views, but does not explicitly state when to use it versus alternatives. It does not mention that describe_procedure should be used for stored procedures, nor does it provide conditions for choosing this tool over other metadata tools. The context is clear but exclusionary guidance is absent.

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, the description carries the full burden. It discloses the tool is read-only and that row limits are auto-applied, which is useful. However, it does not mention error behavior, return format, or any side effects, leaving some behavioral ambiguity.

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 sentence that packs two key behavioral points (read-only and row limits) with no filler. It is front-loaded and efficient, earning a top score for conciseness.

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 description covers the critical constraints (read-only, row limits) and the schema documents all parameters. However, since there is no output schema, the description does not state what the tool returns (e.g., result set format, pagination), leaving a gap in complete understanding for the agent.

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 fully documents all three parameters. The description adds context about read-only and row limits but does not add any parameter-specific meaning beyond the schema, which aligns with the baseline of 3.

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 specific verb (execute) and resource (SQL SELECT query), and qualifies it as read-only and automatically applying row limits. It is clear and distinct from the sibling tools, which are all specialized read-only inspection tools, 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?

No guidance is given on when to use this tool versus the many sibling tools. Since it's the only general SQL executor among siblings, the intended use is implied, but there is no explicit when/when-not guidance or statement of 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?

With no annotations, the description carries the full burden. It states the query type (SELECT) which implies a read-only operation, but it does not disclose any other behaviors such as output size limits, server connection handling, or error behavior. The description is minimal but not misleading; it gives the core behavior without added nuance.

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, clear sentence with no redundant words or filler. It states the action and the key output types upfront, making it efficient and easy to scan.

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?

Given the tool has 4 parameters, no annotations, and no output schema, the description is too sparse. It does not clarify how this tool relates to execute_query, what the exact structure of the returned CSV/JSON is, or any constraints (e.g., row limits, transaction behavior). An agent would lack key information needed to call it correctly and interpret results.

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 all parameters are documented in the schema. The description does not add extra meaning beyond the schema; it essentially restates the format parameter. Since the schema already defines each parameter clearly, the description adds no additional semantic value.

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 executes a SELECT query and returns results in CSV or JSON format. The verb 'execute' and resource 'query' are specific, and the format mention distinguishes it from raw query execution. However, it does not explicitly differentiate from sibling execute_query, so it's clear on what it does but not why it's distinct.

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 is provided on when to use this tool versus alternatives like execute_query. It does not state that this tool is preferred when format conversion is needed or that execute_query returns default format. The description only describes the action without context for selection.

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 only states the purpose ('Generate ... from a table's schema') but does not disclose whether the operation is read-only, whether it requires specific permissions, or any side effects. For a tool that likely reads schema metadata, this is a significant omission.

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, front-loaded sentence with zero waste. It states the verb, resource, and outputs without any redundant filler. This is an example of concise, efficient writing.

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 5 parameters, no annotations, and no output schema, the description is too minimal. It does not explain the return format (e.g., string code), any prerequisites (e.g., existing table), or how the inputs relate. An agent would need to guess at the interaction between table and schema parameters or the nature of the output.

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 all parameters are already documented in the schema. The description adds no extra meaning beyond what is in the schema; it only refers generically to 'table's schema' without elaborating on how server, database, or schema parameters interplay. Baseline 3 applies because the schema carries the weight.

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 verb 'Generate' and resource 'from a table's schema', and explicitly lists the three output types (TypeScript interface, C# class, CREATE TABLE script). This distinguishes it from sibling tools like generate_insert_scripts, generate_er_diagram, and generate_test_data, which produce different artifacts.

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 the tool (when code artifacts are needed from a schema) but does not explicitly state when not to use it or name alternatives. Unlike the calibration example that names a sibling and its condition, this description relies on the agent to infer selection without exclusion 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, so the description carries the full burden. It implies a read-only operation (generating a diagram) and indicates the source (foreign key relationships), which is useful. However, it doesn't disclose potential limitations (e.g., missing foreign keys, empty result) or explicitly confirm no side effects, though 'generate' strongly suggests non-mutating behavior. This is adequate 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.

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

The description is a single, concise sentence that front-loads the core action ('Generate') and object ('Mermaid ER diagram'), followed by the source. It contains no fluff or redundancy, and the structure is optimal for quick comprehension.

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?

Given the tool's simplicity—three optional parameters, no output schema, no nested objects—the description is reasonably complete. However, it doesn't mention edge cases (e.g., behavior when no foreign keys exist) or explicitly state the output format (though 'Mermaid ER diagram' implies text). It also doesn't note that parameters are optional and defaults are used. While functional, it lacks a few details an agent might need for confident invocation.

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 all three parameters (schema, server, database) are already documented in the schema. The description adds no additional meaning or syntax details beyond what the schema provides. Per the baseline for high coverage, a score of 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 clearly states the tool's function: generating a Mermaid ER diagram based on database foreign key relationships. It uses a specific verb ('Generate') and resource ('Mermaid ER diagram'), and the source is explicit. While it doesn't mention sibling differences, the purpose is distinct enough that an agent can infer when it applies, differentiating from tools like get_foreign_keys (which lists relationships) or compare_schemas (which compares).

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 usage guidance is provided. The description doesn't specify when to use this tool over alternatives, nor any exclusions or prerequisites (e.g., 'Use this when you need a visual representation of relationships'). It only states what it does, leaving the agent to infer applicability.

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 disclosing behavior. It only states that it generates INSERT statements from existing table data, but does not mention that it is read-only, whether it has performance implications, or what happens with large tables. The tool appears to be a read operation, but this is not explicitly stated.

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 that states the purpose and use case without redundant detail. It is front-loaded with the action and resource, making it easy to scan quickly.

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?

Given the simplicity of the tool and that all parameters are schema-documented, the description is largely complete for an agent to understand what the tool does. However, because there is no output schema, the description might have mentioned what the tool returns (e.g., the generated scripts as text) to fully close the loop, though it is reasonably implied by the purpose.

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?

The schema description coverage is 100%, so all five parameters (table, top, schema, server, database) are already documented in the schema. The tool description adds no additional meaning about parameters, such as default behaviors or relationships between them, so it does not exceed the baseline.

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 'Generate' and the specific resource 'INSERT statements from existing table data,' which is unambiguous. The parenthetical '(for migration/seeding)' adds a concrete use case that helps distinguish it from siblings like generate_code or generate_test_data.

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 mentions the intended use case (migration/seeding), which gives a clear context. However, it does not name any alternative tools or explicitly state when not to use this tool, so it falls short of a 5. The context itself is enough to infer this is for copying existing data rather than generating new data.

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 states it generates INSERT statements but does not clarify whether these are returned as text or executed directly against the database. It also omits any mention of permissions, side effects (e.g., whether it writes to disk), or whether it requires an active connection. This ambiguity could lead an agent to misuse the tool (e.g., expecting execution when it only generates).

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, focused sentence with no extraneous content. It immediately communicates the core action and basis, making it easy to parse and front-loaded. No wasted words.

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 five parameters and no output schema, so the description should explain what the tool returns (e.g., a SQL string, a file path) and how parameters like server/database are used during generation. It also does not mention any constraints (e.g., whether the table must exist, handling of foreign keys). For a moderately complex tool with zero annotations and no output schema, this description leaves significant gaps that could hinder correct invocation.

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?

The schema description coverage is 100%, meaning all five parameters have descriptions. The tool description itself does not add meaning beyond what the schema provides; it merely reiterates that data is generated based on the table schema. Since the baseline for high coverage is 3, and the description offers no additional context about parameter interactions or edge cases, a score of 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 clearly states the tool's function: generating INSERT statements with realistic fake/test data based on the table schema. It specifies the verb, resource, and basis, and distinguishes it from sibling tools like generate_insert_scripts (which likely generate based on existing data) and sample_table (which might return raw data rather than SQL).

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 provides no guidance on when to use this tool versus alternatives such as generate_insert_scripts or sample_table. It does not mention any prerequisites (e.g., table existence, needed permissions) or exclusions. The only hint is that it generates fake data, implying a testing scenario, but this is not explicitly stated or contrasted with siblings.

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?

Since no annotations exist, the description carries the full burden of behavioral disclosure. It mentions reading from a system view, implying a read-only operation, but does not explicitly state this, nor does it describe the output format, potential row limits, or any performance considerations. The description is too minimal to fully inform the agent about execution effects.

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, front-loaded sentence that efficiently conveys the core purpose without filler. Every word contributes to the tool's function. This is an exemplary level of conciseness, even if other dimensions lack detail.

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 tool with no output schema and one optional parameter, the description is minimally adequate for what the tool does, but it omits context like what the returned query information includes (columns, limits, ordering). Sibling tools such as get_query_store_stats and get_wait_stats are closely related, and without usage guidance, an agent may struggle to choose correctly. Given the tool's low complexity, a 3 is fair.

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% with a single optional parameter 'server' already documented as 'Target server name (uses default if omitted)'. The description adds no further meaning beyond this. Per the baseline for high schema coverage, this is acceptable, though no extra context about how server selection affects results is provided.

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 ('Show'), resource ('currently running queries'), and even identifies the underlying system view (sys.dm_exec_requests). This makes the tool's purpose unambiguous and distinct from most siblings, though it does not explicitly differentiate from get_query_store_stats or get_wait_stats.

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 provides no guidance on when to use this tool versus alternatives like get_query_store_stats or get_deadlocks. No exclusions, prerequisites, or typical use cases are mentioned. The agent must infer appropriateness from the name alone.

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

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 indicates a read operation against msdb, but does not mention permission requirements, error behavior, whether the operation is truly read-only, or any side effects. The word 'Get' implies a safe read, but the description itself does not explicitly state safety or disclose potential behaviors like requiring the database to exist or the meaning of 'recent'.

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 that is front-loaded with the main action and resource. There is zero wasted wording, making it highly efficient.

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 tool with 3 optional parameters and no output schema, the description is incomplete. It does not describe the return format, whether it returns a list, the structure of the backup history, or any limitations. An agent would lack the context to interpret the response or anticipate failure modes, making the description inadequate for a tool of this complexity.

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 all three parameters already documented in the schema. The description adds no extra meaning beyond the schema—it merely states the tool returns 'recent backup history', which is already implied by the 'top' parameter's description. Baseline 3 is appropriate since the schema does the heavy lifting.

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 action ('Get'), the resource ('recent backup history'), and the source ('from msdb'). It is a specific and unambiguous purpose that distinguishes it from all sibling tools, none of which deal with backups.

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 gives no explicit guidance on when to use this tool versus alternatives or when not to use it. While the naming and purpose make it obvious this is for backup history, it lacks any stated context about prerequisites, alternatives, or exclusions. Usage is implied rather than stated.

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 implies a read-only operation ('Show') but doesn't disclose any side effects, permissions, or return format. It adds minimal behavioral context beyond the title, so it falls short for a monitoring 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 a single, well-structured sentence with no fluff. The core action and subject are front-loaded, and every word contributes to meaning.

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 tool with one optional parameter and no output schema, the description gives a high-level idea of what's returned (blocking chains) but omits details like output format, potential errors, or whether it requires specific permissions. It's adequate but leaves some gaps for an agent deciding to call 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?

The schema already provides full coverage (100%) with a description for the single optional 'server' parameter. The description adds no additional meaning beyond what's in the schema, so the baseline of 3 applies.

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 specific verb ('Show') and a clear resource ('current blocking chains'), and clarifies what that means ('which sessions are blocking others'). This distinguishes it from sibling tools like get_active_queries and get_deadlocks, though it doesn't name them explicitly.

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 gives no guidance on when to use this tool versus siblings. There's no mention of alternatives, conditions, or when this tool is preferable (e.g., for identifying blocking chains vs. individual deadlocks).

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, the description must carry all behavioral disclosure. It only states the operation and does not mention read-only nature, output format, error handling, or whether results are aggregated or paginated. This is a minimal disclosure for a read 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 a single, concise sentence with no fluff. It front-loads the key action and resource, and the parenthetical list adds precise scope without excess length.

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 read tool with no output schema and no annotations, the description is adequate but not rich. It clarifies scope (constraint types) but does not mention constraints like foreign keys (which have a sibling tool), nor does it indicate the return shape or any prerequisites. It is minimally complete for an agent familiar with the domain.

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 all four parameters are documented with descriptions. The tool description adds no additional meaning beyond 'for a table', but the schema already explains table, schema, server, and database. The baseline of 3 is appropriate since the schema carries the semantic load.

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 ('Get') and resource ('constraints for a table'), enumerating the constraint types (PK, unique, check, default). It distinguishes from siblings like get_foreign_keys and get_indexes by being the general constraints tool, though it doesn't explicitly call out that distinction.

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 is provided on when to use this tool versus alternatives such as get_foreign_keys, get_indexes, or describe_table. The agent must infer from the name and sibling names, which is insufficient for new users or complex decision points.

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 disclosing behavioral traits. It states the output includes size, files, status, and recovery model, but does not mention whether the operation is read-only, if special permissions are required, if there are performance implications, or what happens when parameters are omitted. This is minimal disclosure for a standard read operation.

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, compact sentence that front-loads the primary purpose ('Get detailed database information') and then lists the key output fields. There is no redundant repetition or stray text, making it efficient and easy to parse.

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 relatively simple read tool with two optional parameters and no output schema, the description covers the primary return values but omits any usage context, such as which sibling tools are alternatives or how results are shaped (single record vs. list). Without annotations, 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?

The input schema has 100% coverage: both 'server' and 'database' have descriptions indicating they are optional and fall back to defaults. The tool description adds no further parameter semantics beyond what the schema already provides. Since coverage is high, a baseline of 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 states a clear verb ('Get'), a resource ('database information'), and enumerates specific details (size, files, status, recovery model). This distinguishes it from siblings like list_databases or get_server_info, though it does not explicitly call out the distinction for the agent.

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 provides no guidance on when to use this tool versus alternatives such as get_server_info or list_databases. There is no mention of prerequisites, context where this is preferred, or exclusions. The usage is only implied by the tool's name and description.

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 disclosing behavior. It only says 'get recent deadlock events' and does not explain whether it is read-only, what the return format is, how 'recent' is defined, or any permission requirements. This thin description does not meet the baseline for a tool with zero annotation support.

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 no wasted words. It conveys the essential purpose without any fluff, making it easy to parse quickly.

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 output schema, the description should explain what the tool returns (e.g., format, time range). It does not mention the output format or define 'recent', which could cause an agent to make incorrect assumptions. However, the tool's complexity is low, so the gap is moderate rather than severe.

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?

The only parameter 'server' is fully described in the input schema ('Target server name (uses default if omitted)'). The tool description adds nothing about parameters, but since schema coverage is 100%, the baseline of 3 applies.

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 verb ('get'), a resource ('deadlock events'), and the source ('system_health Extended Events session'). This unambiguously distinguishes it from all siblings, none of which target deadlocks. An agent knows exactly what this tool retrieves.

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 context is clear: use this to obtain deadlock events. No exclusions or alternatives are explicitly mentioned, but none of the siblings provide equivalent functionality, so the usage is fairly obvious. It lacks an explicit 'when not to use' but is sufficient for selection.

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 disclosing behavior. It only states the action ('Get foreign key relationships') without noting whether it is read-only, whether it requires specific permissions, or how it handles missing tables or invalid inputs. No side effects or return details are mentioned.

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 no fluff, but it lacks any structural detail or additional context. It is appropriately short for a simple read tool, yet it omits any explanation of the returned data or usage nuances, making it feel under-specified rather than elegantly minimal.

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?

Given the lack of annotations and output schema, the description should be more informative. It does not explain return format, behavior on empty results, or how the server/database parameters interact. For a database tool with several optional parameters and no explicit safety notes, this is incomplete for an agent to invoke confidently.

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?

The input schema has 100% description coverage, and the parameter descriptions are clear (e.g., 'Table name', 'Schema name (default: dbo)'). The tool description itself adds no extra meaning beyond what the schema already provides, so it meets the baseline for high coverage but does not enhance parameter understanding.

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 ('Get') and resource ('foreign key relationships for a table'), which is specific and understandable. However, it does not differentiate from siblings like get_constraints or get_indexes, so an agent might not know which is best without deeper inspection.

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?

There is no guidance on when to use this tool versus alternatives (e.g., get_constraints for broader constraint information). No mention of prerequisites, context, or exclusions, leaving the agent to infer usage from the name alone.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states the action ('get') and does not mention side effects, permissions, output format, or any caveats. It adds minimal context beyond the tool name, though it does clarify the table scope.

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 sentence with no filler. It is appropriately sized and front-loaded with the verb and resource. Perfectly concise for its minimal content.

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?

Given the tool has four parameters (one required) and no output schema, the description is too sparse. It doesn't indicate what the returned index information includes, whether it's a list or detail, or any formatting. The schema covers parameters but the description lacks operational context that an agent would need to fully understand the tool's behavior.

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?

The input schema provides 100% parameter documentation, so the baseline is 3. The description adds no additional parameter context beyond implying a table is needed, which is already in the schema.

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 ('Get') and resource ('index information') with a scope ('for a table'), which distinguishes it from sibling tools like get_foreign_keys or get_constraints. It is not a tautology and adds mild specificity, though it doesn't explicitly contrast with get_index_usage or get_missing_indexes.

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?

There is no guidance on when to use this tool versus alternatives, no mention of prerequisites, and no exclusions. The description simply states what it does, leaving the agent to infer context from the name and siblings.

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 must carry the full burden of behavioral disclosure. It names the DMV source, which hints at read-only behavior, but it doesn't clarify whether the tool returns one row per index or an aggregate, whether it reflects cumulative counts since last server restart, or whether it requires elevated permissions (since sys.dm_db_index_usage_stats is a system view often accessible to VIEW SERVER STATE). These gaps leave the agent uncertain about the output format and 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.

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

The description is a single, information-dense sentence that front-loads the purpose and immediately lists the four metrics. The parenthetical about the DMV source is useful and not wasted. There is no redundancy or filler, making it an ideal length for quick parsing by an agent.

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?

There is no output schema, so the description must explain what the tool returns. It lists four counters but does not state the structure (e.g., whether results are grouped by index, whether index name and database are included, or whether all indexes on the table are listed). It also omits that the 'table' parameter is required (though the schema shows it). An agent cannot fully predict the output shape, which is a significant gap for a statistics 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%—each parameter has a short description (table name, schema name with default, server name, database name). The tool description adds no extra meaning beyond those schema descriptions. Per the rubric, with high coverage the baseline is 3, and since there is no additional parameter-specific information, a 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 clearly states the verb (Get) and resource (index usage statistics) and specifies the exact metrics (seeks, scans, lookups, updates) and the source (sys.dm_db_index_usage_stats). This distinguishes it from siblings like get_indexes (which lists index definitions) and get_missing_indexes (which suggests new indexes). It loses a point because it doesn't explicitly say it's per-table, though that's inferred from the required 'table' parameter.

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 gives no guidance on when to use this tool versus alternatives like get_table_stats, get_missing_indexes, or get_indexes. It doesn't mention any prerequisites (e.g., requires table name) or exclusions (e.g., not for missing index suggestions). An agent must infer from the name and parameters when this is appropriate, leaving room for misrouting.

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, the description must carry behavioral info, but it only states the purpose. It does not disclose whether the operation is read-only, whether it requires special permissions, what output format to expect, or any side effects. This is a significant gap for a diagnostic 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, grammatically correct sentence that gets straight to the point with zero waste. It is appropriately short for a simple tool, though it could add just one clause about usage without harming conciseness.

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 one-parameter read-only diagnostic with many siblings, the description lacks usage context and output expectations. It is adequate for invoking the tool but incomplete for choosing it over alternatives or anticipating its result.

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 the single 'server' parameter is fully described in the schema ('Target server name (uses default if omitted)'). The tool description adds no extra parameter details, so the baseline 3 applies.

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 ('Show') with a clear resource ('long-running open transactions') and adds context ('may be holding locks'). This clearly distinguishes it from sibling tools like get_active_queries or get_blocking_chains without needing to enumerate 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?

There is no guidance on when to use this tool versus the many diagnostic siblings (e.g., get_blocking_chains, get_wait_stats, get_deadlocks). The description implies a use case but provides no explicit context, prerequisites, or exclusions.

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 must communicate behavioral traits. It only states the data source (DMVs), which implies a read-only query, but does not explicitly confirm it is non-destructive, explain any performance impact, or disclose what exactly is returned. Without annotations, this is a significant gap for an operation that might be expected to be safe.

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 that front-loads the core purpose. It avoids unnecessary words and is easily scannable. It earns a 4 for efficiency, though it could be slightly expanded to include usage hints without becoming verbose.

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?

Given the tool has no output schema and no annotations, the description should provide more context about return values, limitations, or usage scenarios. It simply states what it does without mentioning that it is SQL Server-specific, what fields are returned, or any constraints. This is insufficient for an agent to fully understand the tool's behavior, though the simplicity slightly mitigates the impact.

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%, meaning both parameters (server and database) are already documented with descriptions in the input schema. The description adds no further parameter context, but the schema carries the burden. Baseline 3 is appropriate since no additional value is provided.

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 retrieves missing index suggestions from SQL Server DMVs, with a specific source (sys.dm_db_missing_index_details). It distinguishes from siblings like get_indexes by focusing on missing indexes, though it doesn't explicitly name alternatives. The verb 'get' and resource are specific.

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 is provided on when to use this tool versus alternatives like get_indexes or other diagnostic tools. There is no mention of prerequisites (e.g., requires SQL Server, connection setup) or scenarios where it is appropriate. The description offers no context for selection.

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 correctly states the key non-destructive behavior (no execution) but does not mention any privileges required, potential performance cost, or error behavior on invalid SQL. This is adequate for a read-only estimation but lacks additional context.

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 leads with the key action and resource, followed by the important qualifier 'without executing it'. There is zero wasted text — every word earns its place, making it highly efficient and front-loaded.

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 analysis tool with three well-documented parameters and no output schema, the description covers the core purpose and behavior. Minor gaps like output format or assumptions about SQL validity are not critical for invocation, but a slightly more detailed hint about the expected return would push this to a 5. Overall, it is sufficiently 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 coverage is 100% and each parameter already has a descriptive name and purpose (sql, server, database). The description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate; it neither improves nor degrades the parameter understanding.

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 'Get' and the resource 'estimated execution plan for a SQL query', and explicitly clarifies 'without executing it' — this distinguishes it from sibling tools like execute_query and conveys exactly what the tool does. The purpose is specific and unambiguous.

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 phrase 'without executing it' provides clear context that this tool is for analysis rather than execution, implying when to choose it over execute_query. However, it does not explicitly name alternatives or state when NOT to use it, leaving some inference to the agent.

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 only mentions the prerequisite but does not state that this is a read-only operation, what the return payload looks like, whether it could be resource-intensive, or any permission requirements. This lack of behavioral context is a significant 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 brief and efficient: one sentence stating the tool's purpose and a second sentence for the prerequisite. It is front-loaded with the action and resource. No wasted words or redundant information. It meets the conciseness ideal.

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?

Given the tool's moderate complexity (4 params, no output schema), the description is minimally sufficient but lacks details about the return format or any hints about the nature of 'top resource-consuming queries'. It does not explain what metrics are included or how results are presented. While the schema covers parameter semantics, the description leaves the result structure undefined, which could cause agent uncertainty.

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 all four parameters (top, server, sort_by, database) are already documented in the schema. The description does not add any extra meaning or usage details beyond the schema, which is acceptable per the baseline rule. It does not compensate for any gaps because there are none.

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 'get', the resource 'top resource-consuming queries from Query Store', and the product version (SQL Server 2016+). This distinguishes it from siblings like get_query_plan (single query plan) and get_active_queries (current running queries). The purpose is unambiguous.

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 provides a clear prerequisite ('Query Store must be enabled') which gives context on when the tool is applicable. However, it does not explicitly mention alternatives or when not to use this tool, though the sibling list includes other query-related tools that might be competitive. The prerequisite is useful but not a full usage guide.

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 does transparently list the information returned (version, edition, OS, memory, CPU), which indicates a read-only inspection. However, it does not explicitly state that no side effects occur, nor does it mention any authentication requirements, rate limits, or error conditions. For a simple info retrieval tool, this is adequate but not rich.

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

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

The description is a single, tightly worded sentence that leads with the core action and resource, then lists the key output fields. It contains zero filler and is fully front-loaded, making it easy for an agent to parse quickly.

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?

Given the tool's low complexity (one optional parameter, no output schema, and no annotations), the description provides sufficient context: it names the resource and the return fields. It does not explain formatting, error handling, or behavior on missing servers, but these are minor gaps for a simple info retrieval tool. The description is complete enough for an agent to invoke it correctly in most cases.

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?

The input schema already has a complete description for the only parameter ('server' with 'Target server name (uses default if omitted)'), giving 100% schema description coverage. The tool description adds no additional context about the parameter, so a baseline score of 3 is appropriate—the schema alone covers parameter semantics.

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 ('Get'), a specific resource ('SQL Server instance information'), and enumerates the exact data fields returned (version, edition, OS, memory, CPU). This makes the tool's purpose unambiguous and distinct from sibling tools like get_database_info or get_active_queries, which target different levels.

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 offers no explicit guidance on when to use this tool versus alternatives. It does not mention exclusions, such as 'use get_database_info for database-level details,' nor does it state any prerequisites or conditions. The context is implied by the name and field list, but there is no explicit routing to help an agent choose among siblings.

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 at all, the description carries the full burden of behavioral disclosure. It only says 'Get detailed disk space usage' but does not explain that it is a read-only operation, whether it requires special permissions, what the return structure looks like, or if it has any performance implications. This is a significant gap for a diagnostic 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 a single, front-loaded sentence with no extraneous words. It effectively communicates the core action, though it is brief to the point of under-specification.

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?

Given that there is no output schema, no annotations, and a large set of sibling tools, this description is incomplete. It does not clarify what 'detailed' entails, whether the output is aggregated or per-table, or any ordering/limitations. An agent lacks sufficient context to call it correctly or differentiate it from similar diagnostics.

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?

The input schema already describes all three parameters (top, server, database) with 100% coverage. The description adds no extra meaning or nuance about parameter usage, so it earns the baseline score of 3 without any additional value.

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 'get' and the resource 'detailed disk space usage by table in a database', which is specific enough to distinguish it from siblings like get_table_stats or get_index_usage. However, it does not explicitly name alternatives or edge cases, so it falls 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?

There is no guidance on when to use this tool versus the many sibling diagnostic tools. It neither states a preferred scenario nor excludes any. The implied use case from the description alone is insufficient for an agent to select it confidently among get_table_stats, get_index_usage, or get_wait_stats.

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 burden of behavioral disclosure. It does disclose the output fields, implying a read-only operation, but doesn't state side effects, permissions, or performance implications. Given the simplicity of the tool, the disclosure is adequate but not comprehensive.

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 sentence that front-loads the tool's purpose and immediately lists the specific statistics returned. There is zero redundant or vague language, making it concise and well-structured.

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?

Given that there is no output schema, the description compensates by explicitly listing the return values (row count, total size, index size, fragmentation). Parameters are fully covered by the schema. The description is complete enough for an agent to call the tool with confidence, though it lacks nuances like whether the statistics are current or cached.

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 all four parameters are documented in the schema. The description adds no additional meaning about parameters (e.g., formats, defaults, or constraints), so it meets the baseline of 3 without exceeding it.

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 specific verb ('Get') and resource ('table statistics') and lists the exact statistics returned (row count, total size, index size, fragmentation). This distinguishes it from vague tools, though it doesn't explicitly differentiate from siblings like 'get_space_usage' or 'get_index_usage' that overlap in scope.

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 is provided on when to use this tool versus alternatives. There is no mention of scenarios where a different stats tool would be more appropriate, nor any prerequisites or limitations. The description simply states what it does without contextualizing selection.

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, the description bears full responsibility for behavioral disclosure. It only states a read operation ('get') but does not specify what triggers are returned (names vs. full definitions), whether any permissions are required, or how the server/database/schema defaults behave. Minimal disclosure beyond the obvious.

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, clear sentence with zero waste. The purpose is front-loaded and easy to parse. It could incorporate a bit more context without sacrificing brevity, but the current form is appropriately minimal.

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 tool with 4 parameters and no output schema, the description is thin. It doesn't explain what the response format will be, any behavioral nuances, or situational context. Without annotations or an output schema, the agent lacks critical information for confident invocation, making completeness inadequate.

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 each parameter is already documented with its role (e.g., table, schema default dbo, server/database optional). The description adds no parameter-specific meaning beyond what the schema provides, so the baseline of 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?

States a specific verb (get) and resource (triggers) scoped to a table. The phrase 'defined on a table' clarifies the exact subject, making the tool easily distinguishable from siblings like get_indexes or get_constraints, even without explicit differentiation.

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 versus alternatives. It doesn't mention prerequisites, when it's appropriate (e.g., when exploring table metadata), or exclude scenarios where other tools would be more suitable. The agent must infer usage from the name alone.

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

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 does not state whether the tool is read-only, requires special permissions, has side effects, or what the return format looks like. The phrase 'Get' implies a read operation but does not explicitly confirm safety or performance impact.

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 that is front-loaded with the core function and immediately followed by the value proposition. There is no redundancy or extraneous detail; 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 simple get-style tool with no output schema and fully described parameters, the description is adequate but not complete. It lacks behavioral context (safety, return format) and does not clarify how wait stats relate to other performance diagnostics. Given the sibling ecosystem, a bit more context would help an agent decide appropriately.

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?

The input schema provides full coverage (100%) for both parameters with clear descriptions: 'top' explains default value, 'server' explains fallback behavior. The tool description adds no additional parameter context, but since the schema is complete, the baseline score of 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 states 'Get top server wait statistics' which clearly identifies the verb and resource, and adds the purpose of identifying performance bottlenecks. It is distinct from sibling tools like get_query_store_stats or get_server_info, though it doesn't explicitly name alternatives. The purpose is clear and unambiguous.

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 gives no guidance on when to use this tool versus other diagnostic tools (e.g., get_query_store_stats, get_table_stats). It does not mention prerequisites, when to choose this over siblings, or exclusion criteria. Usage context is only implied by the name and the note about bottlenecks, not 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. It only states a generic health check without revealing what happens on failure (e.g., timeouts, exceptions), whether it performs network I/O, or what the output format is. This is a significant gap for a diagnostic 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 one short, action-focused sentence with no filler or redundancy. It front-loads the purpose and intent. It is appropriately concise for such a simple tool, though it could include additional context without becoming verbose.

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?

Given the tool's low complexity (one optional parameter, no output schema), the description is borderline adequate but omits crucial details like expected return values or error behavior. The absence of an output schema increases the need for description to explain what the caller receives, which is not provided. However, the purpose is clear and the parameter is documented in the schema, so it slightly exceeds a minimal viable definition.

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?

The single parameter 'server' is fully described in the schema ('Target server name (uses default if omitted)'), giving 100% schema coverage. The description adds no extra parameter details, so the baseline of 3 is appropriate per the rubric. The optional parameter and default behavior are already clear from the schema.

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 ('Check') and resource ('SQL Server connection health') with a qualifier ('basic responsiveness'). It distinguishes itself from siblings by being the only tool focused on connectivity/health rather than querying or metadata. However, it could be more specific about what constitutes 'health' (e.g., connectivity, latency, server availability).

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 provides no guidance on when to use this tool versus alternatives, nor any prerequisites or typical scenarios. It does not mention when not to use it or mention any sibling tools. An agent must infer from the name and description alone, which is insufficient for optimal selection.

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 reveals that only 'accessible' databases are returned, which hints at permission filtering, but it does not disclose whether the operation is read-only, potential output format, ordering, pagination, or error behavior. Given the lack of annotations, the description under-specifies behavioral traits.

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, dense sentence that front-loads the action and resource. There is no redundant wording or filler. Every word earns its place, making it efficient for an agent to parse.

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 list tool with a single optional parameter and no output schema, the description is mostly adequate. However, it does not specify the return format (e.g., array of database names or objects) or any sorting. Given the sibling tools context, an agent might reasonably expect a list of names, but the lack of explicit output details slightly hinders completeness.

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?

The schema has 100% coverage, with an explicit description for the sole parameter ('Target server name (uses default if omitted)'). The tool description adds no additional meaning about the parameter beyond what the schema already provides. Baseline of 3 is appropriate because the schema handles the 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?

The description states a specific verb ('List'), a clear resource ('all accessible databases'), and the scope ('on the SQL Server instance'). This unambiguously distinguishes it from sibling tools like list_tables or list_schemas. An agent can immediately understand what this tool does.

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 (when you need a list of databases) but provides no explicit guidance on when to prefer this tool over alternatives, nor does it mention situations where it should not be used. It offers no exclusions or conditions. The name and purpose make usage fairly obvious, but it falls short of explicit routing.

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 only states what the tool does, not how it behaves: no mention of pagination, large result handling, default server/database resolution, error cases, or output format. This is a significant gap for a list operation.

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, front-loaded sentence that states the core function and the optional filter without any wasted words. Excellent conciseness and structure.

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 list tool, the description covers the basic purpose and optional filter, but lacks details about output shape, default behavior for omitted server/database, and interaction with sibling list tools. Since there is no output schema and no annotations, more context would be expected to fully guide correct invocation.

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% – each parameter (schema, server, database) has a basic description. The tool description adds only that schema filtering is optional, which is already implied by the schema's own description. No extra meaning is provided beyond the structured schema, so baseline 3 applies.

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 action ('List'), the resource ('stored procedures'), and the scope ('in a database, optionally filtered by schema'). It distinguishes from sibling tools like list_tables and describe_procedure by explicitly naming stored procedures as the target.

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 for retrieving stored procedures but does not contrast with related tools (e.g., describe_procedure for details, list_tables for tables). There is no explicit 'when to use' or 'when not to use' guidance, leaving some inference to the agent.

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 states the action but does not explicitly disclose read-only nature, output format, permissions, or behavior when parameters are omitted. It adds minimal context like 'current database' but is not comprehensive.

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?

Single sentence, clear, front-loaded with the purpose. No wasted words; the description is appropriately concise for a simple listing operation.

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 list operation with no required parameters, the description is minimally sufficient but lacks usage context and output expectations. Since no output schema exists, the description could have mentioned whether it returns system schemas or only user schemas, but it doesn't.

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 both parameters (server and database), and the schema provides their descriptions. The tool description adds no additional meaning beyond the schema, so it meets the baseline of 3.

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' and resource 'schemas' with scope 'current database'. It is distinct from sibling tools like list_tables and list_databases, leaving no ambiguity about what the tool does.

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 is provided on when to use this tool vs alternatives, such as list_tables or list_views. No mention of exclusions, prerequisites, or preferences; the agent must infer when to pick this over similar listing tools.

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, the description carries the full burden. It explicitly discloses the result scope ('all configured SQL Server connections') and the returned fields, which is sufficient behavioral transparency for a read-only listing. It does not mention side effects, but the verb 'List' implies none.

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 that front-loads the verb and resource, includes only essential detail fields, and contains no unnecessary words.

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 listing tool with no parameters, no output schema, and a clear description of returned fields, the description is fully complete. An agent can invoke and interpret the result without further information.

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?

The tool has zero parameters, so the description needs to add no param details. The schema coverage is 100% (vacuously), and the description adds no parameter-specific meaning because none exist. Per baseline for 0 params, this scores 4.

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 action (list), the resource (all configured SQL Server connections), and the detail fields (host, database, auth type, security mode). It unambiguously distinguishes this from sibling tools like list_databases (which lists database names) and get_server_info (which provides server-level info).

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 the tool is for enumerating configured connections but does not explicitly mention when to prefer it over alternatives or any exclusions. A clear context is present, but there is no direct guidance on selection among siblings.

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, the description must carry the burden of behavioral disclosure. It states the action is 'List' which implies a read-only operation, but it does not explicitly state that it is non-destructive or require any special permissions. It also does not mention pagination or performance characteristics. The description is functionally accurate but offers only minimal behavioral insight beyond the obvious.

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, front-loaded sentence with no wasted words. It states the core action and the key optional modifier (schema filter) immediately. It is highly concise and well-structured for quick comprehension.

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 listing tool with 3 optional, fully documented parameters and no output schema, the description is adequate. It clearly specifies the scope (all tables, optionally filtered by schema). It does not explicitly state output format, but the term 'List' implies a list of table names. Given the tool's simplicity and that parameters are covered by the schema, nothing critical is missing.

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 all three optional parameters (schema, server, database) are already documented in the schema. The description only mentions the schema filter, which repeats the schema's description and does not add additional semantic value. It does not explain how server and database parameters behave when omitted, which is already covered in the schema.

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's function: listing all tables in a database. It uses a specific verb ('List'), a resource ('tables'), and mentions an optional schema filter. This distinguishes it from sibling tools like list_views (views) and list_databases (databases), 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.

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

No usage guidance is provided. The description does not mention when to use this tool versus alternatives (e.g., list_views for views, list_schemas for schemas), nor does it state any exclusions or conditions. An agent is left to infer that this tool is only for tables, but no explicit routing to siblings is offered.

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 disclosing behavior. It only states the basic function and the optional schema filter. It does not mention that the operation is read-only, how the default server/database is resolved, whether results are paginated, or what fields are returned. For a 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, focused sentence that leads with the action and scope and includes the optional filter. There is zero fluff or redundant phrasing, making it highly efficient.

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, but with no output schema, the description does not hint at the shape of the response (e.g., just view names or full definitions). It also omits default server/database behavior. While the description is adequate for a basic call, the missing return-format context leaves moderate uncertainty for an agent.

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?

The input schema already describes all three parameters (schema, server, database) with 100% coverage. The description mentions the schema filter but adds no new meaning beyond what the schema provides. Per the rubric, this earns the baseline 3.

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 specific verb (List), a specific resource (views), and a scope (in a database), with an optional filter (by schema). This clearly distinguishes it from sibling tools like list_tables and list_schemas, so an agent can tell at a glance what this tool returns.

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: call this when you need to retrieve views. However, it provides no explicit guidance about when to prefer this over alternatives (e.g., list_tables) or any exclusions. The context is clear but not prescriptive, so it earns a middle score.

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 must convey behavioral traits. It discloses that the tool returns a random sample, which is a key behavioral fact. However, it does not state that the operation is read-only, discuss potential performance or randomness guarantees, or mention any side effects or constraints. This is a minimal disclosure that leaves the safety profile implicit.

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 sentence that is clear and to the point. The core action is front-loaded, and there is no superfluous wording. It is appropriately concise, though it could be slightly more structured with an example, but it doesn't waste tokens.

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?

Given the tool has 5 parameters (1 required) and no output schema, the description is reasonably complete for a straightforward sampling tool. However, it omits the return format or an example invocation, which might leave agents uncertain about the response structure. Since the schema fully documents inputs and the purpose is clear, the gap is minor.

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?

The schema description coverage is 100%, meaning every parameter already has an explanation (e.g., count default and max, schema default, server/database fallback). The tool description adds no additional parameter-level context. Since the schema carries the entire burden, the baseline of 3 applies; no extra value is provided here.

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's action: 'Get a random sample of rows from a table' and adds context on its purpose ('useful for understanding data patterns'). It differentiates from sibling tools like describe_table and get_table_stats by focusing specifically on sampling rows, which no sibling explicitly offers. The verb and resource are specific and unambiguous.

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 provides only implicit usage context via the phrase 'useful for understanding data patterns.' It does not explicitly state when to use this tool over alternatives like get_table_stats or describe_table, nor does it mention any conditions where this tool should not be used. With many siblings, an agent lacks clear routing guidance.

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