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

Adds substantial context beyond the annotations: authorization lifetime requirement and ownership scoping, the fact that procurement responses are live and must not be cached, the instruction to stop on status=false even when the envelope reports success, and unit semantics (totals in cents, cargo prices in CNY). The phrase "do not automatically retry writes" creates mild tension with readOnlyHint=true, but in context it reads as guidance for the surrounding procurement write chain rather than a claim that this call mutates state.

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 purpose followed by hard preconditions, and each subsequent sentence carries an operational rule. "Use your Nexscope API key" is mild boilerplate, and the write/retry sentence is ambiguously worded, but there is no filler overall.

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 an 8-parameter, nested-object tool with no output schema, the description covers prerequisites, error semantics and units but says almost nothing about what a preview actually returns (price breakdown? shipping options? per-item totals?) — the exact information an agent needs to decide whether the preview answered its question.

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 75% schema coverage and nested objects, the schema already documents the enums, the addressId reference to receiveAddressList, and the offerId/quantity contract. The description contributes nothing parameter-specific — its units note concerns returned values — so 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?

"Order Preview for the currently authenticated Nexscope user" names the resource but the term "Preview" is never unpacked — nothing says this computes pricing/shipping/totals for a prospective 1688 order rather than creating one. No sibling is named, so the boundary with nexscope_data_alibaba1688_create_order is left for the agent to infer from the name 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 prerequisite (an ACTIVE, unexpired 1688 authorization owned by the current user) is a real usage condition, and the API-key note sets context. But there is no explicit when-to-use or when-not-to-use statement, and no guidance such as "call before create_order to validate totals" that would let an agent choose this over the write/status/payment siblings.

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