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

With no annotations, the description carries the burden. It usefully discloses the contents of the returned metadata but does not state that the operation is read-only, how errors are handled for missing tables, or whether a database parameter is required.

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

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

A single sentence, front-loaded with the verb and resource, enumerates the key metadata fields without redundancy. Every word contributes meaning.

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

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

For a straightforward describe operation, the description covers the essential return content. Since no output schema exists, the explicit list of metadata fields partially compensates, though it omits response shape and failure semantics.

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

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

The input schema covers 100% of parameters with descriptions, so the schema does the heavy lifting. The tool description adds no additional parameter-level details, making 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 ('Get') and resource ('table metadata'), and enumerates exactly what is returned (columns, data types, nullability, max length, primary keys). This clearly distinguishes it from siblings like mssql_list_tables or mssql_execute_query.

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 explicit guidance on when to use this tool vs alternatives, and no mention of prerequisites such as needing an active connection or specifying a database. Usage is only implied by the tool name and description.

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

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

With no annotations, the description must carry behavioral transparency. It does disclose that the tool can execute mutating statements (INSERT, UPDATE, DELETE, EXEC), signaling side-effect risk. However, it does not mention transaction/commit behavior, result-set return, or whether DDL statements are supported.

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

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

The description is a single concise sentence that front-loads the verb and resource, then immediately lists relevant query types. No filler or redundant 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?

For a two-parameter tool this is minimal but workable: the agent knows what query to pass and can name a database. Missing output schema and annotations leave questions about result format and side-effect/commit behavior unanswered, so it is not fully complete.

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

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

Schema description coverage is 100% for both query and database, so the schema already explains the parameters. The description adds no extra meaning about parameter format, defaults, or the behavior of the optional database parameter.

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: 'Execute a T-SQL query' on the MS SQL database, and enumerates supported statement types (SELECT, INSERT, UPDATE, DELETE, EXEC). This clearly distinguishes it from sibling metadata tools such as mssql_list_tables and mssql_describe_table.

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 this is the general-purpose query execution tool, but it never explicitly says when to prefer it over siblings or when not to use it. No exclusions or alternative routing are provided; usage context must be inferred from the sibling tool names.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds the 'online' scoping detail, but omits important behavioral context such as whether it returns system databases, whether authentication is needed, what happens when parameters are omitted, and what the output format looks like.

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

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

The description is a single, front-loaded sentence with no filler or repetition. It is concise and immediately states the core action, though it sacrifices useful parameter and usage detail for brevity.

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

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

For a tool with no annotations, no output schema, and two undocumented parameters, the description is too sparse. An agent cannot fully determine how to invoke the tool correctly, what the parameters mean, or what the result will contain, leaving significant room for misconfiguration.

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

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

The schema has 0% description coverage and the description does not mention the 'server' or 'database' parameters at all. While 'server' is mildly self-explanatory, the 'database' parameter is confusing for a tool that claims to list all online databases, and an agent cannot determine whether it filters the listing or merely specifies connection context.

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 ('List') and resource ('all online databases') on the MS SQL Server, making the tool's purpose immediately clear. It is naturally distinct from siblings like mssql_list_tables and mssql_execute_query because it targets database enumeration at the server level.

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

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

The description gives no guidance about when to choose this tool over alternatives, such as when to use mssql_test_connection versus listing databases or when to use mssql_list_tables once a database is selected. The usage context is only implied by the tool's name and basic purpose, not stated.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the read-only nature implicitly via 'List', but does not mention permissions, whether system tables/views are included, behavior when no database is specified, or any side effects. For a tool with zero annotation coverage, this is a significant gap.

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

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

One concise sentence with no filler. The core operation and scope are front-loaded, and every word contributes value. The description is appropriately sized for a simple list operation.

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

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

For a simple two-parameter list tool with no output schema, the description plus schema covers the basic call. However, the lack of annotations, absence of usage guidance, and silence on behavior quirks (e.g., required database despite schema marking it optional) leave moderate gaps. It is minimally viable but not richly complete.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema. The description adds only a mild rephrasing of the database parameter ('specified MS SQL database') and does not clarify the optional schema filter's format or default behavior. Baseline 3 is appropriate since the schema carries the parameter meaning.

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

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

The description uses a specific verb ('List') and clear resource ('all tables and views in a specified MS SQL database'). It distinguishes this tool from siblings like mssql_list_databases and mssql_describe_table by naming the exact object types and database 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?

The description gives no guidance on when to use this tool versus alternatives. It does not mention that mssql_list_databases should be used first to find available databases, nor does it explain when mssql_describe_table would be more appropriate. Usage context is left entirely 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?

With no annotations present, the description carries full responsibility for behavioral disclosure. It reveals that the tool tests connectivity and returns version/metadata, but says nothing about side effects, authentication needs, failure behavior, or whether any operation is read-only.

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

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

The description is a single, front-loaded sentence with no filler or repetition. Every word contributes to identifying the tool's purpose and output.

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

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

The tool is simple and the schema documents its optional parameters, but without annotations or an output schema, the description should say more about what 'metadata' includes and what happens on failed connections. It is adequate for basic invocation but leaves notable gaps.

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

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

Schema description coverage is 100%, so the input schema already documents all five parameters. The description adds no extra parameter-level meaning, which keeps it at the baseline 3 rather than higher.

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 action ('Test connection'), a clear resource ('MS SQL Server'), and a concrete outcome ('retrieve server version and metadata'). This distinguishes it cleanly from sibling tools that list databases, tables, describe schemas, or execute 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?

No guidance is given about when to run this tool versus listing databases, describing tables, or executing queries. The intended use as a connectivity preflight is only implied by the name and description, with no explicit exclusions or alternative routing.

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