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

No annotations are provided, so the description must carry the burden. It discloses the main side effect (saving a template file) and the fact it drives a browser, but does not mention whether it overwrites existing templates, requires specific permissions, or has any rate-limit implications. For a debugging tool, this is acceptable but not fully transparent about file modifications.

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 is front-loaded with '调试用' (for debugging), then states the action and the automatic alternative. Every word earns its place; no fluff or redundancy.

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

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

For a niche debugging tool with one parameter fully documented in the schema and no output schema, the description provides the essential context: purpose, the fact that it's rarely needed, and the relation to pdd_reviews_list. It doesn't detail the exact browser interaction, but that is not necessary for an agent to decide whether to invoke it.

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 description for the single 'shop' parameter is 100% covered, explaining the shop name mapping to config/shops.json and the default behavior when omitted. The description adds no extra parameter information beyond the schema, so the baseline of 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's purpose: it drives the browser to open evaluation management pages, captures the /saturn/reviews/list request body, and saves it as a template. It also notes that pdd_reviews_list does this automatically on first use, distinguishing it as a debugging fallback. This is specific and avoids confusion with sibling 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?

It explicitly says '一般无需手动调' (generally no need to call manually) and mentions that pdd_reviews_list performs the action automatically, which tells the agent when not to use it. However, it doesn't explicitly state the condition for manual use (e.g., debugging failures) or list alternatives beyond pdd_reviews_list. Still, the guidance is clear enough.

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

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

No annotations are present, so the description carries the full burden of behavioral disclosure. It usefully discloses that the result is pure data JSON and that time-span limits match the backend, but it does not describe the JSON structure, auth/error behavior, or rate-limit considerations. For a 10-parameter tool with no output schema, these are notable gaps.

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 dense sentences: the first front-loads the core query scope, modes, and JSON output type, and the second gives a single explicit routing instruction to the export skill. There is no filler or redundancy.

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

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

Despite no output schema and no annotations, the description covers the essential decision points: what is queried, in which modes, in what format, under what time limits, and where to go for Excel export. The remaining return-structure detail is largely inferable from the rich parameter schema (previewLimit, maxConversations, mode-specific required fields), so the definition is complete enough 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?

Schema description coverage is 100%, so the baseline is 3. The description adds a cross-parameter validity constraint (31/7-day limits) that sharpens the meaning of startDate and endDate, but it does not need to restate per-parameter details already present in 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 names a precise action and resource ('查询聊天记录' = query chat records) and enumerates three query dimensions: customer-service account, order number, and product ID. It also marks the output as pure JSON, which distinguishes it from the Excel-export skill and from sibling tools such as pdd_chat_users or pdd_reviews_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 description explicitly routes Excel-export needs to the pdd-chat-export skill, making the alternative and the condition for choosing it explicit. It also encodes backend validity windows (≤31 days for customer-service/order queries, ≤7 days for product queries), so an agent can reject invalid date ranges before invoking the tool.

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

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

With no annotations, the description carries the burden of behavioral disclosure. '列出' implies a safe read operation, and the description reveals what the result contains ('mmsId + 名称'). It does not explicitly state read-only behavior, permission requirements, or absence of side effects, leaving some behavior implicit.

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 short sentence contains the action, resource, output fields, and the intended companion tool. There is no filler or repetition of what is already in the schema.

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 single-optional-parameter list tool, the description is nearly complete: it names the return fields and explains how to use the result. It does not spell out the exact output shape, but the tool is simple and the schema covers the only parameter.

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%, so the optional shop parameter is already documented with its default behavior. The description adds no parameter-specific detail beyond restating the shop context, so the baseline 3 applies.

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

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

The description uses a specific verb ('列出' / list) and exact resource ('店铺的客服账号'), and specifies the output fields ('mmsId + 名称'). This clearly distinguishes it from data-focused siblings like pdd_chat_data, which concern chat content rather than account metadata.

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

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

It gives an explicit use case: obtain mmsId values for use as the mmsId parameter of pdd_chat_export. It does not state exclusions or conditions when an alternative would be preferred, so it lacks the full when/when-not structure.

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

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

