mssql-dba-mcp

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

Goes well beyond the read-only/idempotent annotations by disclosing the exact severity triggers (823/824/825, severities 19-25), the operator-receipt check, and the conditional escalation to CRITICAL when msdb.dbo.suspect_pages has rows. This is genuinely useful behavioral context an agent cannot infer from annotations or schema.

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?

Three dense sentences that front-load the scope then layer severity logic and platform caveat. Every sentence carries information, though the phrasing is somewhat packed and could be marginally tighter.

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 zero-parameter read tool with no output schema, the description explains what is checked and reported (alerts and operators) and the severity model. It could briefly note the return shape, but nothing critical for correct invocation 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?

The tool takes zero parameters, so the baseline is 4; there is nothing in the schema needing explanation and the description adds no misleading parameter claims.

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 and resource: checks SQL Agent alerts for corruption errors 823/824/825 and severities 19-25, verifies an enabled operator receives them, and lists all alerts and operators. This clearly distinguishes it from siblings like mssql_agent_jobs and mssql_agent_failed_jobs.

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 makes the use case clear (auditing alert coverage for high-severity/corruption conditions) and gives a hard scoping exclusion: 'Not available on Azure SQL Database.' It does not explicitly name alternative tools or say when to prefer this over job-focused siblings, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered; the description adds useful context by disclosing the fixed 7-day lookback window and the Azure SQL Database platform limitation. It does not mention result limits, pagination, or truncation behavior.

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 front-loaded sentence that carries scope, return content, and a caveat with no filler. Every clause 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?

With no output schema, the description appropriately names the returned fields and the time window, and warns about the Azure SQL DB exclusion. It stops short of covering edge cases such as empty results or row limits, but is sufficient for an agent to invoke the tool 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?

Zero parameters and an empty schema, so the baseline is 4. There is nothing parameter-related for the description to compensate for; the lookback window is fixed rather than parameterized, which the description makes clear.

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 resource (SQL Agent failed jobs), the scope (failed in the last 7 days), and the returned fields (date, time, error message). It is clearly distinguishable from sibling mssql_agent_jobs, which lists all jobs, and from mssql_agent_alerts.

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 7-day window and the 'Not available on Azure SQL Database' platform exclusion imply when this tool applies, but no alternative is named and no explicit 'use this when X' statement is given. Usage guidance 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the Azure SQL Database availability caveat and enumerates the returned fields, which is useful behavioral context beyond the annotations, though volume/pagination behavior is unstated.

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 short sentences with no filler; the returned-field inventory is front-loaded and the platform caveat is tucked at the end where it belongs. Every clause carries information.

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 input schema properties, no output schema, and rich annotations, the description covers what an agent needs by naming the returned fields and the platform limitation. It stops short of noting result volume or any ordering, which is minor for a parameterless inventory call.

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 takes no parameters, so there is nothing for the description to disambiguate; baseline for a zero-parameter tool applies. The field list instead documents output content, which is a reasonable substitute.

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 the resource (SQL Agent jobs) and enumerates what is returned (schedule, frequency, interval, last run status), so the agent knows this is a full inventory rather than a filtered subset. It is distinguishable from the closely-named sibling mssql_agent_failed_jobs by scope, though it never names that sibling 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 a platform exclusion (not available on Azure SQL Database), which is genuine when-to-use guidance, but offers no guidance on when to pick this over mssql_agent_failed_jobs or mssql_agent_alerts. Usage is implied by the name and field list 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds only the scope ('all databases on the instance'), which is already implied by the name; it discloses nothing about result size, ordering, or cost on instances with many databases.

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 front-loaded sentence with the scope first and a compact comma-separated field list after. Efficient, with no filler sentences, though the colon-heavy list format is dense rather than 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?

There is no output schema and no annotations-driven return disclosure, so the column enumeration is doing real work in telling the agent what it gets back. However it leaves gaps an agent would care about: whether one row is returned per database, ordering, and any filters. Adequate for a simple inventory call, but not 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The field list describes the output shape rather than inputs, which is a reasonable substitute given no input exists.

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 names a specific resource (all databases on the instance) and enumerates the attributes returned: state, recovery model, compatibility level, sizes, read-only, auto close, auto shrink, page verify, create date. It contrasts implicitly with the single-database sibling mssql_db_info via the 'All databases' scope, though it never names that sibling 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?

There is no statement of when to use this tool versus the many sibling inventory tools (mssql_db_info, mssql_db_config_health, mssql_storage_capacity). The agent must infer from the name alone that this is the fleet-wide inventory call.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds real behavioral value beyond that: the exact issue-detection thresholds (percent growth, ≤1 MB, autogrowth off), the output ordering, and a platform availability restriction.

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?

One sentence, front-loaded with the diagnostic criteria, then ordering, then the platform caveat. No filler, no restatement of the tool name, every clause carries information.

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 must convey the return shape, and it does reasonably well (data and log files matching the three issue conditions, ordered largest first). It stops short of saying whether results span all databases on the instance and what columns come back, which would fully close the gap.

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 takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. The absence of any scope parameter also implicitly tells the agent the scan is instance-wide rather than targeted at one database.

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 names the resource (data and log file autogrowth) and the precise conditions that make a file an 'issue': percent growth, growth of 1 MB or less, or autogrowth disabled, plus the result ordering (largest first). That is specific enough to separate it from neighbors like mssql_storage_capacity or mssql_vlf_counts, though no sibling is named 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?

Usage is only implied: an agent can infer you call this when diagnosing autogrowth misconfiguration, but there is no stated when-to-use versus mssql_storage_capacity or other storage tools. The only explicit scoping statement is the platform exclusion 'Not available on Azure SQL Database.'

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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuine value beyond that: the exact output fields and the semantics of an empty result, which an agent needs in order to report findings correctly.

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 tight sentences with no filler; the core purpose is front-loaded and the empty-result caveat follows immediately. Every clause carries information.

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 carries the return-shape burden and does so by listing the key fields and the empty-result case. It omits only minor operational context such as the required permission (VIEW SERVER STATE) and whether results are instance-wide or per-database.

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 takes zero parameters, so the baseline is 4. The description correctly implies no inputs are required, and there is nothing parameter-related left unexplained.

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 names the resource (blocking/locking) and enumerates exactly what the tool returns: blocked sessions, blocking session, wait type, wait time, and query text. This is far more specific than the sibling names alone, though it never explicitly distinguishes itself from adjacent diagnostics like mssql_running_requests or mssql_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?

