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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds no further behavioral context (e.g., permissions, performance implications) beyond stating that it returns structure information, thus adding some but limited value.

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 concise with two clear sections (Args and Returns), no redundant words, and front-loaded with the main action. Every sentence contributes meaningful 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?

Given the simple parameter set (2 params, 1 required) and the presence of annotations indicating safety, the description provides sufficient detail about the return structure (columns, types, etc.) and default schema behavior. No output schema needed.

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 description essentially repeats the schema's parameter descriptions without adding new semantics such as format constraints or examples. Baseline score 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 uses a specific verb ('Get detailed structure') and explicitly names the resource ('table or view'), clearly distinguishing it from sibling tools like kb_list_tables, kb_list_indexes, and kb_list_constraints, which serve different purposes.

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 purpose of obtaining table structure is clear, but the description does not provide explicit guidance on when to use this tool over alternatives such as kb_table_stats or kb_explain. However, the sibling tool names and the context of schema exploration imply appropriate usage.

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 indicate destructiveHint=true. The description adds crucial details: returns number of affected rows, parameterized queries for safety, and the auto-schema qualification feature, all beyond what annotations 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?

Well-structured with sections, front-loaded purpose, and efficient use of brief bullet-like list for Args and Returns. No unnecessary words.

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?

Covers main purpose, parameters with examples, and return value. Though no output schema, the return type is explicitly stated. Could mention error handling, but adequate for a DML execution 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 coverage is 100%, so baseline 3. The description adds value by explaining the auto-schema behavior for the 'schema' parameter and providing real examples for params, enhancing understanding beyond the schema.

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

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

The description clearly states the tool executes DML statements (INSERT, UPDATE, DELETE) against the KingBase database, distinguishing it from query and DDL tools among siblings.

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 (DML operations) and includes examples. Could explicitly mention not to use for SELECT or DDL, but the sibling names imply the distinction.

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 explicitly warns that DDL operations modify database structure and that DROP/TRUNCATE are irreversible. It also details the confirmation message and warnings for dangerous operations. This adds behavioral context beyond the destructiveHint annotation, which is already true.

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 well-structured with sections (warning, auto-schema, args, returns, examples) and front-loaded with the warning. It is slightly lengthy but each sentence adds value; 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?

Given the tool has no output schema, the description adequately states the return is a confirmation message with optional warnings for dangerous operations. It covers all key aspects: purpose, parameters, behavior, and examples, leaving no major 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 100%, so the schema already documents parameters. The description adds meaning by explaining the auto-schema feature for unqualified table names and how the optional 'schema' parameter overrides the default. Examples further clarify usage.

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

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

The description clearly states the tool executes DDL statements (CREATE, ALTER, DROP, TRUNCATE) against KingBase, using a specific verb and resource. It distinguishes from sibling tools, which include query, description, and other non-DDL operations, making the purpose unambiguous.

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

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

The description provides a warning about destructive operations and explains auto-schema qualification, but does not explicitly contrast with sibling tools like kb_execute or specify when not to use it. However, the warning and focus on DDL implicitly guide usage.

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 notes that setting analyze=true actually executes the query, which is a critical behavioral detail beyond the annotations. Annotations indicate readOnlyHint=false and idempotentHint=true; the description clarifies the execution risk when analyze is true. Missing is any mention of locking or performance impact of ANALYZE.

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 concise, well-structured with paragraphs and examples, and every sentence adds value. It fits within a few lines without 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?

Given the tool's simplicity and the lack of an output schema, the description adequately explains the return type ('execution plan showing scan types, costs, and join strategies'). No missing context for agent usage.

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?

All three parameters (sql, analyze, format) are fully described in the input schema, and the description adds examples and clarifies the effect of analyze and the format options. Schema coverage is 100%, and the description complements it well.

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 explicitly states the tool's purpose: 'Get the execution plan for a SQL query using EXPLAIN.' This clearly distinguishes it from sibling tools like kb_query (which executes) and kb_execute (which runs DML).

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 says 'Use this to analyze query performance, identify full table scans, and optimize queries,' providing clear context for when to use. It lacks explicit when-not-to-use guidance, but the context is sufficient given the sibling 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 indicate read-only and idempotent behavior. The description adds return structure details (name, type, columns, referenced table for FK), providing transparency beyond 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?

Two sentences for purpose, then structured Args/Returns sections. Front-loaded and no unnecessary words.

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 tool with no output schema, the description covers parameters and return structure adequately. Missing error handling but overall 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 coverage is 100%. The description adds the default value for schema (from DB_SCHEMA env or 'public'), which is not in the schema descriptions.

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 'List all constraints (PK, FK, UNIQUE, CHECK) on a table.', specifying both the action and the resource. It distinguishes from siblings like kb_list_indexes by naming constraint types.

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 on when to use this tool vs alternatives. The description implies usage for constraint listing but doesn't provide context or 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, indicating a safe read operation. The description adds useful context about default schema behavior and the specific fields returned, enhancing transparency beyond structured fields.

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 succinct, using a clear docstring format with Args and Returns sections. Every sentence adds value, and the purpose is front-loaded in the first sentence. No redundant or irrelevant 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 simple read-only list tool, the description covers the input parameters, default behavior, and return structure comprehensively. Annotations confirm safety, and no output schema is needed since the return is self-explanatory. The tool is fully specified for agent 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 description coverage is 100% and the description repeats the same parameter descriptions verbatim, adding no new meaning beyond what the input schema provides. Baseline score of 3 is appropriate since the schema already documents both parameters adequately.

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?