With no annotations, the description carries the behavioral burden. It discloses that this is a pure JSON fetch, enumerates the data included, and warns about slowness when the flag is enabled. It does not mention rate limits or errors, but for a read-only data pull the key behaviors are covered.

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 one dense sentence that front-loads the core purpose, then gives the response contents, the flag behavior, and the alternative skill. There is no filler and each clause 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 two fully documented optional parameters and no output schema, the description conveys what the response contains (categorized metrics, promotion data, shop-level data) and the performance implication of the flag. Missing details like exact JSON keys or error behavior are minor for this simple fetch 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 100%, so the schema already explains both parameters. The description repeats the withYesterdayFullDay trade-off but does not add substantial new meaning beyond what the schema provides.

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 specific verb and resource ('拉取商品维度数据') and enumerates exactly what is included: all products, yesterday full-day metrics, today real-time metrics, activity recommendations, promotion data, and shop-level real-time data. This clearly separates it from sibling tools like an overview or a single-goods detail tool.

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

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

It explicitly states a when-not and alternative for Excel reports ('如需 Excel 报表，用 pdd-daily-report skill') and explains the trade-off of enabling withYesterdayFullDay=true (more accurate but slower). It does not exhaustively compare against all sibling data tools, but the context is 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?

With no annotations, the description carries the behavioral burden. It discloses the tool's data coverage ('全部明文接口', metric categories) and implicitly suggests a read-only analytics operation, but it does not explicitly state that it makes no changes, mention rate limits/errors, or describe output shape. The transparency is adequate but not thorough.

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 entire description is one dense sentence that front-loads the purpose before a compact list of delivered data. Every phrase (metric categories, goodsId source, plaintext-interface note) adds information, with no filler.

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

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

Despite lacking an output schema, the description enumerates the major return categories and the key prerequisite (goodsId from pdd_goods_data). It is sufficient for an agent to select and invoke the tool, though field-level details and interpretation of the scores are left unspecified.

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

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

Schema coverage is 100% and both parameters are described in the schema. The description adds meaningful semantics for goodsId by tying it to pdd_goods_data output, which helps the agent know where the value comes from. Shop is not mentioned in the description but is already documented in 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 opens with '单品深度分析' (single-item deep analysis), giving a specific action and resource, and enumerates concrete data categories (today/yesterday metrics, time-phased sales trend, after-sales quality, navigator/health scores, review overview). It stops short of naming siblings or stating what it is not, so it is clearly scoped but not explicitly differentiated from pdd_goods_data/pdd_goods_navigator.

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

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

It gives a concrete workflow hint: 'goodsId 从 pdd_goods_data 的结果里拿', telling the agent to first retrieve goodsId from pdd_goods_data before calling this tool. This is clear contextual guidance, though it does not state exclusions or when to prefer an alternative.

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

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

With no annotations provided, the description carries the full burden, and it does disclose the primary behavior: returning a list with specified performance metrics. However, it does not mention operational aspects such as sorting order, pagination behavior, whether the data is live or cached, or any side-effect-free read guarantee. The '列表' wording implies a read operation, but the description could be more explicit for a tool with no 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?

The description is a single, information-dense sentence with a colon introducing the metric list and a clear purpose clause at the end. There is no filler, and every segment—scope, output metrics, and intended use—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?

Given no output schema and no annotations, the description does a solid job listing the return fields and the practical purpose. Minor omissions exist, such as explicit sorting semantics and pagination response behavior, but the tool is a straightforward paginated list, and the schema covers pagination inputs. It is complete enough for an agent to invoke and interpret the result at a basic level.

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 gives meaningful descriptions for 'shop' and 'goodsName', and pageNo/pageSize have default values and constraints, so half of the parameters are sufficiently documented. The description itself adds no parameter-level detail, such as how filtering by goodsName interacts with the store-wide scope or how pagination affects the list. This is adequate but not compensating 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 identifies the resource (store-wide product navigator list) and the specific metrics returned per product, including composite score percentile, refund rate, and stock status. It also states the intended use case ('用于找出拖后腿的商品'), which distinguishes it from sibling tools like pdd_goods_data and pdd_goods_detail by focusing on comparative performance indicators rather than raw product data.

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

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

The description gives a clear contextual use case: finding underperforming products through a storewide navigator list. It does not explicitly mention alternatives or when not to use this tool, but the distinctive metric list and store-wide framing make the appropriate scenario reasonably 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable traits beyond the schema: the response is pure JSON, data is only available for the most recent ready day (previous day), and Excel reporting is deliberately out of scope. It does not explicitly state 'read-only/no side effects', but the verb 拉取 strongly implies a non-mutating fetch.

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

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

