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

With no annotations, the description carries the full burden and discloses important side effects: previous connection is auto-closed, successful connection returns table info and permission mode, and permission mode cannot be modified. It omits error handling and timeout behavior, but covers key operational traits well.

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 paragraph is front-loaded with the core action and supported databases, then details special cases efficiently using semicolons. It is information-dense but not repetitive, though a few clauses are redundant with the 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?

Given 10 parameters, 6 database types, and no output schema, the description covers connection behavior, return values (table list and permission mode), and database-specific quirks. An agent has enough context to invoke it correctly without opening the schema.

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 schema already documents all parameters thoroughly. The description reiterates some database-specific parameter usage (e.g., SQLite filepath, Oracle database as service name, MSSQL trustServerCertificate) but adds little beyond what the schema already states, so 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?

States a specific verb (connect) and resource (database), lists all supported database types, and distinguishes from siblings by describing what happens on connection (previous connection closed, returns table info and permission mode).

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 clear context for when to use it (to establish a connection before other operations) and implicitly warns that a new connection replaces the old one. However, it does not explicitly compare to siblings like disconnect or connection_status.

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, and it does deliver: it discloses that the tool performs a live ping with a measured latency and reports permission mode, which are behavioral traits not derivable elsewhere. It stops short of stating that the call is strictly read-only/non-mutating or whether it has side effects.

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, front-loaded with purpose followed by usage guidance; every clause earns its place by describing returned fields or the trigger condition. The return-field enumeration is somewhat dense but directly substitutes for the absent 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 and no annotations, the description must cover both behavior and return shape, and it does: it lists all result fields and the diagnostic purpose. An agent has everything needed to decide 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?

The tool takes zero parameters, so per the rubric the baseline is 4; there is nothing for the description to compensate for and it introduces no misleading parameter expectations.

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?

Starts with a specific verb+resource ('查看当前数据库连接的状态') and enumerates exactly what the result contains: connection boolean, database type, ping health with measured latency, table list, and permission mode. This is clearly distinguishable from siblings like connect, disconnect, query, or list_tables.

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 two trigger conditions: after a long period of inactivity, or when an execution failure is captured. It does not name alternative tools or state when not to use it, but the conditional guidance is concrete and actionable.

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 carries the full disclosure burden. It usefully details the return payload (structure, relations, size magnitude, sample values), but says nothing about whether sampling executes real queries on large tables, permission/auth requirements, or read-only safety. The payload disclosure is valuable but behavioral traits are only partially covered.

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 sentences, front-loaded with the return contents, followed by the schema-locating rule and the pre-SQL usage note. No filler, though the final sentence slightly retreads the enumerated return list.

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 (and does) enumerate the return fields, making it callable without guessing. With no annotations either, it is nearly complete, with minor gaps only around cost/side effects of sampling.

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 schema already documents all three parameters. The description adds genuine value beyond the schema by explaining when the 'schema' parameter matters (PostgreSQL/MSSQL/Oracle disambiguation across same-named tables), which the schema text only states flatly.

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 verb+resource ('查看指定表的详细信息') and enumerates exactly what is returned: column definitions, indexes, foreign keys, estimated row count, and data sampling. This clearly distinguishes it from siblings like list_tables and search_schema, which do not return full structural detail.

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 timing guidance ('LLM 在写 SQL 前调用此工具', call before writing SQL) and a conditional rule for when to pass schema. However, it does not name alternative tools (e.g. search_schema, list_tables) or state exclusions, so it falls short of the full when/when-not/alternatives standard.

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 carries the full burden and does well: it discloses that the connection pool is released, that subsequent query/execute calls will fail until connect is invoked, and that the operation is idempotent and safe when already disconnected. It does not state the return/confirmation value, though no output schema exists to cover that.

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 action and effect, followed by the consequence and the idempotency note. 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 zero-parameter, annotation-free lifecycle tool with no output schema, the description covers the action, its side effect on the connection pool, the required follow-up (connect), and the no-op case. Only the observable result of a successful call is left unstated, 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?