Clearly states 'List all indexes on a table including columns, uniqueness, and index type,' specifying the exact resource and returned attributes. Differentiates from siblings like kb_list_constraints and kb_describe_table by focusing on indexes.

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?

Describes what the tool does but does not provide explicit guidance on when to use it versus alternatives such as kb_list_constraints or kb_describe_table. The description is adequate but lacks exclusion criteria or context for selection among ten sibling 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 declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds behavioral detail: it excludes system schemas and returns schema names with owners. This goes beyond annotations by clarifying scope and return format.

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 extremely concise (2 sentences plus structured Args/Returns). Every sentence adds value: purpose, scope (excludes system schemas), and return content. No wasted words.

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

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

For a simple read-only listing tool, the description is complete. It covers what the tool does, what it excludes, what it returns, and that it takes no arguments. Annotations cover safety, and no output schema is needed given the verbal description of return values.

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 no parameters, and the input schema confirms this (100% coverage). The description explicitly states 'Args: None', which provides clarity. With 0 parameters, baseline is 4.

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

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

The description clearly states the tool lists all schemas in the KingBase database, distinguishing it from sibling tools focused on tables, queries, and execution. The verb 'List' and resource 'schemas' are specific and unambiguous.

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 mentions that it returns schema names excluding internal system schemas, which provides context on when to use it (to get clean user schema lists). However, it does not explicitly state when not to use it or suggest alternatives, though sibling tool names make the distinction clear.

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 indicate idempotent, read-only, non-destructive behavior. The description adds information about the return format (type, owner, estimated row count) and default parameter values, which is beyond what annotations 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 sentence followed by a structured list of arguments and returns. Every part is necessary, concise, and front-loaded with the core purpose.

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 list tool with full schema coverage and annotations, the description covers the key aspects: purpose, parameters, and return structure. It lacks details about edge cases (e.g., empty schema) but is otherwise 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 coverage is 100%, so baseline is 3. The description adds value by specifying the default for 'schema' from DB_SCHEMA env or 'public', which is not in the schema definition, and clarifies the default for 'type'.

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 'List all tables and/or views in a schema', specifying a specific verb and resource. It distinguishes itself from sibling tools like kb_list_schemas (schemas) and kb_describe_table (single table details).

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 explains what it does and its parameters but does not explicitly tell when to use this over alternatives like kb_describe_table or kb_list_schemas. Usage is implied but not guided.

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, destructiveHint=false, but the description adds value by explaining the return format (formatted table with row count) and the auto-schema feature. No contradictions.

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?

Well-structured with paragraphs, bullet-like arg list, and examples. Slight redundancy ('Only read-only statements are allowed' appears in both description and schema), but overall efficient 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?

With rich annotations and full schema coverage, the description is complete. It explains return format, safety, and auto-schema. No output schema, but mentions return is a formatted table with row count, which suffices.

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% with descriptions for each parameter. The description adds extra context: for sql, it clarifies read-only constraint; for params, explains $1, $2 substitution; for schema, details auto-qualification and default from env var. Adds significant meaning beyond 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 states the tool executes read-only SQL queries (SELECT/WITH/SHOW) against the KingBase database, with a specific verb and resource. It distinguishes from siblings by noting DML and DDL are handled by other 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?

Explicitly states when to use (read-only queries) and when not ('For INSERT/UPDATE/DELETE use kb_execute; for DDL use kb_execute_ddl'). Also advises using parameterized queries for safety.

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 convey read-only, non-destructive, and idempotent behavior. The description adds that it returns a formatted table with total count, enhancing transparency. It does not disclose performance limitations, but given the annotations, the additional context is sufficient.

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 concise and well-structured, front-loading the purpose and then detailing parameters and examples. It contains no wasted words, though the examples could be slightly trimmed without losing clarity.

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

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

Given no output schema, the description explains the return format (formatted table with total count). It covers all parameters and examples, fitting well with sibling tools. Minor gaps like performance caveats prevent a perfect score.

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 100% schema coverage, the baseline is 3. The description adds value through an Args block with defaults and concrete examples (e.g., table: 'users', where: "status = 'active'"), clarifying usage beyond the schema's descriptions.

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

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

The description clearly states the tool previews table data with filtering and pagination, using a specific verb and resource. It distinguishes from sibling tools like kb_query, which require full SQL, by positioning itself as a shortcut for common SELECT operations.

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

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

The description implies usage for quick previews without writing SQL, providing clear context. However, it lacks explicit when-not-to-use or direct alternatives like kb_query for complex queries, though sibling context partially compensates.

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, destructiveHint=false, covering safety. Description adds specifics of returned statistics but no extra behavioral traits beyond output details. Moderate value given annotation coverage.

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?

Description is concise, with clear purpose statement and separate args/returns sections. However, the args section partially duplicates schema descriptions, slightly reducing efficiency.

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?

No output schema, but description lists return fields. For a simple read-only stats tool, it's complete enough. Could mention prerequisites (e.g., table must exist) but not critical.

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%, with both parameters having descriptions. The description's 'Args' section largely mirrors the schema, adding no new semantics beyond formatting. 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 clearly states the tool retrieves storage and usage statistics for a table, listing specific metrics (row count, size, dead tuples). This distinguishes it from sibling tools like kb_describe_table (structure) and kb_list_tables (list of 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?

No explicit guidance on when to use this tool vs alternatives like kb_describe_table or kb_list_indexes. The description implies use when needing table stats, but lacks context for selection.

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