Usage is implied — this is clearly the tool for diagnosing current blocking — and the 'empty result means no blocking' line tells the agent how to interpret the outcome. However, there is no explicit when-to-use guidance and no mention of alternatives such as mssql_wait_stats for historical wait analysis.

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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuine analytical context with the 95% threshold, but omits the scope of the measurement (instance-wide vs per-database) and any note on what the returned value looks like.

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

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

Two short sentences with no padding, and the metric definition is front-loaded. It is arguably too terse rather than too long, but nothing is wasted.

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 and no parameters, the description carries the burden of explaining the returned value and its scope. The threshold guidance is helpful, but the granularity of the ratio (per instance, per database, or cached-plan scope) is never stated, leaving a real gap for a diagnostic 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?

The tool takes zero parameters, so the schema is trivially complete and the description has nothing to compensate for. Per the rubric, a zero-parameter tool gets the baseline of 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 names a specific metric ('Buffer cache hit ratio (%)'), so an agent knows exactly what this tool returns. It does not, however, differentiate from related diagnostic siblings such as mssql_memory_pressure or mssql_disk_io_latency, which an agent might reasonably confuse with it.

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 statement of when to use this tool versus alternatives. The interpretive threshold ('Below 95% suggests too little memory') hints at a diagnostic purpose but never routes the agent to mssql_memory_pressure or any other sibling, and no prerequisites are given.

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

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

Annotations already cover the read-only, idempotent, non-destructive profile, and the description adds substantive behavior beyond them: it never executes CHECKDB, it flags databases with no check or one older than 7 days, and databases the login cannot read return UNKNOWN. These are exactly the non-obvious traits an agent needs.

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?

Extremely dense with zero filler: the returned artifacts, the staleness threshold, the non-execution guarantee, the permission edge case, and the platform limitation are all packed in without a wasted clause. The most important constraint ('Never runs CHECKDB') is front-loaded after the resource statement.

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 and no parameters, the description carries the full burden and meets it: it enumerates what is returned (per-DB check date, flags, suspect_pages rows), the flagging rule, the UNKNOWN sentinel, and the platform restriction. An agent can call it and interpret results without further context.

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 takes zero parameters, so the baseline is 4 and there is nothing for the description to clarify about inputs. No meaningful gain is possible or required 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?

States a specific verb+resource: reports the last known good DBCC CHECKDB date per online database plus rows in msdb.dbo.suspect_pages. This is clearly distinguishable from sibling backup/config tools (mssql_recent_backups, mssql_db_config_health) because it names the exact artifacts it 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?

Explicitly says 'Never runs CHECKDB', which tells the agent this is a status read rather than an action, and 'Not available on Azure SQL Database' is a clear when-not condition. It does not name a sibling alternative for cases where corruption details are needed, so it stops short of a full when/when-not/alternatives treatment.

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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds two facts annotations cannot convey: the hard 7-day retention window of the query and the Azure SQL Database incompatibility. It stops short of describing return ordering or any pagination, but for a bounded read tool this is solid added 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?

Two sentences with zero filler: the first front-loads the resource, scope, and returned columns; the second is a short platform caveat. Nothing could be removed without losing information.

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 only one optional parameter, rich annotations, and no output schema, the description usefully enumerates the returned fields and flags the platform limitation, which is enough for correct invocation. The one real gap is the absence of any routing signal versus the closely named mssql_recent_backups sibling.

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

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

Schema description coverage is 100% and the single databaseName parameter is fully documented in the schema, including its default to the connected database. The description's phrase 'one database' hints at the same parameter but adds no syntax or format detail beyond it, 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?

Names a specific resource (backup history for one database) and enumerates exactly what it returns: type, start/finish, duration, size, compressed size, file location. The 7-day window is stated up front. It does not, however, distinguish itself from the sibling mssql_recent_backups, which an agent could easily confuse it with.

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 'last 7 days' scope and the 'Not available on Azure SQL Database' caveat give some implied usage context, but there is no explicit when-to-use guidance and no pointer to an alternative such as mssql_recent_backups. An agent must infer the selection criteria itself.

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?

Annotations already declare readOnlyHint/idempotentHint, so the safety profile is covered; the description adds the operational impact (optimizer ignores untrusted constraints, invalid rows may be hidden) and the remediation script pattern. It does not describe the result set shape, but no output schema exists and the purpose is narrow.

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 dense sentences: the first gives purpose plus remediation, the second gives impact plus sibling routing. No filler.

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

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

For a single-optional-param read-only diagnostic, the description covers purpose, impact and disambiguation adequately. Minor gap: the remediation is presented as guidance, and the description doesn't clarify that this tool only reports the fix script rather than applying 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?

Single parameter with 100% schema description coverage, so the schema fully documents databaseName and its default. The description adds no additional parameter semantics, which is the expected baseline 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?

States a specific verb and resource (find check constraints that are untrusted or disabled) and explicitly distinguishes its scope from the foreign-key sibling, mssql_db_foreign_keys. An agent can select it without opening the schema.

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?

Names the alternative tool and the condition that selects it (foreign keys). It also implies when the results matter (optimizer ignores untrusted constraints). It lacks an explicit when-not clause beyond the foreign-key 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety and repeatability profile is covered without the description. The description adds only the notion that a single database's default collation is returned; it says nothing about permissions, latency, or error behavior. Adequate but thin given the low bar set by annotations.

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

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

Two short sentences with no filler, and the resource is front-loaded. The lead-in 'Database collation:' is slightly redundant with the sentence that follows it, costing a little efficiency, but overall it is tightly written.

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 zero-required-parameter read tool with no output schema, the description adequately conveys what is returned (the default collation of one database) and points at the companion tool for conflict diagnosis. Only the return shape and the default-database fallback are left implicit, which is minor for this complexity level.

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

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

Schema description coverage is 100%; the single parameter databaseName is fully documented in the schema including its default to the connected database. The description adds no syntax, naming, or fallback detail beyond that, 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 names a specific resource and scope: the default collation of one database. The implied verb (retrieve) matches the title 'Get Database Collation', so an agent can identify the operation. It stops short of explicitly differentiating itself from sibling mssql_db_info or mssql_all_db_info, which likely also expose collation-related 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?