The tool takes zero parameters, so there are no parameter semantics to explain; the baseline for a parameterless tool applies. Nothing in the description misrepresents the empty input 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 verb and resource ('主动断开当前数据库连接并释放连接池'), and explicitly distinguishes itself from the sibling connect tool by naming it as the required follow-up action. An agent can tell immediately this tears down a connection rather than establishing or inspecting one.

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 clear sequencing guidance: after disconnect, call connect again before query/execute. It also covers the edge case of calling while already disconnected. It does not spell out when an agent should prefer to keep a connection open versus close it, but the operative context is well covered.

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 and does well: it discloses mode-dependent permission behavior (which statement classes are permitted or blocked per mode) and the single-statement constraint. It stops short of stating error behavior, whether operations are transactional/atomic, or confirmation requirements, but the permission gating is genuinely valuable context beyond the 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?

A single well-formed sentence, front-loaded with the core action and immediately followed by the mode-conditional constraints. No filler and 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?

For a one-parameter write tool with no output schema and no annotations, the mode-gating rules are the essential missing context and are fully covered. Minor gaps remain around error/result behavior, but nothing critical for correct invocation is absent.

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 the single 'sql' parameter, so the schema already documents it. The description adds the important semantic that the SQL must be a write statement (DML/DDL per mode), which is meaningful, but provides no syntax, batching, or format detail beyond that. 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 states a specific operation (执行单条写操作 – execute a single write statement) and its exact scope, distinguishing it from the read-oriented 'query' sibling and the multi-statement 'transaction' sibling through the 'single write operation' framing. An agent can determine from the text that this tool mutates data rather than reading 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?

It explicitly conditions use on connection mode: DML only in readwrite, DML+DDL in full, and disabled in readonly, which is strong usage guidance. It does not, however, explicitly route the agent to alternatives for multi-statement writes (transaction) or reads (query), leaving some 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, the description carries the full burden and does disclose key traits: the SQL is not actually executed (a meaningful safety guarantee), it works under every permission mode, and the adapter auto-prefixes EXPLAIN. It stops short of describing the shape of the returned plan or any cost/latency 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?

Three tight sentences, purpose front-loaded, followed by constraints and the prefix-handling detail. Nothing is redundant and every clause carries usable 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 single-parameter tool with no output schema and no annotations, the description covers purpose, safety, permission scope, and input constraints. The one omission is any hint about the format of the returned execution plan, though without an output schema this is a minor 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?

There is only one parameter and schema description coverage is 100%, so the schema already documents 'sql' fully. The description's note about not needing the EXPLAIN prefix simply repeats what the schema field description says, adding no meaning beyond structured data — the baseline of 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?

States a specific verb and resource — obtaining the SQL execution plan for performance analysis — and scopes it precisely (SELECT/INSERT/UPDATE/DELETE/WITH only). The note that EXPLAIN does not execute the original SQL implicitly separates it from execution siblings like execute and query, so an agent can distinguish it 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 clear context: callable in all permission modes, limited to five statement prefixes, and no manual EXPLAIN prefix required. It never explicitly names an alternative tool (e.g. 'use execute for actual execution'), so routing is left partly to inference, but the conditions for valid use are well defined.

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 usefully discloses the schema-scoping rule and that results are non-system schemas, but says nothing about permissions, behavior for other database types, or ordering limits.

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 compact sentences with the main purpose front-loaded and behavioral detail following. No padding, though the opening sentence and the schema clause could be tightened slightly.

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 annotations, the description compensates by describing the returned 'tables' field structure (schema/name/comment) and the schema-filtering rule. Complete enough to call correctly, though permission and non-listed-DB behavior remain unspecified.

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 per the rubric the baseline is 4. The description correctly implies no input is needed beyond the active connection.

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 ('列出...所有表名与表注释') and adds return scope (names and comments only), which cleanly separates it from describe_table and search_schema. An agent can tell which tool returns a flat table listing 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?

