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

With no annotations, the description must disclose behavioral traits. 'Get' implies read-only, but it does not mention error behavior on missing tables, permission requirements, or compatibility with views. It leaves room for ambiguity, though the read-only implication is clear.

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

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

The description is a single sentence with no fluff. It is front-loaded with the verb and clearly conveys the tool's output, making it efficient to parse.

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

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

Given there is no output schema, the description provides a useful summary of the return contents (column structure, indexes, CREATE statement). However, it omits details about return format, error handling, or operational nuances, leaving moderate gaps for a simple describe 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 input schema already provides descriptions for both parameters (database and table), so schema coverage is 100%. The description only repeats 'for a table' and adds no extra parameter semantics, so it relies entirely on 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 uses the specific verb 'Get' and names three concrete outputs (column structure, indexes, CREATE statement) for a table. This clearly distinguishes it from siblings like mysql_query (arbitrary queries) and mysql_list_tables (just table names).

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

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

The description offers no guidance on when to use this tool versus alternatives. It does not mention use cases, when not to use it, or recommend alternatives such as mysql_query or mysql_list_tables, leaving the agent to infer context.

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

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

No annotations are provided, so the description carries the full burden. It discloses a medium risk level and the default rejection of UPDATE/DELETE without WHERE, which is valuable safety behavior. However, it does not explain return values, transaction semantics, or whether the 'by default' can be overridden.

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

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

Two concise sentences with no redundant information. The risk level is front-loaded, and the key safety behavior is immediately stated.

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

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

The description covers the core purpose and a key safety rule, but for a mutation tool it lacks information about return values, error handling, or transactional behavior. The schema covers parameters well, but the absence of output schema and annotations leaves some 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?

The schema already describes all three parameters (sql, params, database) with 100% coverage, so the description adds no additional parameter details. Per the rubric, baseline 3 is appropriate.

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

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

The description uses a specific verb 'Execute' and explicitly names the DML statement types (INSERT, UPDATE, DELETE), clearly distinguishing it from sibling tools like mysql_query (likely for reads). It also adds a useful safety constraint about WHERE-clause rejection.

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

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

The description implies usage for write operations by enumerating INSERT, UPDATE, DELETE, which contrasts with read-oriented sibling tools. It does not explicitly name alternative tools or state when not to use, but the operation types provide clear context.

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

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

With no annotations provided, the description carries the full burden for behavioral disclosure. It reveals the return value (execution plan and full-scan warnings) but does not explicitly state that the query is not executed or that data is unchanged. This is a notable gap for an AI agent that might need to know the operation is non-destructive. The read-only nature is implied by 'EXPLAIN' but not explicitly confirmed.

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

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

The description is two sentences long, front-loaded with the action and purpose, and then details the return value. Every word earns its place, with no unnecessary detail or repetition.

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 two parameters and no output schema, the description is mostly complete: it states the action, scope, and return type. It misses the explicit note that the SELECT is not executed, which would be helpful for safety awareness, but otherwise covers the essential context well.

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

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

The schema description coverage is 100%: the sql parameter is described as 'SELECT statement to analyze' and database as 'Target database (optional).' The tool description adds no further parameter semantics, so the baseline of 3 applies since the schema already documents both parameters effectively.

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 'Run EXPLAIN on a SELECT statement to analyze query performance,' which clearly identifies the specific verb (run EXPLAIN), resource (SELECT statement), and purpose (query performance). It distinguishes itself from siblings like mysql_query and mysql_execute by focusing on analysis rather than execution.

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

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

The phrase 'analyze query performance' sets a clear context for when to use this tool: when you need to inspect the execution plan or check for full-scan warnings. It does not explicitly mention alternatives or exclusions, but the context is sufficient to infer it should be used over direct query execution for performance 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?

No annotations are provided, so the description carries the full burden. It adds a behavioral detail (excludes system databases) but does not disclose return format, error cases, or explicitly confirm it is a read-only operation. For a listing tool, this is adequate but not rich.

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

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

The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the core purpose and a key behavioral constraint.

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

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

Given no output schema and no annotations, the description is slightly under-specified. It does not mention what the returned data looks like (e.g., a list of strings) or potential errors, but for a simple list tool, the information provided is largely sufficient.

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 and schema coverage is 100%, so the schema fully documents inputs. Baseline for 0 params is 4; the description adds no parameter information but none is needed.

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

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

The description clearly states a specific verb ('list') and resource ('databases'), and adds scope ('all accessible') and an exclusion ('system databases are excluded'). This clearly distinguishes it from sibling tools like mysql_list_tables or mysql_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 usage (when you need to list accessible databases) but does not explicitly mention alternatives or when-not-to-use. Sibling tools like mysql_list_tables make the purpose contextually clear, but no direct guidance is provided.

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

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

No annotations are provided, so the description carries the full burden. It only states the function, without disclosing behavioral details like return format, inclusion of views, behavior on missing databases, or that it is a read-only operation. The verb 'list' implies non-destructive but is not explicit.

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

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

The description is a single concise sentence with no redundant wording, making it appropriately sized for a simple listing tool.

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

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

For a one-parameter tool with no output schema, the description is minimally sufficient. However, it does not explicitly state the return value (e.g., an array of table names) or any edge case behavior, leaving some ambiguity.

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 description adds no meaning beyond the schema's 'Database name' parameter. Schema coverage is 100%, so the baseline 3 is appropriate; the description does not compensate with additional parameter details.

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

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

The description uses the specific verb 'list' and resource 'tables' with a scope 'in a database', clearly distinguishing it from siblings like mysql_list_databases (lists databases) and mysql_describe_table (describes a single 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 provides no guidance on when to use this tool versus siblings, such as before querying or for enumeration. No alternatives or exclusions are mentioned.

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

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

With no annotations provided, the description must convey safety and operational behavior. It states the operation is a SELECT query (non-destructive) and that results are automatically limited, which are useful behavioral traits. However, it doesn't explicitly state it is read-only, doesn't mention the default/max limit values (though schema does), and doesn't discuss any potential error conditions or permission requirements. The description adds some transparency but is not comprehensive.

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

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

The description is three sentences, each providing essential information: the operation, the return payload, and the auto-limit behavior. No superfluous language; it is easy to scan and immediately communicates the tool's core purpose and caveat.

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 4-parameter tool with full schema descriptions and no output schema, the description gives a clear summary of return values (rows, field names, row count) and the auto-limit behavior, which is the key operational constraint. However, it lacks any mention of the relationship to sibling tools (e.g., mysql_execute for writes), which would complete the context. Overall, it covers the most important aspects well.

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 every parameter (sql, limit, params, database) has a description. The description adds no additional parameter semantics, so baseline 3 is appropriate. It does mention that results are returned, but not specific to parameters.

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

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

The description clearly states the tool executes a SELECT query and returns structured results (rows, field names, row count). It uses the specific verb 'Execute' and resource 'SELECT query against MySQL', but does not explicitly differentiate from sibling tools like mysql_execute, though 'SELECT' narrows the 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 does not provide any guidance on when to use this tool versus alternatives. It implies it is for SELECT queries but never mentions that mysql_execute handles write operations or other non-SELECT statements. There are no explicit exclusions or comparable use cases.

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