It offers a contextual hint ('Use with mssql_db_collation_mismatches for collation conflict errors'), which implies the scenario where this tool is relevant. However, it never states when to call this instead of the mismatches tool, nor what the pairing actually accomplishes, leaving the usage decision partly to inference.

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?

Annotations already declare this as a safe, read-only, idempotent operation, so the description's added value is in disclosing the scan scope (dbo schema columns only) and the comparison basis (database default collation). It stops short of describing return shape or any rate limits, but adds meaningful behavioral context beyond the annotations.

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

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

Two short sentences, front-loaded with the core definition and followed by a brief diagnostic rationale. No filler or redundancy.

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 listing tool with full schema coverage and rich annotations, the description explains what is returned and why it matters. It does not enumerate result columns, but an output schema is absent and the description is still sufficient for 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 coverage is 100%, so the single databaseName parameter is fully documented by the schema itself. The description adds no additional syntax, format, or default behavior beyond what the schema already provides.

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

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

The description clearly identifies the resource (collation mismatches among columns) and narrows scope to the dbo schema and database default. It effectively distinguishes itself from the sibling mssql_db_collation, but lacks an explicit verb and does not name alternatives.

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

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

The diagnostic note 'A common cause of collation conflict errors in joins with temp tables' implies when the tool is useful, but there is no explicit when-to-use instruction, prerequisite, or comparison to sibling 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?

Annotations already declare this a safe, read-only, idempotent operation, so the safety burden is off the description. The description adds genuine value by disclosing the detection thresholds (6000 bytes near the 8060-byte limit) and that risky types come with a suggested replacement, which goes beyond the annotations.

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

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

A single front-loaded sentence that opens with the resource and then lists the three detection categories. Tight and waste-free, though the parenthetical thresholds make it moderately dense.

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 bears the burden of describing the return content, and it does enumerate the three issue categories the agent will receive. It stops short of describing result shape or severity fields, but for a read-only diagnostic it is nearly 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% with a single optional parameter (databaseName) fully described in the schema, including its default to the connected database. The description adds nothing about the parameter, 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 names the specific resource (column design issues) and enumerates exactly what it detects: deprecated types, risky types with suggested replacements, and oversized row-width tables. This is far more informative than a tautology and implicitly distinguishes it from schema-inventory siblings like mssql_db_tables, though it doesn't name a sibling 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?

No when-to-use guidance, no prerequisites, and no mention of when to prefer this over related tools like mssql_db_tables or mssql_table_info. The agent must infer the trigger condition from the content list 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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds meaningful behavioral context beyond that: it reports risky values via 'Flags' and that onlyFlagged=true is the default filter, which is important because the default silently narrows the result set. It still does not describe row shape or any permission requirements.

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 compact sentences with the scope and the full setting list front-loaded, followed by the flagging/default behavior. Slightly dense with an awkward comma splice before 'onlyFlagged', but no wasted 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?

With no output schema, the description carries the burden of saying what comes back, and it does reasonably well by naming the settings checked and the presence of risk flags. It does not state whether output is one row per database or the exact flag/severity semantics, which is the remaining gap for a diagnostic 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% and the single parameter's schema text ('Return only databases with at least one flag. Set false to return all.') already fully documents it. The description restates the default rather than adding format or cost semantics, 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 states a specific scope ('every online user database') and enumerates exactly which settings are evaluated (compatibility level, recovery model, page verify, auto close, auto shrink, auto statistics, target recovery time, Query Store) plus the flagging behavior. That enumeration lets an agent distinguish this from mssql_server_config (server-level) or mssql_db_info, though it never names a sibling 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?

Usage is implied rather than stated: an agent can infer this is the per-database configuration-health check and that onlyFlagged controls breadth, but there is no explicit when-to-use guidance or routing to alternatives such as mssql_server_config or mssql_db_info.

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?

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower, and the description adds real context: what issues are detected, that a fix statement is surfaced, and a caveat that missing-FK name matches are speculative and must be confirmed. The one ambiguity is whether the 'WITH CHECK CHECK CONSTRAINT fix' is returned as a script or applied, though readOnlyHint implies it is only surfaced — short of a contradiction.

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 content is front-loaded and every clause carries information, but it is delivered as a single dense, heavily parenthesized sentence, which makes the fix and guess caveats slightly harder to scan than a clean bulleted breakdown would be.

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 does the work of describing return content (per-FK trusted/disabled/indexed/mismatch status plus suggested missing FKs), which is sufficient for an agent to know what it will get. It is nearly complete for a read-only diagnostic; the only minor gap is not clarifying whether the fix is a script or an action.

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 both parameters (onlyIssues, databaseName) are already fully documented in the schema. The description alludes to issue-only filtering but adds no syntax, defaults, or format detail beyond what the schema provides, making the 3 baseline correct.

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 resource (foreign keys in one database) and enumerates exactly what the review surfaces: trusted/disabled state, indexing, column type or collation mismatches, the WITH CHECK CHECK CONSTRAINT fix, and likely missing foreign keys. It is clearly distinguishable from siblings like mssql_db_table_keys and mssql_db_check_constraints, while the example 'Votes.PostId -> Posts.Id' pins down the missing-FK heuristic.

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 scope is strongly implied (use this to review FK integrity and to spot missing FKs for a database), and it gives one piece of usage guidance — name matching is a guess, so confirm each hit. However, it names no alternatives and gives no explicit when-not-to-use conditions versus tools such as mssql_db_table_keys or mssql_db_column_design_issues, so guidance remains inferred.

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?

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, and the description adds real value beyond them: the 50%/80% warning thresholds, the consequence of exhaustion (all inserts fail), and the sort order of results. It does not mention permissions or scope of the scan, but the risk semantics are well disclosed.

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 dense sentences with zero filler: the metric and ordering come first, then the alert thresholds and the failure consequence. Every clause 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?

With no output schema and zero required parameters, the description adequately conveys what is returned (identity columns plus percent of range used, ordered) and the severity interpretation. Only minor gaps remain, such as the exact fields or database scope behavior, which the schema partially covers.

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 topN, databaseName, and minPercentUsed are already fully documented in the schema; the description adds no parameter-level detail such as how minPercentUsed interacts with the WARN/RISK levels. Baseline 3 is appropriate when 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 names the exact resource and metric: identity columns with the percentage of their type range already consumed (tinyint to bigint, decimal), returned most-used-first. No sibling tool covers identity headroom, so it is trivially distinguishable, though it is framed as a noun phrase rather than an explicit verb+resource statement.

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?

