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

Annotations already cover read-only, non-destructive, idempotent behavior. The description adds useful scoping (current user related, reviewer perspective) and pagination, but does not disclose additional behaviors such as default status filtering or response format implications. No contradiction with 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 concise sentences: the first states the purpose with scope and perspective, the second provides the API reference. No wasted words, front-loaded with the core function.

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 rich annotations and output schema, the description is largely complete: it specifies the resource, scoping, and API. However, it could explicitly mention the status filter options or contrast with 'yearning_my_orders' to aid selection, though this is 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 description coverage is 50%, with text, status, and work_id documented in the schema. The description does not elaborate on any parameters, only implying pagination through '分页' and giving the API endpoint. It does not compensate for the undocumented page, page_size, or response_format 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?

The description clearly states it lists pending/reviewed orders for the current user as a reviewer, with a specific API endpoint. It distinguishes from sibling tools like 'yearning_my_orders' by the '审核人视角' (reviewer perspective) scope.

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 context (reviewer perspective) but does not explicitly state when to use it vs. alternatives like 'yearning_my_orders' or mention any exclusion criteria. The context is provided through the phrase '审核人视角' but no direct comparison is made.

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 destructiveHint=false, so the safety profile is covered. The description adds only the API endpoint, which is not a behavioral trait, and does not reveal any additional context such as filtering, pagination, or output details.

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 consists of two brief sentences that front-load the purpose and provide the API mapping. It 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 simple read-only listing tool, the description combined with annotations and schema is sufficient to select and invoke it. The output schema exists, and although the description does not mention the 'hide' option, the schema describes it, so the overall package is fairly 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?

The description does not explain any parameters; the schema covers two of three parameters with descriptions, but the response_format parameter lacks definition. The tool description provides no additional meaning 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 lists databases under a specified data source using the verb '列出' and the resource '数据库（库）'. This distinguishes it from sibling tools like list_sources and list_tables.

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

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

The description implies usage when one needs to list databases for a given data source, but it does not explicitly contrast with alternatives or state when not to use it. The user must infer the context from the tool's name and 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, idempotentHint, and destructiveHint. The description adds the scope of current account permissions and the underlying API endpoint, which is useful context. However, it does not disclose additional behavioral traits like pagination or error handling.

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 short sentences, front-loaded with the main purpose and a useful API reference. Every sentence earns its place with 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?

The tool is simple, with an output schema and annotations covering safety. The description adequately covers the operation and scope; it doesn't need to explain return values given the output schema. Minor omission: doesn't mention all filter values (all/idc) but those are in the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already describes the 'tp' parameter with enum values and default. The description restates the filter dimensions but adds no new meaning for 'response_format', which lacks a description. With 50% schema coverage, the description does not adequately compensate for the undocumented 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?

Description clearly states the tool lists data sources accessible to the current account, with optional filtering by query/dml/ddl dimensions. The verb 'list' and resource 'data sources' are specific, and it distinguishes itself from sibling tools like list_databases and list_tables.

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

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

Provides clear context: lists data sources the current account has permission to, and mentions the filter dimension. Does not explicitly exclude alternatives or name when not to use, but the purpose is clear enough 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 already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds only the API endpoint (GET /api/v2/fetch/table), which provides minor context but no extra behavioral detail beyond what annotations indicate. This is adequate but not rich.

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: two short sentences. The main purpose is front-loaded, and the API reference is a useful addition. 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?

Given the tool's simplicity, strong annotations (readOnly, idempotent, non-destructive), and the presence of an output schema, the description is largely complete. It could mention potential pagination or output format details, but these are not essential for a list operation and the output schema likely covers 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 description mentions 'specified data source, specified database' which maps to source_id and database, but this largely repeats the schema descriptions ('数据源 ID', '库名'). The response_format parameter is not mentioned. Schema coverage is 67%, and the description adds minimal extra meaning 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's function: '列出指定数据源、指定库下的数据表列表' (list tables under a specified data source and database). This specific verb+resource+scope distinguishes it from siblings like yearning_list_databases (which lists databases) and yearning_table_fields (which gets fields of a table).

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 vs alternatives or mention exclusions. However, the purpose is clear enough that an agent can infer it should be used when needing a table list for a given source and database. No explicit 'when not to use' guidance is provided, so it relies on implication.

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, and destructiveHint=false, covering the safety profile. The description adds the API endpoint and filter capabilities, but does not disclose additional behavioral traits like pagination behavior or return format. It does not contradict 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?

