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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuine context beyond that: it does NOT read business rows and it validates permissions/types, telling the agent this is a structural check rather than a data read.

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 front-loaded clause stating the validation scope, the return value, and the negative constraint. Every element earns its place with zero 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?

There is no output schema, and the description at least states that a query-structure summary is returned. For a read-only validator with a self-describing nested query schema, this is largely sufficient, though the contents of the summary could be clearer.

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 60% - connection, database and schema carry good inline descriptions, but the large nested query object and timeout_ms are undocumented. The description adds nothing about individual parameters, so it relies on the schema; baseline 3 fits the moderate coverage.

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 (校验/validate) and resource (结构化查询 - structured query), plus the scope of validation (tables, fields, permissions, types) and what it returns (查询结构摘要). The tagline '不读取业务行' sharpens it against siblings like execute_query, though it never names them explicitly.

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: validating a query without reading rows suggests a pre-execution check, but the description never states when to reach for this vs explain_query or execute_query, nor any prerequisites. No explicit when/when-not guidance is given.

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 the full safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the description adds only the disclosure that address and credentials are not returned. That is useful because there is no output schema, but it is thin on behavioral context such as what 'dual read-only status' means or how hard limits are surfaced.

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, tightly packed sentence with the verb leading and the enumerated outputs following; the negative return clause is appended cleanly. No wasted words, though the density makes it slightly back-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 read-only verification tool with no output schema, the description lists what is checked but does not describe the shape or format of the result, which matters when no output schema exists. Annotations cover the safety dimension, leaving this mostly adequate but with a real gap in return expectations.

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 the schema already documents both required parameters with sourcing and prohibition rules (no guessing, no address/credentials). The description adds nothing beyond what the schema provides, which is the expected baseline.

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 gives a specific verb (验证/verify) and resource (a DBeaver connection) and enumerates the exact facets inspected: database, visible schemas, dual read-only status, server version, and hard limits. It also states a negative scope (no address/credentials returned). It does not name which sibling it complements, 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?

There is no explicit when-to-use or when-not-to-use guidance, and no alternative tool is named. The only workflow hint is indirect, carried by the parameter descriptions ('通过list_databases发现的...'), not by the tool description itself.

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 readOnly, idempotent and non-destructive, so the safety bar is lower, yet the description adds substantial context: read-only transaction, account-native read permissions with RLS, dependency security validation, parameter binding, and bounded results. This goes well beyond the annotations, though it does not address rate limits 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?

A single dense sentence that front-loads the core action before listing behavioral constraints. It is compact and free of filler, though the comma-separated clause list is somewhat telegraphic.

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 a deeply nested, complex query parameter, the description covers the execution/safety profile but says nothing about result shape, row limits actually returned, or timeout behavior. For a tool this complex, the return-value picture is 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 60% with the four connection/database/schema/query params partly documented in the schema itself. The description adds only the general notion of 参数绑定 and 有界结果 (implying limit behavior) and does not clarify connection/database/schema/timeout semantics, so it is a baseline-adequate contribution.

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 (服务端组装的结构化SELECT), which is clear and distinguishes it from catalog siblings. However, it does not explicitly contrast with query-analysis siblings like analyze_query or explain_query, so full sibling differentiation is missing.

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 when-to-use or when-not-to-use guidance is given, and the alternatives (analyze_query, explain_query, scan_database, search_catalog) are never referenced. The agent must infer that this is the execution tool versus the analysis tools.

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 establish readOnly/idempotent/non-destructive, and the description adds real behavioral value: it does not execute ANALYZE, returns a desensitized plan tree with costs, and hides condition values. That disclosure about masking and non-execution goes beyond the annotations.

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 dense sentence that front-loads what the tool does and immediately appends the key non-behaviors. It is compact and wastes no words, though the semicolon-separated clauses pack several ideas that could be slightly clearer.

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 5-parameter tool with 4 required params, a deeply nested query schema, and no output schema, the description adequately frames purpose and safety but does not explain the returned plan/cost structure or parameter expectations. It is minimally viable but leaves 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 60%, so the schema documents connection/database/schema but leaves timeout_ms and the nested query structure without descriptions. The description adds nothing about parameter syntax or format, so it neither compensates nor regresses; 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 (生成成本摘要) and resource (结构化SELECT读取计划), and clarifies it is a read-plan cost summarizer. However it does not explicitly differentiate itself from the sibling analyze_query, relying on the phrase '不运行ANALYZE' to imply the contrast.

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?

Implies usage for server-side structured SELECT costing and signals it will not run ANALYZE, which hints at when it is preferred over analyze_query. But it gives no explicit when-to-use/when-not guidance or named alternatives among the 13 siblings.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered structurally. The description adds genuinely new behavioral context by clarifying that no database connection is made, but it says nothing about the shape or format of the returned capability data.

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 compact clause pair, front-loaded with the three capabilities and ending with the key scoping constraint. Every element earns its place with no 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 zero-argument, read-only discovery tool with full annotation coverage and no nested parameters, the definition supplies enough to call it correctly. The only minor gap is that, absent an output schema, it does not hint at what the returned capability description looks like.

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, which is the baseline-4 case: there is nothing for the description to disambiguate and the empty schema is fully self-describing. No additional parameter semantics are 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?