Usage is implied rather than stated: the WARN/RISK thresholds and the note that 'when an identity runs out, every insert fails' tell the agent why to call it, but there is no explicit when-to-use guidance, prerequisites, or named alternative among the many mssql_* diagnostics.

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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety bar is met. The description adds real value beyond that: it discloses the LIMITED scan-mode performance caveat on large databases and clarifies that DROP/REBUILD/REORGANIZE output is a script 'to review' rather than executed work.

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, densely but purposefully packed; the returned-content enumeration and the performance caveat are both front-loaded. Slight density cost, but no filler sentence.

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 carries the return-value burden and does so by listing the fields returned. Combined with the performance caveat and sibling routing, it is nearly complete; only pagination/result-size behavior is unstated.

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

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

Schema description coverage is 100% and the single parameter (databaseName) is fully documented including its default. The description adds no syntax or format detail beyond what the schema provides, 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?

States a specific verb+resource ('index health for one database') and enumerates the returned content: key/included columns, usage, fragmentation, fill factor advice, size, and suggested scripts. It also names the sibling it is not (mssql_table_index_health), so an agent can distinguish it without opening a schema.

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

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

Explicitly routes the agent: use mssql_table_index_health when only a few tables are of interest, and this tool otherwise. It also warns that physical stats (LIMITED) can be slow on very large databases, which is actionable timing 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is fully covered and the description does not contradict it. The description adds no behavior beyond that (no cost, no permissions, no caveats about restricted DMV visibility). With annotations carrying the safety load, a baseline 3 is appropriate.

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 dense sentence with the scope front-loaded and the attribute inventory following. No filler, though the comma-separated field list makes it read as a run-on rather than structured output summary.

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?

No output schema exists, so enumerating the returned fields (state, recovery model, compatibility level, sizes, flags, create date) is genuinely load-bearing information for the agent. The remaining gap is that server context and privilege requirements are unstated, which matters for a diagnostics tool against a specific instance.

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?

Only one parameter (databaseName) and schema coverage is 100%, with the default ('connected database') already documented in the schema. The description adds no extra semantics about the parameter, so the high-coverage 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?

States the resource (database info) and the scope qualifier 'for one database', then enumerates the exact attributes returned. The 'one database' scope implicitly separates it from the mssql_all_db_info sibling, though that sibling is never named. Clear enough that an agent knows what it gets without opening the schema.

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?

Usage is only implied by the phrase 'for one database' — the agent can infer this is the single-database counterpart to mssql_all_db_info, but no when-to-use condition, prerequisite, or alternative is stated explicitly. No mention of required permissions or workload conditions.

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?

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description goes beyond them by disclosing the ranking fields (urgency, improvement %, uses, equality, inequality, included columns) and the filtering thresholds (1000+ rows, real query volume), which materially shape what comes back.

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 dense sentences, front-loaded with the resource and source, then the ranking fields and filtering thresholds. Every clause carries information with no filler.

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 usefully enumerates the ranking columns and the row/volume filters, and annotations cover the safety profile. Adequate for calling the tool correctly, though it could note that results are advisory recommendations.

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 parameter's description ('Target database. Defaults to connected database.') already fully explains it. The description only echoes this with 'for one database', adding no format or syntax detail beyond 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?

States a specific resource (missing indexes) with a clear scope (for one database) and names the data source (missing-index DMVs). The 'one database' scope distinguishes it from the table-level sibling mssql_table_missing_indexes without opening a schema.

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?

Describes what the tool returns but offers no when-to-use guidance, no prerequisites, and no explicit routing versus alternatives like mssql_table_missing_indexes or mssql_db_index_health. The agent must infer the use case.

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?

Annotations already declare read-only, idempotent, non-destructive, and closed-world. The description adds real behavioral context beyond that: the sa exclusion is based on SID 0x01 so a renamed sa still counts, orphaned owners (logins that no longer exist) are included, and the tool is unavailable on Azure SQL Database.

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?

One dense sentence, front-loaded with the resource and immediately qualified by the two inclusion rules and the platform limit. No filler, no repetition of the title.

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 no-param, read-only tool with full annotation coverage and no output schema, the description covers scope, filtering rules, orphan handling, and platform limits. It could briefly note the return shape (owner name per database), but nothing essential to correct invocation 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-param tool is 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 names a specific resource (database owners) and sharply narrows scope: user databases not owned by sa (by SID, so renamed sa is caught), plus orphaned owners. That specificity makes it distinguishable from generic siblings like mssql_db_info or mssql_privileged_logins, though no sibling is named 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?

There is no statement of when to call this tool versus alternatives such as mssql_privileged_logins or mssql_db_config_health. The Azure SQL unavailability is a platform constraint, not usage routing guidance, so the agent gets no when/when-not direction.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context by explaining what is flagged and how onlyFlagged changes the result set, though it says nothing about permissions, performance, or result ordering.

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 compact and front-loaded: it defines the resource and returned fields first, then explains flagging behavior, then states the onlyFlagged default. Every sentence carries useful information with no filler.

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 carry return-value information. It does list the key returned fields and flag conditions, making it mostly complete, but it does not describe the exact output structure, column names, or ordering.

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 both parameters are already documented in the input schema. The description repeats onlyFlagged's default and effect but adds no extra semantic detail beyond what the schema provides, which is the baseline 3 when 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 states the resource (table keys) and specifies the exact contents: user tables with row count, heap or clustered index, primary key, unique indexes, and flags for heaps/missing PK/single-column uniqueness. It is clear, but it does not explicitly differentiate itself from sibling tools like mssql_db_tables or mssql_db_index_health.

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 through its diagnostic flagging logic and the onlyFlagged default, which tells the agent this is for finding key/index design problems. However, it never states when to choose this tool over similar siblings such as mssql_db_tables, mssql_table_info, or mssql_db_index_health.

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?

Annotations already declare readOnlyHint/idempotentHint/non-destructive, so safety is covered; the description goes beyond them by disclosing the LIMITED index-stats read and its slowness on very large databases, plus the result ordering (largest first). It stops short of describing pagination or result-size limits, which is a minor 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?

One dense sentence plus a caveat sentence, with the payload list front-loaded and the performance warning placed last where it belongs. The return-field enumeration is long but each item earns its place given there is no output schema.

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 carries the burden of describing the return shape and does so by enumerating the columns and their sort order. Combined with the performance caveat and the sibling pointer, an agent has enough to call it correctly; only result-size/pagination behavior is unaddressed.

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

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

