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

With no annotations, the description must carry the behavioral disclosure burden. It discloses the core restriction and that stop_on_error controls whether execution halts on error, but it does not explain what happens with invalid statements, whether execution is transactional, or what side effects occur beyond modifying column comments.

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 compact and front-loaded: a one-sentence purpose plus a short parameter list. Every sentence contributes useful information with no filler 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?

It covers the main purpose and both parameters, and an output schema exists so return-value documentation is less critical. However, with no annotations, a batch SQL-writing tool would benefit from more context about validation behavior, error handling for disallowed statements, and transaction or rollback 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?

Schema description coverage is 0%, so the parameter explanations in the description are essential. They add real meaning: sql is defined as multiple COMMENT ON COLUMN statements separated by semicolons, and stop_on_error is described as whether to stop when encountering errors during execution. This meaningfully exceeds the bare 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 clearly identifies a specific verb and resource: it batch-executes field comment SQL and explicitly restricts execution to COMMENT ON COLUMN statements. This distinguishes it from broad siblings like execute_sql and execute_sql_file.

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 allowed statement type is stated ('仅允许 COMMENT ON COLUMN 语句'), which implies when the tool is appropriate. However, it does not explicitly mention alternatives such as execute_sql or explain when not to use this tool, leaving sibling selection mostly 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?

No annotations are provided, so the description carries the behavioral disclosure burden. It usefully reveals the default-SCHEMA fallback behavior, but it does not state whether the operation is read-only, how errors are handled, or whether the count includes only tables or also views. The output schema covers return shape, but safety and edge-case behavior remain undocumented.

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 focused sentence that front-loads the action and immediately covers the optionality. There is no redundant phrasing or filler.

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 counting tool with one optional parameter and an existing output schema, the description covers the core behavior and the default case adequately. It could be slightly more complete with explicit read-only/error behavior or sibling differentiation, but nothing essential is missing for basic invocation.

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?

Although schema description coverage is 0%, the description fully compensates by explaining the one parameter's semantics: a specified SCHEMA is counted directly, while an unspecified one falls back to the default SCHEMA. This adds meaning beyond the raw nullable schema property.

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 the exact verb and resource: count the number of tables under a specified SCHEMA, and clarifies the default when none is provided. This clearly distinguishes it from siblings like list_tables, which would return table names rather than a count.

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 clear context for the schema parameter (specified vs. default schema) but provides no explicit guidance on when to choose this tool over siblings such as list_tables or execute_sql, and names no alternatives or exclusions. Usage is implied rather than fully articulated.

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 of disclosing behavior, but it only says SQL statements are executed. It does not state whether the tool is read-only, whether commits occur, what SQL dialects or operations are allowed, what happens with destructive statements, or what the response contains. The '强制限定配置' phrase suggests restriction but fails to define it concretely.

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 appropriately short and front-loads the main purpose before listing parameters. The parameter list is easy to scan and avoids excessive detail. The parenthetical is somewhat cryptic, but no sentences are wasted.

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 named execute_sql with multiple siblings, no annotations, and a potentially dangerous operation, the description is incomplete. It omits allowed SQL statement types, result format, pagination behavior, error handling, and security restrictions. An agent cannot confidently decide whether this tool will safely execute a given SQL statement or whether to choose execute_sql_file or list_tables instead.

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. The parameter list restates the schema names but does add minimal meaning: limit is for pagination, offset skips rows, and fetch_results controls result return. However, it does not explain how these interact, whether limit/offset apply to all statements or only queries, or what constraints exist on the sql 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?

The description clearly identifies the core action: '执行 SQL 语句' (execute SQL statements). The parenthetical '强制限定配置下的SCHEMA操作' adds some scoping, suggesting operations are constrained, but it is vague about whether this means schema-only, read-only, or sandboxed execution. It is distinguishable from execute_sql_file because it executes a raw SQL string rather than a file.

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 is given about when to use this tool versus its siblings like execute_sql_file, list_tables, or switch_schema. The parenthetical hints at a restricted configuration but never states the conditions under which execute_sql is appropriate or when another tool should be chosen. An agent is left to infer usage 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, the description carries the full transparency burden. It discloses two important behaviors: the file path must be inside the DAMENG_SQL_FILE_ALLOWED_DIRS whitelist, and SQL comments are stripped before validation/execution while string literals are unaffected. This is meaningful beyond the schema, though it does not mention mutation risks or error 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?

The description is compact: three sentences that front-load the core purpose, then add the critical path whitelist constraint and comment-stripping behavior. No filler or redundant repetition of 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?

While the description covers the key file-path constraint and a useful preprocessing behavior, it omits guidance on several operationally important aspects: what limit/offset/fetch_results/stop_on_error control, whether file execution can modify data, and how this tool relates to execute_sql for non-long queries. The presence of an output schema reduces the need to document return values, but parameter semantics remain incomplete.

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, but it only sheds light on file_path (via the whitelist constraint). The remaining parameters—limit, offset, encoding, fetch_results, and stop_on_error—are not given any semantic explanation in the description, leaving the agent to guess their roles.

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 that the tool reads and executes a SQL file, and explicitly positions it for handling ultra-long SQL, which differentiates it from the sibling execute_sql. It does not explicitly name the sibling or define the exact length threshold, so it stops short of a perfect 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?

The phrase '用于处理超长 SQL' provides clear context for when to use this tool: when SQL is too long to handle inline. It does not explicitly state when not to use it or name alternative tools, but the intended use case is unambiguous enough for an agent to make a reasonable selection.

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?

