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

Annotations already cover safety (readOnly, non-destructive, open-world), and the description adds real operational context the annotations cannot: no auth needed, anonymous store pricing, a fixed cost of 10 credits per request, and automatic refunds on failure. That cost/refund disclosure is exactly the kind of trait an agent needs before spending budget, though return shape and pagination are not described.

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 short sentences, each carrying a distinct fact (access model, cost, refund policy), with the capability statement front-loaded. Minor waste in the compound "search / inspect / retrieve SKUs" clause, which is the least informative part and also the most ambiguous.

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 only two fully-documented parameters and annotations present, the essential call mechanics are covered. But there is no output schema, and the description never characterizes what the response contains (full product record? variations? pricing fields?) — for a tool whose stated purpose is inspection, that omission leaves a meaningful 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 description coverage is 100% — storeUrl is documented as a public HTTPS root without query/fragment, and productId as a store-scoped positive ID with a digit pattern. The description contributes nothing additional about either parameter (e.g., whether productId must belong to that store, or how to obtain it), 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 states the resource (a WooCommerce product reached through the public Store API) but bundles three loosely-related capabilities — "search within one store", "inspect a product", and "retrieve a parent's SKUs" — into a tool whose only two parameters are storeUrl and productId. An agent can infer it's a product-detail lookup, but the multi-purpose framing muddies what the single call actually returns.

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?

"No store key or OAuth is required" establishes an access prerequisite, which is useful selection context. However, it never says when to pick this over siblings such as nexscope_woocommerce_products, nexscope_woocommerce_product_variations, or nexscope_woocommerce_product_attribute_detail — all of which overlap with the "parent's SKUs" phrasing used here.

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