Schema description coverage is 100% and the single databaseName parameter is fully documented there, so the schema does the heavy lifting. The description only implies the per-database scoping ('for one database') without adding default or format detail, matching the baseline for high-coverage schemas.

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 names a specific verb+resource (a per-database tables overview) and enumerates the exact payload: row count, size, primary key, index counts, index health, workload, and access pattern. It also distinguishes itself from the closest sibling by noting that mssql_table_info covers a few tables instead of the whole database.

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?

It states the scope condition (whole database vs a few tables) and names the alternative tool (mssql_table_info) for the narrower case. It also flags the operational cost — index physical stats are read at LIMITED level and can be slow on very large databases — which is precisely the when-to-avoid guidance an agent needs.

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?

Annotations already declare readOnlyHint, idempotentHint and non-destructive behavior, so the safety profile is covered. The description adds the output shape (per-file metrics plus an Exceptional-to-Critical rating), which is useful, but says nothing about scope (instance-wide vs. filtered), freshness, or cost of the scan.

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 tight sentences: the returned metrics come first, the intended use case second. No filler, no repetition of the tool name, nothing that could be cut.

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 parameters and no output schema, the description carries the return-value burden and does so reasonably by listing the metrics and the rating scale. It omits what governs the rating thresholds and whether results are per-instance or filtered, but an agent has enough to invoke 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?

There are zero parameters, so the baseline of 4 applies; nothing needs to be disambiguated and the description is not required to explain any inputs.

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 resource (disk I/O latency per database file) and enumerates the returned metrics (reads, writes, avg read/write stall in ms, rating scale). This clearly distinguishes it from siblings like mssql_storage_capacity (capacity, not latency) and mssql_wait_stats (engine waits, not per-file I/O).

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?

'Use to find slow storage' gives an explicit diagnostic context for when to reach for this tool. It stops short of naming alternatives or exclusions (e.g., capacity planning vs. latency triage), so it is clear context without routing detail.

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?

Annotations already cover the read-only/idempotent/non-destructive safety profile, so the bar is lower. The description still adds real operational context beyond them: required permissions (VIEW ANY ERROR LOG, SQL Server 2022+/MI, or securityadmin), platform exclusion, and result ordering ('newest entries first').

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?

One dense paragraph, front-loaded with the core action, then filters, then ordering, then prerequisites and platform limits. Every clause carries information an agent needs; nothing is padding.

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 read-only, no-required-param tool with full schema coverage and no output schema, the description covers purpose, filtering, ordering, permissions, and availability. Nothing needed to invoke it correctly 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 five parameters are already documented in the schema, including the logType enum, maxRows cap, and logNumber semantics. The description restates the two-search-string combination and the archived-log concept without adding syntax or format detail beyond the schema, so it sits at 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?

States a specific verb and resource (read the SQL Server ERRORLOG or Agent log via sp_readerrorlog) and immediately distinguishes it from siblings like mssql_agent_jobs and mssql_recent_backups by scoping to raw log lines. An agent can identify this as the log-text reader without opening the schema.

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?

Gives clear operating context: filtering by one or two strings, selecting an archived log, and a hard availability exclusion ('Not available on Azure SQL Database'). It does not name a sibling alternative for related needs (e.g. when to prefer a structured check like mssql_agent_failed_jobs), so it stops short of explicit when-not-to-use-this 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?

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds real context beyond them: it touches only the plan cache, never executes the query, and truncates large plans at 35,000 characters — an important disclosure that output may be incomplete.

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?

Three short sentences, each carrying distinct information: what it returns, where to get the input, and the behavioral constraints. The purpose is front-loaded and nothing is wasted.

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

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

For a single-parameter read tool with no output schema, the description supplies the return format (showplan XML), the truncation caveat, and the input provenance — everything an agent needs to call it and interpret the 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 already documents the hex plan handle format, so the baseline is 3. The description adds value by naming the source tool (mssql_top_queries) where the handle comes from.

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?

Names a specific verb+resource: retrieves the showplan XML execution plan for a cached query keyed by plan handle. It is clearly distinct from siblings like mssql_run_select (executes queries) and mssql_top_queries (lists queries).

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

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

Explicitly states the prerequisite chain — the plan handle must be obtained from mssql_top_queries — which routes the agent correctly. It also clarifies this reads the plan cache only and never runs the query, though it doesn't name when a different tool would be preferred.

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?

Annotations already establish readOnly, idempotent, non-destructive behavior. The description adds meaningful diagnostic context beyond annotations by explaining what PLE is and giving interpretation thresholds, which helps an agent understand the tool's significance. It does not describe return format, but that is a minor gap for this simple read-only metric.

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 tightly written sentences. The metric and its source are front-loaded, and the interpretation thresholds follow immediately with 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?

For a no-parameter diagnostic tool with rich annotations and no output schema, the description is nearly complete. It explains the metric and thresholds but does not state what the response contains (e.g., a scalar PLE value), which is a minor omission given the simplicity.

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 baseline score of 4 applies. The schema has 100% coverage for an empty parameter set, and the description does not need to document any inputs.

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 resource and metric: Page Life Expectancy from the Buffer Manager, framed as memory pressure diagnostics. It is specific enough to distinguish from generic server checks, though it does not explicitly contrast itself with similar siblings like mssql_buffer_hit_ratio.

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?

Thresholds ('below 300 signals memory pressure', 'below 1000 on modern servers is worth a look') imply when the result matters, but the description never states when to call this tool versus alternatives such as mssql_buffer_hit_ratio or mssql_wait_stats. Usage guidance is only implicit.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description's added value is the operational definition of 'offline' (the state enumeration) and the triage signal 'any row needs attention'; it says nothing about result shape, counts, or ordering, so a 3 is appropriate.

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 compact sentence with the definition front-loaded and the actionable takeaway ('Any row needs attention') at the end. No filler, no redundancy with the title.

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, but the description compensates by enumerating the states that produce rows, which is the main thing an agent needs to interpret results. For a zero-parameter, read-only diagnostic tool with complete annotation coverage, this is close to sufficient; only the absence of any mention of scope (server-wide vs. instance) leaves a small gap.

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 takes no parameters, so the baseline of 4 applies; there is no parameter surface for the description to explain or omit. No misleading parameter language is present.

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 names the resource (databases that are not ONLINE) and enumerates the exact states counted as offline (OFFLINE, RESTORING, RECOVERING, SUSPECT, EMERGENCY), so an agent knows precisely what a row represents. It does not explicitly differentiate itself from siblings such as mssql_all_db_info or mssql_db_info, which also return database rows, 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?

