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

Annotations only declare readOnlyHint=false and openWorldHint=true, so the description is expected to carry real behavioral weight. It does add valuable context (Ozon plus Wildberries coverage, 20-SKU cap, full field inventory), but says nothing about cost/credits, rate limits, or data freshness, and never reconciles with readOnlyHint=false — an agent cannot tell from the text whether the call has side effects. The retrieval framing is consistent with the operation but not a direct contradiction of a stated safety property.

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 first two sentences are tight and front-loaded, but roughly forty percent of the text is a keyword-stuffed trigger list that repeats "Ozon keyword reverse lookup" / "Ozon SKU keyword reverse" half a dozen times, followed by a redundant "also trigger" sentence. That repetition adds no selection value and buries the useful scope statement.

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 29 parameters and no output schema, the description does the right compensatory work by enumerating what each returned keyword carries (search volume, growth, market space, competitor/seller counts, average price, top products, organic/ad rank and conversion profiles). Remaining gaps are operational: authentication identifiers (uId/memberId) and quota behavior are never mentioned.

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% across 29 parameters, so the schema already documents every field including ranges, pagination, and include/exclude keyword lists. The description adds only light interpretation — the organic/ad meaning of the type filter and the available filter dimensions — which largely restates what the schema says. 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?

States a specific verb and resource with scope: "reverse-looks up Ozon (and Wildberries) search keywords by a list of product SKUs (up to 20), returning which search terms those products appear under (organic/ad search terms)". This is enough to distinguish it from keyword-mining siblings such as nexscope_ozon_keyword_mining or nexscope_ozon_market_keyword_search without opening the schemas, because the input object (SKUs) and direction (product → keyword) are both named.

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?

Explicit use cases are given: "Ozon keyword reverse lookup, listing keyword optimization, competitor traffic word mining, and ad keyword analysis", plus an intent-level fallback ("Also trigger when the intent is to reverse-lookup Ozon search keywords by product SKU"). It never states when NOT to use it or names a concrete alternative tool, so it stops short of a 5.

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