get_product

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

Annotations already establish that the tool is read-only, idempotent, and non-destructive. The description adds useful behavioral context by calling the data 'live' and exposing that variant inclusion is optional, which complements openWorldHint by signaling that prices and stock can change between calls. No contradiction with annotations exists.

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 front-loaded with the core purpose, then delivers a dense but purposeful list of return contents in one well-structured sentence. It is longer than minimal, but nearly every clause contributes useful information for tool selection and invocation.

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?

Given the read-only annotations, full parameter documentation, and presence of an output schema, the description is complete for calling the tool correctly. It clarifies the granularity (one article), the live nature of data, and the optional group-variant behavior, so no essential contextual gap remains.

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?

The input schema already documents both parameters fully, including the article number format and the meaning of include_variants. The description's 'optionally — the other articles merged into the same product group' phrase mirrors include_variants but does not add new parameter-level semantics beyond the schema.

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 names a specific operation and resource: it returns a 'Full, live product card for one article'. The detailed list of return contents (price, stock, delivery, seller, ratings, etc.) makes its purpose concrete and distinguishes it from broader tools like search_products and compare_products.

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 clearly frames the tool as the single-article detail card, which is enough context for an agent to select it over search or compare tools. It also notes the optional include_variants behavior. However, it does not explicitly direct the agent to siblings such as get_price_history for full price history or get_reviews for review detail.

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