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

With no annotations, the description carries the full burden, and it does disclose one important failure mode: Pinduoduo retired goods_id_list and passing it triggers error 40005. It also notes the returned link carries coupons. However, it says nothing about authentication, rate limits, or link persistence, so the behavioral picture is only partially drawn.

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?

Purpose is front-loaded, critical platform caveats follow, and the Args block closes it out. The two consecutive sentences about Pinduoduo overlap slightly, but the structure is easy to scan and mostly earns its length.

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?

An output schema exists, so return values need not be spelled out, and all parameters are explained. The main gap is operational context such as auth requirements or whether the generated link is account-bound, which matters for a conversion tool.

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

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

Schema coverage is 0%, so the description must document all three parameters, and it does: platform values (taobao/jd/pdd), the accepted item format per platform (taobao num_iid, jd skuId or URL, pdd goods_sign), and sub_pid's optional purpose for distinguishing traffic sources. This fully compensates for the bare 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 opening sentence gives a precise verb and resource: turning a product into one's own promotion/rebate link, including coupon handling. No sibling tool (shopping_status, search_products, get_product) performs link conversion, so the purpose is unambiguous against the tool set.

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 platform-specific usage rules (pdd requires goods_sign, not numeric goods_id) and identifies sub_pid's role for traffic attribution. It does not state when to avoid the tool or point to an alternative, but the per-platform context is clear and actionable.

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 supplied, so the description carries the full behavioral burden. It does disclose a genuinely useful behavioral quirk (PDD's numeric goods_id is discontinued, only goods_sign works), but says nothing about permissions, rate limits, or error behavior for a cross-platform 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?

Front-loaded with the core action, then a compact per-platform mapping, then a structured Args block. Every sentence carries information; the parenthetical about goods_sign is long but earns its place by preventing a deprecated-id mistake.

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 two-parameter lookup tool with an output schema already covering return values, the description supplies everything needed to call it correctly. It omits only edge behavior (unknown id, platform/id mismatch, errors), a minor gap.

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% and the schema even lacks an enum for platform, yet the description fully compensates: it enumerates taobao/jd/pdd and maps item_id to num_iid, skuId, and goods_sign respectively, including where the goods_sign token comes from. This prevents the most likely invocation error.

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?

States a specific verb and resource ('按商品 id 查详情' – fetch product details by product id), which clearly separates it from the search_products sibling. It does not explicitly name or contrast with any sibling, so it stops 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?

Usage context is implied rather than stated: the agent can infer this is the follow-up to search_products when it already has an id, but no when-to-use/when-not guidance or named alternative appears. The per-platform id routing hints at how to invoke, not when to choose this 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 full behavioral burden. It discloses the result shape and the sort/range semantics, but says nothing about authentication requirements, rate limits, total result caps, or whether pagination beyond page_size is possible. Useful context, but incomplete for a 6-param search tool with zero 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?

Purpose is front-loaded in the first clause, followed by a compact Args list with no filler sentences. The only minor redundancy is restating return fields that the output schema already defines, but it is one short parenthetical and does not bloat the definition.

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 paginated search with an output schema present, the description covers the searchable dimensions and result semantics adequately, so return values need not be explained further. It falls short of 5 only because cross-platform behavioral differences (e.g., whether commission data exists on every platform) are left unstated.

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 carry all parameter meaning and it does: platform enumerated as taobao/jd/pdd, keyword noted as Chinese-friendly, page documented as 1-based, page_size bounded 1-50, has_coupon explained, and six sort modes spelled out including the meaning of commission and sales. This fully compensates for the bare 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?

States a specific verb and resource ('按关键词搜索商品') and enumerates the unified return fields (price, coupon price, commission rate, sales, shop, link), so the agent immediately knows what the tool produces. It does not, however, distinguish itself from siblings like get_product or shopping_status, which an agent must infer from names alone.

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 Args block gives implicit operational guidance (has_coupon to restrict to coupon items, sort values to shape results), which helps an agent steer the call. There is no explicit statement of when to use this tool versus get_product for a single item, nor any exclusion or prerequisite, so usage remains implied rather than declared.

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 full burden and does so well: it discloses the exact return contents (per-platform mode with live/mock semantics, missing environment variable names, application location and required qualifications). The word 查看 implies a read-only inspection, though read-only/non-destructive behavior is never stated explicitly, leaving a small gap.

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?

Three tightly written sentences: what it inspects, what it returns, and when to call it. The purpose is front-loaded and every sentence adds distinct information 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?

An output schema exists, yet the description still usefully summarizes the return shape (mode, missing env vars, application info), which exceeds requirements. For a zero-parameter diagnostic tool, nothing an agent needs to invoke it correctly is missing.

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

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

The tool takes zero parameters, so the baseline of 4 applies. There is nothing for the description to clarify about inputs.

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?

States a specific verb+resource: viewing credential configuration status, running mode, and application guidance across taobao/jd/pdd. This is unmistakably a diagnostic/status tool, clearly distinguished from siblings like search_products, get_product, and convert_link which all perform shopping operations rather than configuration checks.

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?

"开始任何调用前先看这个" (check this before making any call) gives an explicit usage directive and priority ordering. It does not name when-not-to-use or explicitly enumerate alternatives, but the sequencing instruction is clear enough that an agent knows exactly when to reach for it.

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