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 meaningful behavioral scope by identifying the specific anomaly categories being tested, which is useful context beyond the annotations. No contradiction exists.

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 dense sentence with no filler or repetition. It front-loads the core action and immediately lists the anomaly types, making efficient use of the space.

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 anomaly-detection tool with annotations covering safety, the description is mostly adequate. But with no output schema, it does not state what the tool returns (e.g., a list of flagged anomalies or counts), and it omits the role of report_id. These are notable but not severe 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 0%, so the description must compensate. It does map 'ACOS threshold' and 'CTR threshold' to max_acos and min_ctr, adding meaning beyond the bare schema. However, the required report_id parameter is not explained, and default threshold behavior is left entirely to schema defaults.

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 verb ('检查' / check) and the specific resource (ad anomalies), and enumerates concrete anomaly types: burning money with no revenue, high ACOS, low CTR, and clicks without orders. This differentiates it from sibling tools like inventory_risk_detect or product_metrics_get.

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: use this when you need to detect ad anomalies against ACOS and CTR thresholds. However, there is no explicit guidance about when not to use it, nor does it contrast with alternatives such as product_metrics_get or inventory_risk_detect.

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?

注释已声明 readOnlyHint=true、idempotentHint=true、destructiveHint=false，描述本身未包含额外行为信息，但也没有矛盾。描述添加了具体计算字段的上下文，符合注释下应有水平。

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?

描述简洁明确，一句话涵盖所有核心要点，无冗余内容，易于快速理解。

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?

对于单参数工具且无输出 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?

参数 report_id 在 schema 中仅有类型和长度约束，无描述。Schema 描述覆盖率为 0%，描述中未提及 report_id 的含义或格式，对单个参数缺乏任何语义补充，因此评分低。

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?

描述明确说明该工具计算达人视频数、花费、收入、订单、ROAS 和单均成本，动词'计算'搭配资源'达人效果'，清晰表达了核心功能。但未与兄弟工具（如 product_metrics_get、order_summary_get）进行区分，存在混淆风险。

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?

描述隐含了用于获取达人效果汇总数据的场景，但未明确说明何时使用此工具而非其他指标工具，如 product_metrics_get 或 order_summary_get。没有提供排除条件或替代工具指引。

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 idempotentHint=true, so the agent knows it is a safe read operation. The description adds the aggregation scope (categories, counts, times, CSAT), which is useful context, but it does not disclose output format, pagination, or any caveats such as date ranges or report_id interpretation.

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, tight sentence that front-loads the core action and lists the key output fields without filler. Every word contributes to the tool's meaning.

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?

Despite low complexity and supportive annotations, the description omits the meaning of report_id, provides no output details, and gives no usage context. An agent would struggle to invoke this tool correctly when preparing the required input.

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 sole parameter report_id has no schema description (0% coverage), and the tool description does not mention report_id at all. With no compensating explanation anywhere, the agent cannot determine what value to supply for this required parameter.

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

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

The description clearly states a specific action ('汇总' = summarize) applied to a distinct resource (customer service issues) and lists the exact metrics included (categories, unresolved count, first response, resolution duration, CSAT). This is distinguishable from siblings like report_import or report_list, though it does not explicitly name alternatives.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, contexts, or exclusions, leaving the agent to infer usage solely from the name and summary.

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 signal read-only, idempotent, and non-destructive behavior. The description adds meaningful behavior beyond that: it reads the latest imported reports and, importantly, returns null for missing data types, which is an edge case an agent needs to know. 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?