The description is extremely concise: two short sentences that clearly state the purpose and supported filters, plus the API reference. Every word earns its place, with no 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?

Given the tool's moderate complexity, annotations, and output schema, the description is mostly complete. It covers the core purpose, filters, pagination, and API. The only minor gap is that it does not explicitly mention response format or default sort order, but these are not critical given the output schema exists.

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 high (83%), so the schema already documents most parameters. The description adds semantic grouping by mentioning status/keyword/work_id filtering, which aligns with the schema but does not provide new details beyond what the parameter descriptions already contain. It does not compensate for the few undocumented 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?

The description clearly states the tool lists work orders submitted by the current user, with a specific verb '列出' and resource '当前用户提交的工单'. It also mentions supported filters (status/keyword/work_id), which distinguishes it from sibling tools like order_detail or audit_orders.

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 viewing the current user's own submitted orders, which is a clear context. However, it does not explicitly name alternative tools or state when not to use this tool, so it falls short of a 5 but is still 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 declare readOnlyHint, idempotentHint, and non-destructive behavior, covering the safety profile. The description adds the scope ('全部评论') and API endpoint, but does not disclose ordering, pagination, or other behaviors. This is adequate but not rich.

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 two concise sentences, front-loaded with the primary purpose and an API reference. Every sentence earns its place with no redundancy 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?

The tool is simple, and annotations plus output schema handle some context. However, the description lacks usage guidelines and response_format semantics, which is noticeable given the tool's context among 14 siblings. It is adequate but not 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 50%; work_id is described in the schema ('工单号'), but response_format is undocumented in both schema and description. The description text adds no parameter semantics, failing to compensate for the low 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 clearly states the tool reads all comments for a specified work order, using a specific verb ('读取') and resource ('指定工单的全部评论'). It also references the exact API. However, it does not explicitly differentiate from sibling tools like yearning_order_detail or yearning_order_timeline, 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 guidance on when to use this tool versus alternatives. The description offers only the core function and API reference, with no mention of prerequisites, scenarios, or exclusions. Given the large sibling set, this is a significant gap.

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, and destructiveHint=false, covering the safety profile. The description adds behavioral context by specifying that it retrieves paginated SQL details, complete SQL statements, and execution result records, and that it corresponds to two GET endpoints. This goes beyond what annotations provide, though it does not disclose rate limits or merge logic.

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 two concise sentences, front-loaded with the primary purpose. Every clause provides relevant information, and there is no redundant or filler content. It is efficient and well-structured.

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 a read-only detail query with an output schema provided, so the description does not need to explain return values in depth. It covers the main content returned and the pagination behavior, which is sufficient for basic invocation. It could optionally mention the response_format parameter, but the schema already defines its default and enum.

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 25% (only work_id has a description). The description mentions pagination, which gives meaning to page and page_size, but it does not explain the response_format parameter or how it affects the output. Since coverage is low, the description partially compensates but leaves gaps for some 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?

The description starts with '查看工单详情' (view work order details) and enumerates the specific content: SQL details (paginated), full SQL statements, and execution result records. This is a specific verb+resource combination that clearly distinguishes it from sibling tools like 'yearning_my_orders' (list orders) and 'yearning_order_timeline' (view timeline). It also maps to two concrete API endpoints, making the purpose unmistakable.

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 when to use the tool: when you need detailed SQL and execution results for a specific work order. However, it does not explicitly mention alternatives or say when not to use it. The context is clear enough for an agent to infer the primary use case, but there is no direct comparison to 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, idempotentHint=true, and destructiveHint=false. The description adds behavioral context by specifying the underlying API endpoints (GET) and the content included (reviewer actions, current step), which 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?