The description reveals what information is returned (current schema and allowed schemas) but does not disclose behavioral traits such as read-only status, whether connections are required, side effects, or failure modes. With no annotations available, the description carries the full burden and only partially covers it.

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 short sentence that directly states the tool's purpose. It is concise, front-loaded, and contains no filler or redundant 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 parameterless getter with an output schema available, the description adequately states what will be retrieved. It could be slightly more complete by noting typical use cases or read-only behavior, but no critical invocation information 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?

The tool has zero parameters, so there is no parameter semantics burden on the description. The description's mention of 'current configured database' and 'allowed schemas' adds meaningful context even though the input schema is empty.

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 clear action and resource: retrieve the currently configured database's schema and the list of allowed schemas. It is specific enough to convey the tool's core function, though it does not explicitly distinguish itself from sibling tools like list_tables or switch_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?

No guidance is provided for when to use this tool versus alternatives such as list_tables, switch_schema, or execute_sql. The intended context must be inferred entirely from the tool name and description, with no exclusions or selection criteria 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. The verb 'get' implies a read-only operation, and the description states the subject (directories allowed for execute_sql_file). However, it does not explicitly disclose that it has no side effects, returns a list of paths, or how the allowed directories are determined (configuration, environment). This is adequate for a simple getter but lacks depth.

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 that states the verb and object efficiently with no filler. It is appropriately sized for a tool of this simplicity.

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 low complexity (0 params) and has an output schema, so the description need not detail return values. It tells the agent exactly what information is retrieved. Minor gaps, such as what an empty result means or how directories are configured, are not essential given the output schema and the tool's simplicity.

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 has zero parameters with 100% schema description coverage (empty properties). The description adds no parameter-specific details, but with no parameters, the baseline of 4 applies. It implicitly communicates that the tool requires no arguments, which is correct.

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 ('获取' / get) and a precise resource ('execute_sql_file 允许读取的 SQL 文件目录' / the SQL file directories execute_sql_file is allowed to read). It clearly differentiates from sibling tools by tying the operation to execute_sql_file's permitted paths, leaving no ambiguity about what the tool returns.

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: an agent would call this when it needs to know which directories execute_sql_file can read from. However, the description does not explicitly state when to use it versus alternatives, nor does it mention prerequisites or consequences (e.g., checking before executing a SQL file). None of the sibling tools overlap, so the lack of exclusions is acceptable but not exemplary.

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 disclosure burden. It usefully reveals the default-schema behavior and implies a read-only query, but it does not disclose whether views are included, what happens for invalid schema names, or whether the current connection is used.

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 compact sentence that conveys both the main purpose and the important default behavior with 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 simple one-optional-parameter listing tool with an output schema, the description is nearly complete. The main gap is that 'default SCHEMA' is not defined or cross-referenced with get_current_schema or switch_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 0%, so the description must compensate. It does clarify that the optional 'schema' parameter selects the schema to list and that null/omission means the default schema, but it does not define how the default schema is determined or specify naming/case/quoting rules.

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 ('查询') and resource ('所有表'), and scopes it to a given schema or the default schema if none is given. It does not explicitly differentiate from sibling tools like count_tables or execute_sql, so it stops 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?

The description gives clear behavior for the optional schema parameter: if omitted, the default schema is queried. However, it provides no guidance on when to prefer this tool over siblings such as count_tables or execute_sql, nor any exclusions.

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 discloses that the tool changes the current schema and is only available under a specific configuration. It does not clarify the scope of the change, persistence, or error behavior, leaving some ambiguity.

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 a useful parenthetical constraint. It is front-loaded and contains no filler, though it could add a bit more practical guidance without becoming verbose.

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, but the description does not explain how to determine valid schema names, what happens to subsequent operations, or how to verify the switch succeeded. A bit more context would be needed for an agent to use it confidently.

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%, and the description adds little beyond the schema property name. The parameter's meaning (the target schema name) is implied, but there is no guidance on allowed values, formatting, or how to discover valid schemas.

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 action (switch) and a specific resource (the current operation's SCHEMA), and includes a configuration-based availability condition. It is distinguishable from siblings like get_current_schema, though it does not explicitly name alternatives.

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 that this tool is used to change the active schema for subsequent operations, and it gives a prerequisite (DAMENG_ALLOWED_SCHEMAS must be configured). However, it does not mention when to prefer this over related tools or explain the effect on later calls.

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 must carry the behavioral disclosure burden. It states the operation as testing connection status, which implies a read-only health check, but it does not describe failure behavior, return semantics, or whether any side effects occur. For a simple, zero-parameter test operation this is adequate but minimal.

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 short sentence in Chinese that fully communicates the tool's purpose with no redundant words or filler. It is maximally concise and 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 zero-parameter health-check tool with an output schema, the description provides enough information for an agent to select the tool. It could benefit from a note about what the output looks like on success/failure, but the output schema likely covers return structure, and the tool's simplicity keeps the description adequate.

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, so the baseline is 4. There is no parameter information in the description, but none is needed because the input schema is empty. The description cannot add meaning beyond the schema where no parameters exist.

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 action (test) on a clear resource (database connection status). It is distinct from sibling tools that execute SQL files, run queries, list tables, or manage schema, so an agent can immediately understand this is a connectivity health check.

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 explicitly state when to use this tool versus alternatives, but the name and description clearly imply it is for checking database connectivity. Since none of the sibling tools serve this purpose, the usage context is reasonably inferable, though no explicit guidance is provided.

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