Get product detail

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

Beyond the annotations (readOnly, openWorld, idempotent, not destructive), the description discloses a critical implementation behavior: there is no public JSON endpoint, so the tool parses the server-rendered Nuxt payload and decodes it with devalue. This is exactly the kind of non-obvious behavior an agent needs to know to trust and interpret results.

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 description is two sentences: the first lists the product scope and included fields, the second explains the implementation workaround. Every sentence carries essential information, with no filler or repetition of annotations.

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 tool that reads an embedded page payload instead of calling a normal API, the description gives the agent everything needed: what fields to expect, how the product identifier can be provided, what verbose does, and why the implementation is unconventional. No output schema exists, but the field list and verbose explanation compensate well.

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 100%, so the parameters are already fully described by the input schema. The description restates the product id/URL forms and the compact vs. verbose output concept, but does not add new parameter-level semantics beyond what the schema already documents.

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 opens with a specific verb-resource pairing ('Fetch the full detail of a single oskelly.ru product') and enumerates exactly what is included, making the tool's scope unmistakable. It clearly distinguishes from the sibling tools by focusing on a single product detail rather than search, facets, or seller lists.

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 description makes the tool's use case evident: retrieving full single-product data by id or URL. It does not explicitly name alternatives like oskelly_search_products or oskelly_seller_products for comparison, but the context is clear enough that an agent would know 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.