Usage is implied rather than stated: 'Any row needs attention' signals this is a diagnostic/triage check, but there is no explicit when-to-use guidance or named alternative (e.g., use mssql_all_db_info for a full inventory). Adequate but leaves the routing decision to inference.

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?

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so the bar is low; the description still adds real behavioral facts beyond them — the permission requirement for full visibility and the Azure SQL Database unavailability. It stops short of describing output shape or how the REVIEW marking is derived.

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?

Three short, information-dense clauses with zero filler: what it lists, how each member is classified, what permission is required, and where it does not work. Everything is front-loaded; no sentence is expendable.

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 must convey the returned content, and it does — role membership plus the Expected/Built-in/REVIEW triage marks. Prerequisites and platform limits are covered, leaving nothing an agent needs before calling it.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema alone implies only indirectly: that listed accounts are marked 'Expected instead of REVIEW', tying the parameter to a visible output classification. The case-insensitivity detail remains schema-only, which is fine.

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+resource: enumerating members of the sysadmin and securityadmin server roles, with the exact classifications returned (Expected, Built-in, REVIEW). No sibling tool covers security role membership, so it is trivially distinguishable from the health/DB-inspection siblings.

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?

Frames the tool as a security audit check and states the precondition (needs VIEW ANY DEFINITION to see all members) plus the platform exclusion (not available on Azure SQL Database). It does not name alternative tools, but no sibling overlaps, so the when-to-use context is effectively complete.

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?

Annotations already declare readOnly/idempotent/non-destructive/non-open-world, so safety is covered. The description adds meaningful behavior the annotations do not: the 30-day retention window, NULL date semantics for databases without backups, and an Azure SQL availability constraint. It stops short of describing row shape or ordering, but that is minor.

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?

Three short sentences, front-loaded with the core scope before the alternative and the availability caveat. Every sentence carries distinct information with no redundancy.

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 carries the burden of conveying return semantics, and it does: per-database latest Full/Diff/Log with NULL dates when absent. Combined with the Azure exclusion and the sibling routing, an agent has everything needed to call and interpret this 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline for a parameterless tool is 4. No misuse is possible from missing parameter documentation.

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

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

States a specific resource (backups) with a precise scope: the most recent Full, Differential and Log backup per database over the last 30 days. It is immediately distinguishable from the sibling mssql_db_backup_history, which it names, without requiring the agent to open either schema.

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

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