States a specific verb (查看/view) plus three concrete resources: structured query capabilities, parameter language, and security restrictions. The clause '不连接数据库' implicitly separates it from execute_query/analyze_query siblings, though no sibling is named explicitly, which keeps it just shy 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 phrase '不连接数据库' signals this is a safe, non-executing inspection step, hinting a caller uses it to discover capabilities before invoking query tools. However, there is no explicit when-to-use statement or named alternative among the many query-oriented siblings (analyze_query, explain_query, execute_query), leaving usage 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, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral value by clarifying the read is metadata-only and explicitly excludes business row data, which is the key operational distinction. It does not cover error behavior, cost, or latency.

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 front-loaded sentence that first states the scope (connection → exact database/schema) and then the metadata categories, closed by a semicolon-delimited exclusion. No filler, no restatement 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?

With no output schema, the description usefully enumerates the returned metadata categories (columns, comments, keys, indexes, approximate row count) and explicitly scopes out row data, which is what an agent needs to decide whether to call it. Only finer return-shape details and pagination/limits are 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?

Schema coverage is 75%, with the 'table' parameter lacking a description in the schema. The description compensates by clarifying that table accepts either a table OR a view ('表或视图'), and by emphasising that database/schema must be exact ('精确'), reinforcing the precision requirement on parameters that would otherwise be guessable.

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 (读取/read) and enumerates exactly what metadata is retrieved: columns, comments, primary/foreign keys, indexes, and approximate row count, scoped to a precise database/schema. The explicit '不读取业务行' (does not read business rows) cleanly separates it from siblings like execute_query or scan_database.

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 states the operating context (metadata inside a specific DBeaver connection/database/schema) and provides one explicit exclusion ('does not read business rows'), which implicitly routes data-reading tasks elsewhere. It stops short of naming the alternative tool or stating prerequisites like 'connection must already exist' and 'database/schema must be discovered first', which the schema fields carry instead.

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 cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description still adds useful context by stating the result scope (only databases the current account can connect to) and what is returned (default DB, template flag, 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?

One compact sentence that front-loads the resource and scope and appends the return fields; 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 no-output-schema, single-parameter read tool, the description conveys scope, constraints, and the returned fields adequately. Output format details (ordering, pagination) are absent but not critical here.

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 a single parameter and 100% schema description coverage, the schema already documents the connection argument and its prohibition on addresses/credentials. The description adds nothing about the parameter beyond what the schema states, 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?

The description states a specific verb and resource (列出...数据库) and scopes it precisely to databases reachable by the current account under a DBeaver PostgreSQL connection. The resource noun inherently separates it from siblings like list_schemas, though no sibling is named explicitly.

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 scope (per-connection, current-account databases) implies when the tool applies, but there is no explicit when-to-use guidance or routing to alternatives such as list_schemas or list_dbeaver_connections.

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, idempotentHint and non-destructive behavior, so the safety profile is covered. The description adds genuinely useful disclosure beyond that: it explicitly states that addresses and credentials are NOT returned, which is a meaningful data-disclosure boundary an agent cannot derive from the annotations.

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 compact sentence with the resource and scope front-loaded and a semicolon-delimited exclusion clause. Every element earns its place with no 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?

With no output schema, the description carries the return-value burden, and it does explain that each connection comes with a usable-database summary and that sensitive fields are omitted. Ordering, pagination and count details are unstated, but for a zero-parameter read listing they are minor 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 tool takes zero parameters, so the baseline is 4; there is nothing for the description to document semantically. It correctly avoids inventing parameters or filter syntax that does not 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?

States a specific verb (列出) and resource (DBeaver中已有且可用的PostgreSQL连接), plus the scope (available/usable connections) and the return content (数据库摘要). An agent can tell this apart from list_databases, which enumerates databases within a connection, without opening either 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 explicit when-to-use or when-not-to-use guidance, and no sibling is named as an alternative. The implied workflow (find a connection before calling list_databases) is inferable but left to the agent, which is the definition of minimum-viable usage 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds that only visible schemas are returned and that table/view/object counts are included, but it does not cover permission requirements, pagination, 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?

One front-loaded sentence states scope and return content without filler. It is 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?

This is a low-complexity listing tool: annotations cover safety, schema covers both required params, and the description states the returned content (schemas and counts). Missing output format and explicit usage sequencing keep it from being 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%; both required parameters have detailed schema-level descriptions. The tool description adds no parameter-level detail beyond that, 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?

The description states a specific verb (列出/list) and resource (可见schema及每个schema的表、视图和对象计数) within an exact DBeaver connection/database. It is clearly distinct from sibling tools like list_databases and table-level tools.

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 tool description gives no when-to-use, prerequisites, or alternative guidance. The only routing hint appears in the schema field description for database ('通过list_databases发现...'), not in the description itself.

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 cover read-only, idempotent and non-destructive semantics, and the description adds genuinely new context: results are scoped to the current account's visibility and sensitive config values are masked (脱敏). It does not, however, describe output shape or any permission requirements beyond account scope.

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 compressed sentence front-loads the action, scope, replacement semantics and the masking guarantee. Nothing is wasted, though the density leaves the 'names' filter unexplained.

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 3-parameter read tool with no output schema, the description covers what the tool is and its safety-relevant behavior, but omits what the returned settings look like and the purpose of 'names'. Adequate but leaves clear 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 coverage is 67%: database and connection carry explicit constraints (must come from list_databases / DBeaver connection list, no addresses or credentials), while 'names' is undocumented. The description adds no parameter-level meaning, so it neither compensates for nor extends 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?

States a specific verb+resource (read database configuration) and narrows scope with 'visible to the current account'. The 'replaces SHOW/SHOW ALL' clause helpfully distinguishes it from raw-query siblings like execute_query, though no sibling tool is named directly.

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?

'替代SHOW/SHOW ALL' gives an implied when-to-use signal by routing agents away from running SHOW manually via execute_query. However, it offers no explicit when-not or named alternative among the large sibling set (scan_database, search_catalog, etc.).

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 the full safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description nevertheless adds genuine behavioral context: output is limited to security-event summaries, it does not accept user-supplied paths, and it will not return raw SQL/messages — useful constraints that go beyond the annotations.

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 dense, front-loaded sentence that leads with the verb and resource and then appends constraints; there is no filler. The clauses are packed but each carries information, so only minor readability cost.

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 6-parameter tool with no output schema, the description covers the target and output scope adequately, and annotations cover safety. The gap is the undocumented input parameters (limit, since, levels, max_bytes), which an agent needs to call the tool 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 only 33% (2 of 6 parameters documented), so the description must compensate. It clarifies only the data source (exact database, no paths) and says nothing about limit, since, levels, or max_bytes, leaving half the input contract unexplained in both the schema and the prose.

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 (读取/read) plus resource (PostgreSQL 当前 JSON/CSV 日志尾部) and the scope constraint (精确 database, log tail). An agent can immediately distinguish this from read_database_settings or execute_query 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?

Usage is implied by the resource ('read the log tail for a specific database'), and there is a boundary statement ('不接收路径... 不返回SQL/原始消息'). However, no explicit when-to-use vs alternatives or when-not conditions are given, and no sibling tool is named to route the agent.

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds genuine value beyond them: it enumerates what is returned (object type, comment, approximate row count, counts) and, critically, states what is NOT done ('不读取业务行'). It stops short of disclosing cost/limits of the approximate row counting.

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 front-loaded clause leads with the verb and scope, and every element earns its place, including the terminal negation '不读取业务行' which meaningfully bounds behavior. 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 read-only catalog scanner with no output schema, the description adequately establishes scope and return contents, and annotations carry the safety profile. But it says nothing about the filtering parameters (name_pattern, object_types) or the limit/pagination behavior, leaving the 50% schema-coverage gap unaddressed.

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 50%: connection, database, and schema carry rich descriptions, but limit, name_pattern, and object_types have none. The description adds no parameter-level meaning at all, so it does not compensate for the undocumented half. Baseline 3 given the schema already handles the required 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?

States a concrete verb (扫描/scan) and resource (表/视图目录 - table and view catalog) scoped to an exact database/schema within a DBeaver connection, and explicitly notes it does NOT read business rows. The scope is well drawn, but siblings like search_catalog and get_table_context are not named in the description itself for differentiation.

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: the 'returns metadata, does not read business rows' framing signals a catalog-inspection use case as opposed to a data-reading one. However, the description never says when to prefer this over search_catalog, list_schemas, or get_table_context; that routing only appears in the schema-level description of the 'schema' parameter.

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 readOnly, idempotent, non-destructive, and closed-world behavior, so safety is covered. The description adds a scope behavior: omitting schema searches all visible non-system schemas. It does not describe return format, pagination, or authentication beyond what annotations and schema provide.

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 separated by a semicolon. It immediately states what is searched and then gives the schema-omission behavior. No words are wasted, and it is appropriately sized for a read-only search 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?

The definition is adequate for invocation: required parameters and key semantics are covered. However, with no output schema, the description does not explain what results look like, and it omits return or pagination behavior. Annotations and schema descriptions carry much of the context, leaving some gaps but not enough to prevent correct use.

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 descriptions cover 60% of parameters (connection, database, schema), and the description adds meaning for the query parameter by specifying table/column/comment search. It also restates the schema-omission behavior already documented on the schema parameter. It does not clarify the limit parameter or compensate fully for the uncovered 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?

Description states a specific verb (搜索/search) and resource (精确database目录/exact database catalog), and specifies search fields: table name, column name, or comment. It also clarifies default schema scope when schema is omitted. It does not explicitly differentiate from siblings like scan_database or get_table_context, so it misses the top tier.

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 by the stated search fields and the note that schema can be omitted to search across all visible non-system schemas. However, there is no explicit guidance on when to prefer this tool over scan_database, get_table_context, or list_schemas, and no exclusions or prerequisites are given.

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