Dinilu — custom promotional products

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

No annotations are provided, so the description carries the full burden. It discloses what the operation returns (attributes, options, MOQ, quantity step) and how the output connects to get_quote determination. However, it does not describe response formatting, pagination, or potential errors, though these are less critical for a simple read operation.

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?

Two compact sentences deliver the core action first and then explain the critical sequencing relationship. No filler or repetition of schema information.

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 single-parameter, read-only retrieval tool, the description is largely complete: it identifies the input, the output contents, and the dependent sibling tool. There is no output schema, so the description partially compensates by listing returned elements, though the exact response shape is not specified.

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 schema already provides 100% coverage of the single parameter with a clear description of mpn and its source. The tool description adds little beyond that, matching the baseline for fully described schema parameters.

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 uses a specific verb ('Get') with a specific resource: a product's configurable attributes, options, minimum order quantity, and quantity step. This clearly distinguishes it from the sibling tools get_quote and search_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 explicitly instructs the agent to call this before get_quote, explaining that the attribute and option IDs returned are what get_quote expects. It also implicitly ties mpn acquisition to search_products, giving clear sequencing guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It discloses that the quote is indicative, excludes VAT and shipping, and is never binding. It explains the MOQ behavior (quantity raised to MOQ and a warning returned), the warning for omitted quantity, attribute defaulting and reporting in warnings, and the exact matching requirement for option names (including double spaces and per-domain translation). These are non-obvious behaviors an agent must know to call the tool correctly.

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 appropriately sized for the complexity. It opens with the core purpose and key caveats (indicative, non-binding), then elaborates on parameters in a logical order. Every sentence provides necessary guidance; there is no fluff or repetition. The front-loading of critical warnings (read warnings, indicative) ensures the agent does not miss important context.

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 nested attributes object, the absence of an output schema, and the tool's pricing semantics, the description is exceptionally complete. It covers how to pass attributes, how quantities are handled, how countries are specified, and what warnings to expect. It even instructs the agent to read warnings before presenting the price. There is no missing information an agent would need to invoke the tool successfully.

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%, so the baseline is 3, but the description adds substantial meaning beyond the schema. For 'qty', it explains the MOQ behavior and price sensitivity. For 'country', it enumerates accepted formats (name, alpha-2, alpha-3, numeric). For 'attributes', it explains the id structure, accepted option names with exact matching, and the default-filling behavior. These enrich the schema definitions significantly, making the tool easier to use correctly.

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 clearly states the tool's purpose: 'Price a specific configuration and quantity, with production time and shipping options.' It uses a specific verb (price) and resource (configuration and quantity), and explicitly notes it is 'indicative, excludes VAT and shipping, never binding.' This distinguishes it from get_product (retrieving product details) and search_products (searching for products), leaving no ambiguity about what the tool does.

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 provides clear guidance on when to use the tool: to obtain a price for a specific configuration and quantity, with production and shipping options. It also instructs to 'Read the returned warnings before presenting the price' and advises always passing the real target quantity because 'price per piece changes substantially with volume.' While it does not explicitly name alternatives or exclusions, the context of when to use it is well covered. It could have explicitly mentioned that this is not for binding orders or that it replaces other tools, but the indicative nature is stated.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool 'Returns mpn, title, page URL and category,' which implies a read operation, but does not mention pagination, rate limits, authentication requirements, or potential errors. The description is not misleading but lacks depth regarding operational behavior, especially since no annotations are available to cover the safety profile.

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 long and front-loaded with the core purpose, followed by return information and the critical note about mpn usage for siblings. Every sentence contributes valuable information without redundancy or fluff. It is tightly written and efficient.

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 absence of an output schema, the description adequately explains the return values (mpn, title, page URL, category) and links them to downstream tools. It also implicitly covers the 'list everything' scenario by referencing free text and category filters. The description provides enough context for an agent to invoke the tool correctly without needing additional details.

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 schema provides 100% coverage for all three parameters (limit, query, category), so the baseline is 3. The description does not add additional semantic meaning beyond what the schema already explains; it merely summarizes the search capabilities (free text and/or category) without detailing parameter syntax or constraints. It neither enhances nor detracts from the schema's documentation.

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 clearly states the tool's purpose: 'Find products in this catalogue by free text and/or category.' It specifies the exact resource (catalogue) and the action (search), and explicitly lists the return fields (mpn, title, page URL, category). It also distinguishes itself from siblings by noting that 'mpn is what get_product and get_quote take,' which prevents confusion about when to use this tool.

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 implies usage context by stating that the returned mpn is what the sibling tools require, effectively telling the agent to search first before calling get_product or get_quote. However, it does not explicitly state when not to use this tool or mention any alternatives beyond that implicit hint. The guidance is clear enough for a search-first workflow but lacks explicit exclusions.

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