The description is two sentences, front-loaded with the main purpose and followed by the API reference. No unnecessary words 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?

For a read-only timeline tool with strong annotations and an output schema, the description covers the core behavior and API mapping. It lacks usage scenarios or prerequisites, but these are not critical given the simple read-only nature.

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%, with work_id and source_id having Chinese descriptions. The description does not add parameter-level details beyond what the schema provides, but the schema already covers the key parameters, so a 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 clearly states it views the work order audit timeline and process steps, including each reviewer's actions and current step. This specific verb+resource combination distinguishes it from sibling tools like order detail, query status, etc.

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 the tool is for viewing timelines and steps, but does not explicitly say when to use it versus alternatives or provide exclusion criteria. It is reasonably clear but lacks direct guidance on tool 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds behavior beyond annotations: it reveals that the tool invokes two separate GET endpoints (is_query and query_status), implying combined functionality. It also specifies that it operates on the current user's data, which is not indicated in annotations. No contradictions found.

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 exceptionally concise: two sentences, with the first stating purpose and the second listing API endpoints. Every word is purposeful, no redundancy or filler. It is front-loaded with the key information and easy to scan.

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, strong annotations, and presence of an output schema, the description provides adequate context: it names the two checks and corresponding APIs. It does not explain return values, but that is covered by the output schema. It could benefit from a usage note (e.g., 'use before running a query'), but that is covered under usage guidelines. Overall, it is reasonably complete for its scope.

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 0% for the single optional parameter response_format, and the description does not mention this parameter at all. Since coverage is low, the description should compensate by explaining the parameter or its behavior, but it fails to do so. The enum values (markdown/json) are self-explanatory, but the lack of any description or context leaves the agent without guidance on when to choose each format.

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 checks whether the query audit switch is enabled and the current user's query order status, which is a specific verb+resource+scope. It clearly distinguishes from sibling tools like yearning_my_orders (lists orders) and yearning_run_query (runs queries). The mention of specific API endpoints further solidifies its unique purpose.

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 no explicit guidance on when to use this tool versus alternatives. It does not mention that it should be used before running queries, nor does it reference sibling tools for different scenarios. Usage is only implied by the tool's function, lacking clear 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, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context—that the SQL is generated before execution—but does not disclose additional traits such as whether rollback SQL may be unavailable or any permission requirements. The description does not contradict 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?

The description is only two sentences, front-loading the primary purpose and immediately providing the corresponding API. Every sentence earns its place, with no redundant 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 retrieval tool with rich annotations and an output schema, the description is largely complete. It covers purpose, generation timing, and API mapping. Minor gaps exist, such as not mentioning potential absence of rollback SQL, but overall it is sufficient for an AI agent to invoke 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?

The schema already describes work_id as '工单号' and response_format with enum/default values. The description does not add parameter-level details beyond echoing the work order concept. At 50% schema coverage, the description is not required to fully compensate, but it also adds minimal parameter semantics.

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's function: retrieving rollback SQL for a work order (获取工单的回滚 SQL). It uses a specific verb and resource, and the context '用于误操作回退' distinguishes it from sibling tools like run_query or sql_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 provides clear context on when to use the tool: to fetch rollback SQL that was generated by the system before execution, for reverting accidental operations. It does not explicitly name alternatives or exclusions, but the use case is sufficiently 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?

