Get Tables Info

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.