Explains the schema-filtering behavior for PostgreSQL/MSSQL/Oracle, but frames it as return behavior rather than when to pick this tool over siblings like describe_table or search_schema. No explicit when-to-use or when-not-to-use 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?

With no annotations, the description carries the full burden and does disclose real behavioral traits: read-only safety, a hard 1000-row cap communicated via a limit field, and failure past QUERY_TIMEOUT_MS. It omits auth/connection prerequisites and what happens to rows beyond the cap, but the operational profile is well covered.

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 clauses with zero filler: capability and scope first, then limits, then the alternative tool. Every sentence earns its place and the most important constraint (read-only) is front-loaded.

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 covers the essentials an agent needs: allowed statement types, truncation behavior, timeout, and the explain alternative, including the limit field that stands in for an output schema. Missing only error/connection 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?

Only one parameter and schema description coverage is 100%, so the schema already documents the sql parameter. The description adds no syntax or format guidance for the query string, so the baseline of 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?

States a specific verb and resource (执行只读 SQL 查询) and enumerates the accepted statement types (SELECT / SHOW / DESCRIBE), which separates it from write-oriented siblings like transaction and execute. An agent can identify the tool's job 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?

Explicitly routes execution-planning needs to the explain tool (执行计划请使用 explain 工具), a clear condition-to-alternative mapping. It does not, however, distinguish this tool from the sibling execute or transaction, leaving some ambiguity for an agent choosing between SQL execution paths.

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 carries the behavioral burden. It usefully discloses the result cap of 50 hits, which is real operational context absent from structured fields. However, it does not state that this is a non-mutating read, nor anything about truncation signaling or connection 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 clauses that front-load the action and scope, then the usage context. No padding or redundancy; could only be improved by adding the alternative tools, which is a content rather than structure issue.

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 should ideally clarify what a hit looks like (table, column, type). It communicates the 50-result cap but leaves the shape of results to be discovered, which is a modest gap for a discovery-oriented 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%, so the single keyword parameter and its case-insensitive matching behavior are already documented in the schema. The description restates the same matching scope without adding format or syntax guidance, 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 verb (search) and resource (current database schema) with explicit match scope: table names, column names, and field types. It is clearly distinguishable from describe_table and list_tables in intent, though it does not name those siblings to reinforce the distinction.

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?

'Suitable for quickly locating relevant tables or fields in a large database' gives an implied usage context, but never states when to prefer this over list_tables or describe_table, nor any preconditions (e.g. requires an active connection). The routing guidance 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?

With no annotations, the description carries the full behavioral burden and does well: it discloses rollback-on-any-failure, commit-only-on-full-success, and the permission matrix (readonly disabled, readwrite DML-only, full DML+DDL). It omits failure/error return behavior and whether SELECTs are permitted inside, leaving a small gap for a mutation 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, front-loaded with the core transactional behavior, then permissions, then use cases. Every sentence adds 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?

For a one-parameter mutation tool with no annotations and no output schema, the description covers enough to call it confidently: atomicity contract, permission gating, and typical scenarios. It could be fuller on result/error reporting or handling of non-DML statements, but nothing essential 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% and the single 'sqls' parameter is already documented as an ordered array requiring at least one statement. The description's mention of sequential execution adds marginal reinforcement but no new syntax or format detail, 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 (execute) and resource (a group of SQL statements) with the defining constraint that they run inside a single database transaction. The all-or-nothing semantics clearly separate it from the sibling 'execute', which runs statements without an atomic wrapper.

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 concrete usage context ('atomicity for multi-step writes such as transfers and order creation') and references 'execute' for the permission model, implying that single/non-atomic statements belong there. It stops short of an explicit when-not-to-use rule, so it is not quite a 5.

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