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

readOnlyHint=true already tells the agent this is a safe non-mutating call, so the bar is lower. The description does add real value by disclosing exactly what the payload contains (columns, types, indexes, foreign keys). It says nothing about failure behavior for a nonexistent table, dialect-specific DDL formatting, or whether the statement is reconstructed vs. stored.

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 returned artifact and followed by the enumerated contents. No filler, no restatement of the tool name, nothing to 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 only two parameters, no output schema, and a read-only annotation, the surface area is small, and the return-content clause covers the most important unknown. The remaining gap is parameter meaning — particularly how to disambiguate a table across databases — which an agent needs in order to call this 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?

Schema description coverage is 0%: neither `table` nor `database` carries any documentation. The description supplies none either, leaving open whether `table` accepts a qualified name, whether case matters, and what omitting the nullable `database` defaults to. With zero coverage the description was the only place to compensate, and it does not.

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 and resource ('Return the CREATE TABLE statement') and enumerates the content returned: columns, types, indexes, foreign keys. That is far more informative than a tautology. It stops short of contrasting itself with list_tables or query, though the DDL-returning nature makes it implicitly distinct.

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

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

There is no explicit when-to-use statement, no prerequisites, and no named alternative such as 'use list_tables to enumerate tables first' or 'use query to inspect rows'. The use case (inspecting a single table's structure) is strongly implied by the description but 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 readOnlyHint=true, so the safety profile is covered. The description adds real behavioral context in saying the results are limited to what the configured MySQL user can see, but it says nothing about the returned shape (names only?) or ordering, and there is no output schema to fill that 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 front-loaded sentence with no filler; the scope qualifier follows the verb-resource statement rather than burying it. 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?

For a zero-parameter, read-only listing tool this is nearly sufficient: purpose and privilege scoping are clear and annotations cover safety. The only shortfall is that with no output schema, a brief note on what the list contains (database names) would fully close the loop.

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 no parameter semantics to explain and the baseline of 4 applies. The description correctly implies the call needs no arguments.

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 ('List the databases') and adds a scoping qualifier ('visible to the configured MySQL user') that tells the agent the result is privilege-dependent. The resource is distinct enough from siblings list_tables and describe_table that no explicit contrast is needed, though the description never names them.

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

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

Usage is only implied: an agent can infer this is a discovery step before calling list_tables or query, but the description never says so or states any precondition. No when-not-to-use or alternative routing 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?

readOnlyHint=true already covers the safety profile, and the description adds two useful facts beyond it: that views are included alongside tables, and that row counts are approximate rather than exact. It still omits cost/pagination behavior for large schemas, which keeps it from 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?

A single sentence that front-loads the action, resource, and default, with no redundant or filler wording.

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 annotations and no output schema, the definition covers scope, defaults, and return fidelity adequately. Only the shape of the returned rows (name, type, row count columns) is left implicit.

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?

With 0% schema description coverage and a single optional parameter, the description supplies the missing meaning by naming the default database (MYSQL_DATABASE). This is exactly the compensation needed, though it does not explain the expected string format or how an unknown database is reported.

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 and resource ('List tables and views in a database') plus a scope detail (approximate row counts), which clearly separates it from list_databases and describe_table. It does not name a sibling explicitly, 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: an agent can infer this is the schema-discovery step before describe_table or query. There is no explicit 'use this instead of X when Y' guidance or statement of 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?

Beyond the annotations, it discloses truncation behavior at MYSQL_MAX_ROWS and the different return shape for writes ({rows_affected, last_insert_id}), both of which an agent needs to reason about result handling. The caveat that writes are possible when the server runs with MYSQL_ALLOW_WRITE=true adds context the readOnlyHint annotation cannot express, though it sits in mild tension with a blanket readOnlyHint=true; it does not contradict the annotation for the default configuration. Missing: error behavior and whether multi-statement input is rejected.

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 plus a conditional clause; return shape and truncation semantics are front-loaded before the read-only caveat. Nothing is filler and no sentence merely restates the tool name.

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 returns and does so for both read and write paths, including the truncation flag. It falls short only on the `database` parameter and on failure modes, which are meaningful for a tool that executes arbitrary SQL.

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 0%, so the description must compensate for two undocumented parameters, and it only partially does. 'One SQL statement' usefully constrains the `sql` parameter's expected shape, but the `database` parameter (default null) is never explained at all — an agent must guess whether it overrides the session's current 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 opens with a specific verb and resource ('Run one SQL statement'), which is unambiguous and clearly distinct in kind from the schema-introspection siblings list_databases/list_tables/describe_table. It never explicitly names those siblings as alternatives, but the gulf between 'arbitrary SQL' and 'enumerate schema objects' is large enough that an agent will not confuse them.

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

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

It gives a real constraint ('one SQL statement', read-only unless MYSQL_ALLOW_WRITE=true), which implicitly tells the agent this is the general-purpose path. However, it offers no explicit routing such as 'use describe_table instead of DESCRIBE via SQL', leaving the agent to infer when to prefer the specialized siblings.

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