pdd_promotion_creative_dailyFetch daily creative report for a store/ad/product verified against the promotion list, preserving null-suppressed metrics.
从当前推广列表核验店铺/广告/商品，仅读取该ad创意日报；保留null抑制指标，无创意小时或单品小时请求。
| Name | Required | Description | Default |
|---|---|---|---|
| adId | Yes | ||
| date | No | yesterday | |
| shop | No | 店铺名（多店铺时指定，对应 config/shops.json 的键名；省略=默认店铺） | |
| cdpUrl | No | ||
| expectedMallId | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does 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.