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

Annotations already declare read-only, idempotent, open-world, and non-destructive, so the description's job is to add information beyond those annotations. It does so: it lists the result categories returned and discloses the billing model (¥0.2 per call, charged only on success, with automatic refund on failure or empty results), which is a real behavioral trait an agent cannot get from structured fields. It omits authentication or rate-limit details, but the schema handles auth via X-FW-Token, so this remains a solid score.

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?

Four dense sentences that cover purpose, return contents, usage context, and pricing; nothing is wasted. The key facts, namely what it fetches and what it returns, are front-loaded before the pricing caveat.

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?

There is no output schema, so the description must describe what is returned, and it does (registration info, operating metrics, contact details). It is a simple read-only lookup with two parameters, and the description covers everything an agent needs in order to call it correctly. Only minor details, such as whether the result is nested or what shape it has, are 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?

Schema description coverage is 100%, and both parameters are documented (seller_id is 商家ID; _token notes the preferred header). The description adds no further meaning about seller_id format, where to source it, or whether it accepts shop IDs versus member IDs, so any additional guidance on which ID to use is missing. The baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: it obtains merchant/shop information for 1688 (获取1688商家信息), and it distinguishes this from product-level siblings such as item_get_1688 and item_search_1688 by scoping the result to registration data, operating metrics, and contact details. It does not name any sibling, so it falls one step short of a perfect score, but the audience can still infer the distinction.

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 phrase 做供应商背调、店铺监测时用 clearly states when the tool applies - it is for supplier due diligence and shop monitoring. This is a clear usage context, but no exclusions or explicit alternatives are given (for example, 'use item_get_1688 for individual products'), so the tool meets the clear-context bar but not the named-alternatives bar.

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