The description is compact and front-loaded with the most important constraints (JSON format, data freshness) before listing contents. The final sentence routes Excel needs to an alternative skill. Every part earns its place with no filler.

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

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

For a simple one-optional-parameter overview tool, the description covers what data is returned, when it is available, and the output format. Since there is no output schema, the metric enumeration helps fill that gap. It does not explain error behavior or default-shop resolution, but those are adequately handled by the schema and are minor gaps.

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

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

Schema description coverage is 100% for the single optional parameter, which already documents the shop key semantics. The tool description itself adds no parameter-level detail, but per the baseline, that is acceptable when the schema covers parameters fully.

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 specific verb and resource, '拉取经营总览数据', and enumerates the exact metrics included (成交金额/订单/转化率/退款, 店铺评分, GMV升级进度, 客服质量). It also states the data format (纯 JSON) and freshness (最近已就绪日即前一日), making the tool's purpose unmistakable and distinct from 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?

The description clearly conveys when the tool is appropriate: for pulling overview data as pure JSON for the most recent ready day. It explicitly directs users to the pdd-daily-report skill when Excel output is needed, which is a useful exclusion. However, it does not explicitly contrast this tool with sibling pdd_* data tools, though the overview scope is clear enough to avoid confusion.

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. The description adds value by specifying that it verifies store/ad/product against the current promotion list, retains null suppression metrics, and does not issue hourly requests. These are behavioral details beyond the annotations, with no contradiction.

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 with no wasted words, front-loading the core action and scope. However, domain-specific jargon like 'null抑制指标' may reduce clarity for agents lacking context.

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 5 parameters, no output schema, and low schema coverage, the description does not explain what the returned daily report contains, how the 'yesterday' default works, or the role of cdpUrl. The 'current promotion list' dependency is also undefined, leaving an agent without sufficient context to use the tool correctly.

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

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