Explicitly routes the agent to mssql_db_backup_history for single-database history, giving the selecting condition ('one database's history'). It also states an environment exclusion ('Not available on Azure SQL Database'), covering both when-to-use and when-not.

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?

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so safety is covered; the description adds real value on top by disclosing the returned field set (including blocking session and open transactions) and the semantic effect of includeSleeping. It stops short of noting that DMV snapshots can be costly under load or that results are point-in-time only (no history), which would push it higher for an observability 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?

Three tight sentences with the core purpose front-loaded and no filler; the field enumeration is dense but earns its place since no output schema exists. Slightly list-heavy, which costs it the top mark, but nothing is wasted.

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 competently shoulders the burden of describing the return contents, and it resolves the one parameter plus the sibling overlap. It omits scope details (instance-wide vs. current database) and any note about snapshot/latency behavior, which are the remaining gaps for full 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 coverage is 100% and the single boolean is already documented in the schema with the same meaning; the description restates includeSleeping without adding format or edge-case detail. Baseline 3 is correct when the schema carries the 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?

States a specific verb+resource ('Running requests now: active user sessions') and enumerates exactly what each row contains (status, command, CPU, reads, elapsed time, wait type, blocking session, open transactions, current statement). It explicitly distinguishes itself from the sibling mssql_blocking for the blocked-only case, so an agent can route without opening either schema.

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?

Names the alternative (mssql_blocking) together with the condition that selects it ('For blocked sessions only'), and gives the condition that changes this tool's own behavior ('includeSleeping=true also lists idle sessions that hold an open transaction'). Nothing essential is left to inference.

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?

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real operational context beyond them: exactly one statement, a list of rejected keywords (INSERT, UPDATE, EXEC, SET, USE, SELECT INTO), session-change prohibition, and a hard 500-row return cap with mitigation advice.

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?

Three tight sentences, front-loaded with the core capability, then the constraint set, then the return-limit workaround. No filler; every clause carries either a rule or a routing cue.

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 still covers the essentials an agent needs: what is accepted, what is rejected, how to target another database, and the 500-row result ceiling. Nothing material is left unstated for a query-execution 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 coverage is 100%, so the baseline is 3; the description adds value by explaining the intent behind databaseName ('instead of USE to run in another database'), which clarifies why the parameter exists rather than just what it is. It does not add syntax details for selectQuery beyond the schema's own example.

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 (run) and resource (one read-only SELECT / WITH...SELECT) plus its scope: ad-hoc analysis of system views and DMVs. It also positions itself against siblings with 'when no other tool fits', so an agent can tell it apart from the ~40 specialized mssql_* tools without opening any schema.

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?

Gives a clear context for use ('ad-hoc analysis of system views and DMVs when no other tool fits') and an explicit alternative for one case ('use databaseName instead of USE'). It stops short of naming any concrete sibling (e.g. mssql_top_queries), so the routing guidance remains general rather than exhaustive.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds real context beyond that: the underlying source views, the specific risk conditions that produce a Flag, and the default filtering behavior. It stops short of describing output shape or how many flags typically fire.

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 resource and source views are front-loaded, and the flag examples are packed into one dense sentence with an 'and more' catch-all that costs little. Slightly long for a one-parameter read tool, but every clause carries information.

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 read-only, closed-world tool with full schema coverage and no output schema, the description supplies what an agent needs: what is inspected, what counts as flagged, and the default filter. Return format is unspecified, but annotations and the read-only nature keep the risk low.

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

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

Schema description coverage is 100% and the single parameter's meaning, including its default and the false case, is fully documented in the schema. The description's sentence about onlyFlagged=true repeats that structured information rather than adding syntax or edge-case detail, 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 names the exact resource and its backing views (sp_configure, sys.configurations) and enumerates the concrete risky settings it inspects, so an agent can tell this server-level config audit apart from siblings like mssql_db_config_health or mssql_memory_pressure. The verb 'returns' plus the scoping make the operation 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?

Usage is only implied: an agent can infer this is for auditing server-level configuration risk, and the default-onlyFlagged behavior is stated. However, it never says when to reach for this tool versus mssql_db_config_health or mssql_memory_pressure, and no prerequisites or exclusions are given.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description usefully adds what the call yields (local time, UTC time, UTC offset), which matters since there is no output schema. No auth or rate-limit details, but none are needed for a zero-parameter read.

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 short sentences, the returned values front-loaded followed by the usage cue. Every clause earns its place with no filler.

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 trivial zero-param read-only diagnostic with no output schema, the description covers both what is returned and when to reach for it. Only a note on the output's precise format (e.g. offset notation) is absent, which 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?

Zero parameters, so per the rubric the baseline is 4. The description's listing of returned values is helpful output context but not parameter semantics, and nothing is missing on the input side.

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 resource (server time and timezone) and enumerates the returned values: local time, UTC time, UTC offset. Distinguishable from siblings like mssql_server_version or mssql_server_config, though it doesn't explicitly name those 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?

Provides a concrete usage context: 'Use for time-related job, backup or replication problems.' This tells the agent when the tool is relevant, but no explicit alternatives or exclusions are named.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds no behavioral context beyond that — no auth requirements, execution cost, or freshness/caching notes — so it neither contradicts nor enriches the annotations.

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

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

Two short sentences, zero filler. The returned fields are front-loaded and the operative usage instruction ('call first') is placed at the end where it is easy to act on.

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 usefully enumerates the returned facets, which is exactly what an agent needs to decide whether this call answers its question. It stops just short of stating output shape or whether the values span all nodes in a clustered/HADR setup, so it is strong but not exhaustive.

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 takes no parameters, so there is nothing to document and the baseline for a 0-parameter tool is 4. The description correctly spends no words on inputs and instead focuses on what is returned.

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 names the specific resource (server version) and enumerates the exact facets returned — version, edition, patch level/CU, collation, clustering/HADR, licensing — which cleanly separates it from near-siblings like mssql_db_collation and mssql_db_info. Combined with the 'Get Server Version' title, an agent knows precisely what this returns without opening the schema.

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?

It gives explicit placement guidance: 'Call first in any health check.' That is a concrete when-to-use signal. It does not name exclusions or competing tools, but for a zero-parameter server-level introspection call the guidance is clear enough.

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?

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so safety is covered; the description still adds real behavioral context beyond them — the <10% threshold that determines inclusion, the interpretation rule that any returned row is a warning, and the Azure SQL Database unavailability. It does not describe pagination or column layout, but that is minor here.

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?

Four short clauses, zero filler, and the substantive content (scope, threshold, and the Azure exclusion) is front-loaded. Nothing can be removed without losing information.

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 parameters, no output schema, and rich annotations, the remaining burden is small and mostly met: threshold, warning semantics, and availability limits are all stated. What a returned row actually contains is left unstated, though the "any row is a warning" rule lets an agent act on the result without knowing the columns.

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 takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to disambiguate, and it correctly spends no words on nonexistent inputs.

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 names the resource (drive free space) and the exact filter that defines the result set (drives with less than 10% free), which cleanly separates it from siblings like mssql_disk_io_latency and mssql_autogrowth_issues. The action verb is only implied by the title, not stated in the description itself.

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

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

It gives explicit usage direction ("Include in every health check") and a hard platform exclusion ("Not available on Azure SQL Database"), which is exactly the kind of when-not guidance agents need. It stops short of naming alternative tools for adjacent disk concerns, so it is not a full when/when-not/alternatives treatment.

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?

Annotations already establish the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false). The description adds useful substance beyond that: it discloses the tool returns advisory output including a suggested maintenance script, i.e. it advises rather than mutates. It says nothing about cost on large tables, permissions, or result shape, so it is additive 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?

A single front-loaded sentence with the resource first and the payload enumerated after the colon. No filler, though the enumeration could be slightly tightened.

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 has to convey what comes back, and it does name the four output areas (fragmentation, usage, fill factor advice, script). That is adequate for an assessment tool, though it leaves ambiguity about how 'usage' is measured and whether non-table objects are supported.

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?

Both parameters have full schema descriptions (100% coverage), so the schema carries the semantics. The description only says 'the given tables', adding no format, plural/singular, or database-qualification guidance beyond 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 gives a clear verb+resource ('Index health for the given tables') and enumerates the specific outputs (fragmentation, usage, fill factor advice, maintenance script), so the agent knows exactly what it gets. It does not, however, distinguish itself from close siblings such as mssql_db_index_health (database-scope) or mssql_table_missing_indexes, leaving the agent to infer the table-level 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?

There is no when-to-use guidance, no prerequisites, and no reference to the analogous database-level tool. The agent gets no help deciding between this, mssql_db_index_health, and mssql_table_missing_indexes.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the tool computes derived analytics (read/write workload, access pattern, volatility) rather than raw catalog metadata, which is genuine extra context. It says nothing about cost, sampling window, or permissions required to read workload data, so it stays at an adequate 3.

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 front-loaded sentence that leads with the resource and then lists returned attributes — no filler or restatement of the name. The trailing comma-list is dense but every item is informative. Slightly more structure (e.g., separating input scope from output scope) would help.

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 enumeration of returned metrics in the description is doing real work and largely substitutes for one. Combined with 100% schema coverage and annotations that state the operation is read-only, an agent has enough to call this correctly. The only gap is that vague terms like 'access pattern' and 'volatility' are not defined.

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 both tableNames and databaseName are already documented in the schema. The phrase 'for the given tables' loosely maps to tableNames but adds no syntax, batch-size, or permission detail beyond it, and databaseName is never referenced in the description. Baseline 3 applies when 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 names the resource (table details for given tables) and enumerates the exact attributes returned: row count, size, primary key type, index counts, workload, access pattern, volatility. That is far more specific than the title 'Get Tables Info'. It does not, however, distinguish this tool from nearby siblings such as mssql_db_tables, mssql_db_table_keys, or mssql_table_index_health, which an agent could easily confuse it with.

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 when-to-use guidance at all — no statement of when to prefer this over mssql_db_tables (listing tables) or mssql_table_index_health (index diagnostics). The overlapping attribute 'index counts' vs. mssql_table_index_health is exactly the ambiguity an agent needs help resolving, and nothing 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?