One compact sentence with a clear front-loaded action, a list of generated report categories, and an edge-case behavior at the end. Every phrase carries information and there is 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 one-parameter, read-only, annotated tool, the description covers what it reads, what it generates, and its null behavior. With no output schema, an agent still lacks a precise sketch of the returned brief structure, but the tool's name and category list make the expected result reasonably predictable.

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 documents only a required project_id string with length bounds and has no per-parameter descriptions. The description mentions '项目' as the target of the operation, adding slight context, but it does not explain the project identifier's meaning, format, or source; with one self-explanatory parameter this is acceptable but not rich.

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 opens with a clear action (读取...报表) and states what it produces (订单、库存、广告和客服简报), so an agent can recognize it as a cross-domain daily briefing tool. However, it never names or contrasts sibling tools like order_summary_get or customer_service_issue_summary, so differentiation rests on inferring aggregation from the four categories.

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 wording implies this is the tool to request when a multi-area daily brief over order, inventory, advertising, and customer service data is needed. It does not explicitly say when to prefer a sibling tool, nor give exclusion criteria, so usage guidance is only implied.

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 covered. The description adds the fact that it produces an evidence structure for evidence_add, which clarifies the output's purpose but does not disclose any other behavioral traits like side effects, validation rules, or error conditions. Given annotations, this is adequate but not enriched.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that front-loads the core purpose. It avoids fluff and is easily parsed. However, it may be too terse given the complexity, but as a structural evaluation, it is efficient.

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 has five required parameters, a nested object, no output schema, and zero schema coverage in the description. The description provides no guidance on how to construct the evidence structure, what each parameter represents, or any constraints or examples. This is completely inadequate for an agent to call it 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 0%, meaning the description must explain the parameters, but it does not. It only mentions 'analysis result' generically without clarifying what project_id, analysis_type, summary, analysis, or source_report_ids mean, or how they map to the evidence structure. This is a critical gap for a tool with five required parameters, including a nested object.

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 ('wrap') and resource ('analysis result' into an 'evidence structure'), and names the downstream consumer (orange_island_core evidence_add). This clearly differentiates it from sibling analysis/report tools, which are about generating or retrieving data rather than packaging it for another system.

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 a post-processing role (wrapping an analysis result for a specific target), but does not explicitly state when to use this tool versus alternatives, nor any exclusions. The mention of evidence_add gives context, but an agent is left to infer that this is the final step before handoff.

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, so the safety profile is covered. However, the description adds no behavioral context such as data prerequisites, error conditions, or response formatting, which would be useful given the absence of an output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, self-contained sentence that is front-loaded with the core function and avoids redundant or filler content. Every word earns its place.

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

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

With no output schema, the description should clarify what the call returns and how target_cover_days is used. It only says 'calculates coverage days and replenishment risk,' which is too high-level to fully guide correct invocation, and it doesn't mention whether the report must exist or how errors surface.

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

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

The input schema has no property descriptions (0% coverage), so the description carries the full burden. It mentions data sources (inventory, daily sales, in-transit, lead time) but never maps them to the parameters report_id or target_cover_days, leaving the agent to guess what report_id refers to and how target_cover_days influences the risk score.

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 (calculate), resource (inventory risk from stock/sales/in-transit/lead time), and the outputs (coverage days and replenishment risk). This distinguishes it from siblings such as profit_calculate or ad_anomaly_detect, which target different metrics.

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 guidance on when to use this tool versus alternatives. It neither names alternative tools nor states conditions or prerequisites, leaving the agent to infer usage solely from the tool name.

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 covered. The description adds the detail that it checks specific listing fields and explicitly reinforces non-mutation ('不写回平台'). This adds some context beyond annotations but does not disclose output format or failure behaviors.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that conveys the core purpose and the non-mutation guarantee with no filler. It is extremely concise and easy to parse.

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 one parameter, no output schema, and annotations covering safety, the description still fails to explain what report_id is or what the tool returns. An agent cannot know how to obtain a valid report_id or interpret the audit results. The description is insufficient for correct invocation.

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

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

The schema has zero description coverage for the sole parameter report_id, and the description provides no explanation of what report_id represents, how it is obtained, or its format. The description is entirely unhelpful for understanding this parameter, leaving the agent to guess.

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

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

The description states a clear verb (检查/check) and resource (listing issues), and enumerates specific aspects (title, image, description, price, status). It explicitly says it does not write back to the platform, which further clarifies its scope. While it doesn't explicitly contrast with sibling tools, the purpose is 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?

There is no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, typical scenarios, or which sibling tools to prefer for different needs. The description only states what it does, not when to invoke it.

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 annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the aggregation scope but does not disclose additional behavioral traits such as dependencies on imported reports, return format, or limitations beyond the metric list.

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 that front-loads the verb '汇总' and quickly lists all covered metrics without filler. It is appropriately concise, though the brevity sacrifices parameter and usage detail.

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 one required parameter and no output schema, the description does not explain what report_id refers to or what the summary output looks like beyond the metric names. Annotations cover the read-only/idempotent nature but not invocation context, leaving the agent under-informed.

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

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

Schema description coverage is 0% and the description never mentions report_id or explains how to obtain or format it. Because coverage is low, the description was expected to compensate with parameter guidance, but it provides none.

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, '汇总' (summarize), and clearly identifies the resource as order business metrics, enumerating orders, sales, revenue, refunds, average order value, and country distribution. It is unambiguous about the tool's purpose, though it does not explicitly differentiate it from sibling tools like report_list or product_metrics_get.

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

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

No guidance is provided on when to use this tool versus alternatives; there are no exclusions, prerequisites, or references to sibling tools. The metric list implies it is for order-level summaries, but the agent must infer the appropriate selection context on its own.

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?

注释已声明readOnlyHint、idempotentHint和destructiveHint，描述未额外披露行为信息，但也没有矛盾。对于只读操作，描述没有增加实质性上下文，因此评分适中。

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?

单句描述，信息集中，没有冗余。简洁且直接列出了关键指标。

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?