Schema coverage is only 20%, so the description must compensate for parameter meanings. It vaguely references '店铺/广告/商品' (shop/ad/product) and '该ad', hinting at shop and adId, but leaves expectedMallId, date, and cdpUrl unexplained. Required parameter expectedMallId remains ambiguous.

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 action ('读取' / read) and the resource ('该ad创意日报' / that ad's creative daily report). It also scopes the tool as single-link, daily, and explicitly not hourly, distinguishing it from sibling tools like pdd_promotion_data. The title reinforces the 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 implies usage for daily creative reports and explicitly excludes hourly requests ('无创意小时或单品小时请求'). However, it does not name alternatives for hourly needs nor provide explicit when-to-use conditions. The prerequisite 'current promotion list' is mentioned but not elaborated.

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

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

No annotations are present, so the description carries the disclosure burden. It does well: it warns that the tool will temporarily open the marketing center page, states the ~30 second runtime, and clarifies all returned values are plaintext. It could add prerequisites like login state or anti-bot risk, but the main behavioral traits are disclosed.

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 one front-loaded sentence: resource and default first, then the requested fields, then side effects and duration. Every clause adds useful information and there is no fluff.

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 compensates by enumerating the returned sections (units, account summary, daily spend) and the exact unit fields. The main remaining ambiguity is the vague '近几日' (which days) and no failure/empty-result behavior, but for a read-oriented data pull this is largely adequate.

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

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

Schema coverage is 100% and both parameters already carry descriptions, enums, and defaults. The description's '默认昨日' only repeats the schema default and adds no meaningful semantic information beyond what the schema already provides.

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 concrete verb and resource ('拉取营销中心推广数据') and enumerates the exact data scope: all promotion units by spend/ROI/GMV/orders, account summary, and recent daily spend. It is unmistakable what data this returns, though it does not explicitly contrast against sibling promotion tools like pdd_promotion_detail or pdd_promotion_export.

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 indicates the default date and that it performs a live collection by opening the marketing center page, which implies it is for one-time data pulls. It gives no explicit when-to-use guidance or exclusions relative to sibling tools, so an agent must infer appropriateness from the tool name and field list.

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, and the description reinforces the read-only nature. Valuable non-obvious behavior is added: platform-suppressed null metrics are not zero, creative hours are unsupported, and expectedMallId is mandatory for shop verification. This goes beyond what annotations alone 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 one dense sentence, front-loaded with the core action and resource, followed by return contents and finally critical constraints. Every clause carries meaningful information 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?

With no output schema, the description still names the major return categories: dailyReport, 24-hour metrics, creative images, and daily metrics. It also covers key constraints and null semantics. It could mention error behavior or exact response fields, but for a read-only detail tool this is largely sufficient.

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

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

Schema description coverage is 60%, so the description must partly compensate. It does add meaning to expectedMallId as a shop-verification parameter and ties adId to the target promotion, but it does not explain the date format or the shop/cdpUrl relationship beyond what the schema already provides.

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 action: '按adId读取单个稳定成本推广的昨日/指定日数据' and enumerates what data is returned (dailyReport, 24-hour raw metrics, creative images, daily metrics). It does not explicitly name sibling alternatives, but the scope is specific enough to distinguish it from list-level or operations-level tools.

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

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

It gives clear usage context: read one stable-cost promotion's data by adId, expectedMallId must verify shop, and only verified scenesMode=1 is supported. It also excludes creative-hour metrics, which helps the agent avoid expecting unsupported data. It does not point to an alternative tool for other cases, so it falls short of a 5.

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, which the description reinforces ('只读报表', '不改预算出价'). Beyond that, it discloses timeout limits, polling intervals, recovery from same taskId/outDir, file contents (missing rows not zero-padded, creatives excluded), and runtime dependencies (python openpyxl/xlrd). This is a rich behavioral disclosure that goes well 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 a single dense paragraph but is reasonably sized for the amount of information it conveys. The main purpose is front-loaded, and each sentence adds meaningful content (modes, timing, recovery, file details, dependencies). However, it could be better structured with separators or bullets for clarity, but it is not overly verbose.

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

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

Given the tool has 10 parameters (1 required) and no output schema, the description covers the core workflow: what files are produced, mode-specific behaviors, timeout/recovery, and data exclusions. It does not explain all parameters or authentication requirements, but for an export tool the essential usage context is present. Minor gaps in parameter explanation 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?

Schema description coverage is only 30%, and the description does not compensate. It mentions 'mode' and its variants, and indirectly references taskId/outDir for recovery, but fails to explain adId, date, endDate, cdpUrl, maxPolls, expectedMallId, or their roles. With such low schema coverage, the description should have detailed each parameter, but it leaves most of them undocumented for the agent.

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 generates read-only report tasks and downloads raw XLS/XLSX, parses JSON and manifest files, and explicitly notes it does not modify budget/bids. It distinguishes itself from sibling tools like pdd_promotion_operations (which implies mutations) and pdd_promotion_data (which likely serves data views). The verb-resource pairing is 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 provides detailed mode guidance (shop-hourly, unit-hourly, unit-daily) with timing expectations and recovery behavior, and notes exclusions (creatives not included). However, it does not explicitly name alternative tools or state when this tool should be avoided in favor of another, leaving some inference to the agent.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds behavioral context: pagination, deduplication, and shop identity verification. It does not contradict the annotations and discloses more than the structured metadata alone.

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, and the primary action and resource are front-loaded. Some technical terms like 'scenesMode=1' and 'CDP端点' are compressed without elaboration, slightly reducing 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?

With no output schema and low parameter coverage, the description should explain more about return values and how the four parameters affect the call. It covers purpose and key behavior, but leaves gaps around result shape, pagination details, and route selection among promotion siblings.

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 'shop' has a schema description), yet the description does not explain expectedMallId, cdpUrl, or date value semantics. It refers to a 'CDP endpoint' and '店铺身份核验' but does not compensate for the low schema 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 uses a specific verb ('读取') and names the exact resource: the full sceneMode=1 product promotion list with summary. It also differentiates itself by pointing to pdd_promotion_detail for per-unit hourly/creative data, so an agent can distinguish it from related 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?

It explicitly states the complementary relationship with pdd_promotion_detail ('配合pdd_promotion_detail逐单元读取...'), which gives clear context on when this list tool is the right first step. However, it does not mention exclusions or alternatives like pdd_promotion_data or pdd_promotion_operations.

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 goes far beyond the readOnlyHint and destructiveHint annotations by disclosing concrete behaviors: per-page total validation, deduplication by event ID, retention of second-level timestamps and original change text, operator anonymization, null type handling, and early-window error behavior. This gives an agent a rich picture of what will happen when the tool is invoked.

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

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