Annotations already declare this a safe, idempotent, read-only, closed-world operation, so the safety profile is covered. The description adds that results are ranked by improvement score, which hints at output shape, but says nothing about cost of running it, empty results, or how many recommendations are returned.

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 front-loaded sentence with no filler, and the scope qualifier comes before the ranking detail. It is slightly terse for the amount of routing information an agent needs.

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 carries some burden for describing the return payload; 'ranked by improvement score' gives a partial signal but omits the shape of each recommendation (columns, indexes, impact). For a two-parameter read-only diagnostic tool it is minimally adequate.

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 both parameters are already documented in the schema, including the database default behavior. The description's 'given tables' merely mirrors tableNames and adds no format, casing, or qualification guidance. 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?

States a specific resource and scope: 'Missing indexes for the given tables', with the ranking basis ('improvement score') disclosed. It does not explicitly distinguish itself from the sibling mssql_db_missing_indexes, so an agent must infer the table-scoped vs database-scoped split from the input schema.

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 'for the given tables' implies the usage context (use when you have specific tables in hand), but there is no explicit when-to-use, when-not-to-use, or named alternative such as mssql_db_missing_indexes for a whole-database scan. Usage is only implied.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds substantive context: it names the top-10-session limit and discloses the specific conditions it flags (too few data files, unequal sizes, percent autogrowth), which tells the agent what constitutes a finding rather than just a raw dump.

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 dense sentence organized as scope → categories → flagged conditions, with the resource named first. Every clause carries information; there is no filler or repetition of the title.

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 describe what comes back — and it does, listing file layout, space-use breakdown, top sessions, and the flagged anomalies. For a zero-parameter read-only diagnostic with full annotation coverage, nothing needed for correct invocation 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?

The tool takes zero parameters, so the schema has nothing to document and the baseline is 4. The description correctly introduces no parameter-related claims, leaving no gap.

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?

Names a specific resource (TempDB health) and enumerates exactly what it inspects: file layout (count, equal sizes, autogrowth), space use (user/internal objects, version store, free space), and top 10 tempdb sessions. TempDB is a unique resource across the sibling list, so it is readily distinguishable from mssql_autogrowth_issues, mssql_disk_io_latency, and mssql_storage_capacity.

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?

Usage is implied — an agent can infer this is the tempdb-specific diagnostic to run when investigating tempdb contention or file layout. However, the description never states when to choose it over the overlapping sibling mssql_autogrowth_issues, nor any exclusions or prerequisites.

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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: results come specifically from the plan cache (sys.dm_exec_query_stats), so only cached statements appear, and it discloses the return payload (statement text and Plan Handle).

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 dense sentences with the sortable dimensions and data source front-loaded and no wasted wording. Every clause (dimensions, source, output payload, handoff, topN bound) carries information.

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 correctly compensates by naming the returned fields (statement text, Plan Handle) and the data source. It omits any note on the cost/scope of scanning the plan cache or how stale cache entries affect results, but for a two-param read tool with full annotations it is essentially 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% – both topN (default 25, range 1-100) and sortBy (full enum) are documented in the schema itself. The description's restatement of 'topN default 25, max 100' duplicates the schema without adding format or behavioral nuance, 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?

States a specific verb+resource ('top queries') and enumerates the sortable dimensions (CPU, logical reads, memory grant, spills, duration, executions). It names the sibling it feeds into (mssql_execution_plan via Plan Handle) and the data source, so an agent can distinguish it from mssql_running_requests or mssql_wait_stats without opening a schema.

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 context (top resource consumers from the plan cache) and gives a clear downstream handoff to mssql_execution_plan, but it never states when to prefer this over alternatives like mssql_running_requests or mssql_wait_stats, nor any exclusions. Usage is implied rather than spelled out.

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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond that: the ordering guarantee (worst first), the platform requirement (SQL Server 2016 SP2+), and the operational significance of high VLF counts.

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?

Three tight sentences: what is returned and how it is sorted first, why it matters second, prerequisite last. No redundancy or filler.

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 zero-required-parameter read-only diagnostic with full annotation coverage and a fully documented single parameter, the description supplies enough context to invoke it confidently. No output schema exists, but the description does not characterize the return shape (column names, whether it includes log size), leaving a small gap.

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 parameter's meaning, default, and minimum are fully documented in the schema; the description merely restates the default of 1000. It adds no syntax or behavioral nuance for the parameter beyond what the schema provides, 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?

States a specific resource (virtual log files in transaction logs) and the exact selection/ordering rule: databases whose log has more VLFs than the threshold, worst first. No sibling tool covers VLF counts, so it is trivially distinguished from the rest of the mssql_* family.

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 sentence 'Many VLFs slow recovery, restores and log backups' gives clear diagnostic context for when to reach for this tool, and the version prerequisite is stated. It stops short of naming explicit alternatives or when-not-to-use conditions, but none are obviously required for a unique diagnostic.

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?

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds real behavioral context beyond that: idle waits are excluded, and the sampling mode changes the semantics of every returned number. It does not mention the blocking/timeout risk of a non-zero sample (that lives only in the schema), so a 4 rather than a 5.

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?

Front-loads what the tool returns, then the metric definitions, then the mode distinction — a sensible order. Dense but nearly every clause carries information; it is close to run-on in the metric enumeration but not wasteful.

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 usefully sketches the return shape (top wait types, percentage of all waits, average wait, signal %), and annotations cover the safety profile. The one gap is proximity to sibling wait/blocking diagnostics, which is left to inference.

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 are already documented, and the description largely restates sampleSeconds semantics (0 = since restart, 5 = live sample). It adds a little framing value but no syntax or constraints (ranges, timeout interaction) the schema doesn't already carry, making the baseline 3 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 and resource ('wait statistics: the top wait types'), then enumerates what is measured (CPU, I/O, locks, memory) and the returned metrics (% of all waits, average wait, signal %). An agent can distinguish this from siblings like mssql_blocking or mssql_running_requests without opening a schema.

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

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

Explicitly distinguishes the two operating modes: sampleSeconds=0 for cumulative-since-restart and sampleSeconds=5 as the 'what is slow right now' view. It does not, however, say when to prefer this tool over adjacent diagnostics like mssql_blocking or mssql_top_queries, so it stops short of full when/alternative routing.

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