Beyond annotations (readOnlyHint=true, destructiveHint=false), the description adds significant behavioral context: it only executes SELECT with no data modification, but it retains audit records and may cause resource overhead like full-table scans and lock contention, making it a 'submit operation' rather than a purely passive read. This enriches the annotation info without contradicting 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 main purpose is stated in a single, focused sentence. The additional note and API reference are structured and useful, though the API endpoint detail is slightly beyond core usage guidance. Overall, it is concise and well-organized.

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 description covers purpose, constraints, permissions, and side effects. The output schema handles return format details, so missing return value descriptions are not a gap. It could be slightly more complete by mentioning error scenarios, but it is adequate for a query 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 description coverage is 80%, so parameters are already well-documented. The description reinforces that SQL is read-only, but does not add new parameter-level details beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states it executes a read-only SELECT query and returns a result table. It uses specific verb+resource (execute query on specified data source) and distinguishes from sibling tools like sql_check and audit_orders, 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 description provides clear context: it requires query permissions and must pass query review, and it explicitly notes this is a 'submit operation' with audit and resource overhead. It does not explicitly list alternative tools, but it gives enough context for an agent to understand when this tool is applicable.

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, so the safety profile is clear. The description adds behavioral context by detailing return values (check results with level/affected rows/errors/execution time) and the API endpoint (PUT /api/v2/fetch/test), which goes beyond the structured annotations. No contradictions with annotations exist.

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 two sentences: first sentence states purpose and output, second provides usage recommendation and API. It is front-loaded, concise, and every sentence contributes useful information. No waste 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?

Given the tool's moderate complexity, the description covers purpose, usage, output characteristics, and API endpoint. An output schema exists, so return details needn't be fully explained. The description is sufficient for an agent to select and invoke this tool correctly, though it could optionally mention any limitations or prerequisites.

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 80% with descriptions for sql, database, source_id, and order_type. The description does not add parameter-specific semantics beyond that; it only mentions "逐条检查结果" (per-item results), which relates to output, not parameters. With high schema coverage, baseline 3 is appropriate.

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

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

The description clearly states the tool performs a pre-submission SQL audit check ("提交前对 SQL 做审核检测") and specifies the output includes per-item results (level/affected rows/errors/execution time). This distinguishes it from sibling tools like yearning_run_query, which likely executes queries rather than validating them. The reference to yearning_submit_order further clarifies its role in the workflow.

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 explicitly recommends calling this tool before yearning_submit_order ("建议先调用本工具确认无误，再调用 yearning_submit_order 提交工单"), providing clear when-to-use guidance. It lacks explicit when-not-to-use or alternative tool mentions, but the workflow context is strong enough for an agent to infer 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 declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, providing the safety profile. The description adds value by specifying the exact return content (field attributes and index info) and the underlying API endpoint, which 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?

The description is two concise sentences, front-loaded with the core purpose, and includes a useful API reference without any wasted words. It is well-structured for quick scanning.

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 introspection tool, the description covers the main functionality and return value. It lacks explicit error scenarios, authorization requirements, or interaction with other tools, but these are not critical given the annotations and schema. The presence of an output schema (response_format) further reduces the need to detail return formats.

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 75% (3 of 4 parameters described), so the schema already handles most parameter semantics. The tool description does not add any extra meaning to the parameters, such as how to find or format source_id, database, or table. Thus 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 clearly states the tool's purpose: viewing table structure, specifically field lists with type, nullable, key, default, comment, and index information. This distinguishes it from sibling tools like yearning_list_tables, which list tables rather than their fields.

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 context is implied by the description (inspect table schema when needed), but there is no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The context signals and sibling names suggest differentiation, but the description itself does not spell it out.

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, and destructiveHint=false, so the safety profile is established. The description adds value by specifying the exact payload (user info, department, email, authorized data sources) and the underlying API endpoint, without contradicting 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?

The description consists of two short sentences that front-load the purpose and end with the API endpoint. Every word earns its place, with no redundancy.

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

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

This is a simple read-only lookup with strong annotations and an output schema; the description covers what is returned and the endpoint. Given the low complexity and available structured metadata, the description is complete enough for the AI agent to select and invoke 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?

The single parameter response_format is not mentioned in the description, and schema description coverage is 0%. The schema's enum values (markdown/json) and default provide some semantic clarity, but the description adds no parameter-level guidance and fails to compensate for the missing parameter 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 uses the specific verb '查看' (view) and names exact resources: current logged-in user's information, department, email, and authorized data source list. This clearly differentiates it from sibling tools that list databases, tables, orders, or run queries.

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 is provided, but the description clearly implies the natural use case of retrieving one's own user profile and permissions. It does not mention alternatives or exclusions, so it is minimally viable.

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