The description is compact and information-dense, with no filler. Each clause adds a distinct behavioral or semantic detail, and the key read-only/non-mutating constraint is clearly placed near the end. The semicolon-separated structure is acceptable for a dense technical description.

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 that there is no output schema, the description does a good job of covering return-related traits (timestamps, original change text, anonymization, null type) and an important error condition (early platform window). It is incomplete only in that cdpUrl remains unexplained and the date range format is not specified, which are notable for a 6-parameter 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?

With schema description coverage at only 17%, the description must compensate, and it does partially: it explains that startDate/endDate define a date range and that shop/ad/product are verified. However, it does not explain the cdpUrl parameter, the exact date format, or the meaning of expectedMallId beyond the loose '商品' mention, leaving meaningful gaps.

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 and title clearly identify the resource as operation records for a single promotion link and the action as retrieving them. It adds specificity with phrases like '真实商品推广抽屉操作记录接口' and '不改投放', but it does not explicitly differentiate this tool from closely related siblings such as pdd_promotion_detail or pdd_promotion_data.

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 useful context: it is read-only, does not request hourly data, does not modify ad delivery, and errors when the date is earlier than the platform window. However, it gives no explicit guidance on when to choose this tool over an alternative, and no sibling tool is named as a comparison.

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?

【无 annotation，描述承担全部行为披露责任】“跨页拉取”和“自动复用页面自身请求体模板”披露了分页和模板复用行为，并暗示“拉取”为读取操作。但未明确说明认证要求、失败时的行为、或导出 CSV 对文件系统的副作用（虽有参数说明，但描述未补充默认行为）。整体有一定披露，但不够完整。

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?

在无 annotation、无输出模式的情况下，描述覆盖了主要用途和关键能力，且参数模式已补充了 refreshTemplate 等细节，基本可用。但未说明返回结果的形式（是否为列表、字段结构）、依赖登录态的提醒，以及模板复用失败的常见后果，整体上下文仍留有缺口。

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?

输入模式对 7 个参数全部有详细描述，覆盖率 100%，因此基线为 3。描述中的“待举报、关键词过滤、导出 CSV”虽然映射到 reportableOnly、keyword、outCsv，但未超出模式已有的说明，也未对参数格式或边界条件增添新信息。

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?

描述给出了明确动词“拉取”和资源“mms 后台评价列表”，直接点明工具作用，且与 sibling 中的商品、推广、聊天类工具明显区分。同时列出“待举报、关键词过滤、导出 CSV”等能力，进一步明确了功能边界，代理无需查看其他工具模式即可判断用途。

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?

描述未提供任何“何时使用”或“何时不用”的指导，也没有提及替代工具或切换条件。虽然功能列表暗示了过滤和导出场景，但没有说明在什么情况下应选此工具而非其他 sibling，代理只能依赖默认推断。

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses which components are verified (Chrome debug port, tab, login state, request channel), implying a read-only diagnostic operation. However, it does not state the output format, whether the check can also repair issues, or how results are interpreted — leaving the agent to guess what a 'success' or 'failure' response looks like.

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 efficient sentences with zero filler. The core purpose (what components are checked) is front-loaded, followed immediately by the actionable usage directive. Every sentence earns its place and the structure supports quick agent parsing.

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 (single optional param, no annotations, no output schema). The description covers purpose and usage trigger well, but omits what the check returns or how results should be interpreted — a notable gap for a diagnostic tool since an agent needs to know how to read the outcome to decide next steps. Minor but real.

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% — the single optional 'shop' parameter is fully documented in the schema, including its semantics (shop name key for config/shops.json, omitted = default shop). The description adds no parameter-level detail beyond the schema, so the baseline 3 applies correctly.

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 specifies a clear verb ('检查' / check) and specific resources: Chrome debug port connection, mms.pinduoduo.com tab, login state, and in-page request channel. It is a health/diagnostic tool clearly distinguishable from all sibling data-retrieval tools (reviews, chat, goods, promotion), so an agent can immediately recognize it as the environment pre-flight 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 gives an explicit trigger condition: '其他工具报错时先调这个' (when other tools report errors, call this first). This is clear when-to-use guidance that positions it as a first-line diagnostic. It does not name a specific alternative or state when NOT to use it, but for a diagnostic tool the trigger is well-defined enough to route correct selection.

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