只有一个参数，描述列出了汇总的指标，但没有说明返回格式或使用场景。对于简单工具，描述足够使用，但缺乏使用时机指导，完整性一般。

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?

描述未解释report_id的确切含义（是SKU还是报表ID），且schema描述覆盖率为0%，参数语义完全依赖描述，但描述未提供足够说明。

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?

描述明确说明按SKU汇总多个商品指标（曝光、点击、订单等），动词“汇总”和资源“商品指标”具体。但它没有明确与其他兄弟工具（如creator_performance_get）区分，因此不是满分。

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?

没有说明何时使用此工具或何时不使用，也没有提及替代工具。尽管存在多个相关兄弟工具，描述未提供任何路由指导。

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?

注解已提供readOnlyHint和idempotentHint等安全特性，描述补充了'缺字段会明确提示'的行为信息，增加了价值。但未详细说明计算规则或边界情况，且与注解无矛盾。

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?

描述为一句紧凑的句子，直接说明核心操作并附有错误处理说明，无冗余内容，但稍微长了一点，可以更精简。

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?

无输出模式，描述未说明返回值或输出格式。对于简单计算工具，应至少提及结果形式，但描述仅说会提示缺字段，不够完整。

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?

模式覆盖率为0%，描述完全未提及report_id参数的含义或用法。描述只提及'报表'，但未说明该参数如何标识报表，未补偿模式中的缺失。

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?

描述明确说明了计算贡献利润的动作，并列出具体数据来源（收入、成本、物流、平台费、广告费、退款），区别于其他获取指标的工具。但未明确提及与兄弟工具的差异，例如与product_metrics_get的区别，因此未达到满分。

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?

描述仅隐含地表明用于利润计算，未提供显式的使用时机或排除条件，也未提及替代工具。缺少'当使用此工具时'或'在何种情况下不使用'的指导。

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 that this is a non-read-only, non-idempotent write, so the description only needs to add context beyond them. It does add one meaningful behavioral guarantee — 不会连接或写入外部平台, meaning the side effects are purely local. However, it says nothing about re-import behavior, validation, or failure modes, so disclosure beyond the annotations is minimal; there is no contradiction with 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?

Two short sentences with zero filler: the primary action is front-loaded and the scoping statement about not touching external platforms follows directly. No schema contents are restated and every sentence earns its place.

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

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

For a tool with 7 parameters, 4 required, and no schema descriptions or output schema, two sentences are insufficient. The description omits what 'standardized' means, the expected shape of rows, how the period/currency fields behave, and what occurs after a successful save, leaving a non-idempotent write operation under-specified for an agent.

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

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

Schema description coverage is 0%, so the description carries the full burden of explaining the 7 parameters, and it does not. The phrase 标准化 JSON 报表 offers only a weak hint that rows holds the JSON payload, but none of project_id, platform, report_type, currency, period_start, or period_end is given any meaning beyond the bare schema fields. This fails to compensate for the absent 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 states a specific verb (保存/save), a resource (seller-authorized standardized JSON report), and the destination (本地/local), so the agent knows exactly what the tool does. The follow-up 不会连接或写入外部平台 clarifies that it is local-only and differentiates it from any external-sync behavior. It stops short of the top tier because it never explicitly contrasts with a sibling tool such as evidence_export or report_list.

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 use case is implied: invoke when a seller-authorized standardized JSON report needs to be persisted locally, as indicated by 把卖家授权的标准化 JSON 报表保存到本地. No explicit when-not-to-use conditions, prerequisites, or alternatives are named, so an agent must infer the selection criteria from the verb and context alone.

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), lowering the bar for the description. The description does add one useful nuance—that only metadata is returned, not report contents—but it says nothing about pagination, limits, or response shape beyond that.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single clean sentence with zero wasted words, front-loading the action (列出/list) before the resource. Nothing extraneous is included, and the length is appropriate for the tool's simplicity.

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

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

For a simple read-only list tool, the combination of structured data and description covers what an agent needs to invoke it correctly: the schema defines the required project_id, limit constraints, and report_type enum; annotations define the safety profile; the description defines the purpose. The only real gap is usage routing guidance, which is not strictly required for a correct call.

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

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

Schema description coverage is 0%, so the description must compensate for documenting parameters, but it does not mention project_id, limit, or report_type at all. The parameter names and report_type enum are self-evident, yet the description fully fails to compensate for the undocumented schema, leaving the filtering semantics and limit behavior entirely implicit.

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), a specific resource (报表元数据/report metadata), and a clear scope (项目/project). It also notes the metadata-only nature of the result, which distinguishes it from report_import (importing vs. listing) and from the metric/summary siblings like product_metrics_get and order_summary_get.

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

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

No guidance is given on when to use this tool versus its siblings. It never mentions report_import as the complementary operation, nor does it state any conditions, exclusions, or prerequisites for choosing report_list over the other report-related tools.

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