Suorigo Konfigurátor

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

Annotations declare readOnlyHint=false and idempotentHint=false, and the description adds that the tool validates and saves a design, indicating a persistent side effect. It also discloses that it returns an indicative price and layers with uploaded URLs, which is useful behavioral context beyond the annotations. No contradiction found.

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 a single, front-loaded sentence that efficiently states the action, object, and result without redundancy. Every clause adds information: validation, saving, the design scope, and the returned data for create_order.

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?

The description covers the overall purpose and return value (price and layers), but with 5 parameters and no output schema, the absence of parameter explanations and edge cases leaves gaps. It does not mention required fields (product, layers) or the meaning of preview data URLs, so while the main context is clear, it is not fully complete for a tool of this complexity.

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 only 20% (only 'layers' has a description). The top-level description mentions 'logo/text on t-shirt sides' which loosely relates to the 'layers' parameter but does not explain `colorId`, `product`, `previewBackDataUrl`, or `previewFrontDataUrl`. With such low coverage, the description fails to compensate for the undocumented 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 clearly states the tool validates and saves a design (logo/text on t-shirt sides) and returns an indicative price plus layers for use in create_order. This distinguishes it from siblings like create_order (which places the order) and get_quote (which presumably only quotes) by specifying the resource (design) and the output (prepared layers with URLs).

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 the tool is a precursor to create_order by stating the result is for use in create_order, giving clear context for when to use it. However, it does not explicitly say when not to use it or name alternatives (e.g., use get_quote for price-only queries), so it lacks explicit exclusions.

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?

Annotations already indicate readOnlyHint:false and idempotentHint:false, but the description adds valuable behavioral context that the tool only creates an order awaiting payment and returns instructions, emphasizing the agent does not pay. This explains the side effects beyond the bare annotations, though it does not cover all edge cases like idempotency failures.

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 exceptionally concise, two short sentences front-loaded with the core purpose and immediate follow-up. Every word adds value, including the payment flow and required fields, with no redundancy or filler.

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?

Without an output schema, the description compensates by explicitly stating that it returns payment instructions (amount, account, variable symbol, QR). It also covers key prerequisites. It lacks details on error handling or the full structure of the customer object, but given the nested schema and annotations, it is sufficiently complete for an agent to act effectively.

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 describes most parameters (67% coverage), so the description adds limited incremental meaning. It highlights that customer.email is required and consent must be true, which reinforces the schema, but it does not elaborate on the structure or allowed values of other parameters like notes or promoCode.

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 'Založí objednávku' (creates an order) and clearly states the immediate outcome: it waits for payment and returns payment instructions. This distinguishes it from sibling tools like get_quote and create_design, making its purpose unmistakable.

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?

It provides clear context for use by specifying prerequisites (customer.email and consent:true) and the behavioral note that the agent does not pay, which guides when to invoke it. However, it does not explicitly compare with alternatives like get_quote or list_products, so it omits explicit when-not-to-use 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?

The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the status includes payment and processing details, which is useful context, but it doesn't explain error behaviors or return format.

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 a single, focused sentence that immediately states the function and the key parameter, with no extraneous words.

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 simple read-only tool with one parameter and no output schema, the description provides enough information: what it returns and how to identify the order. It doesn't need to list all possible statuses given the tool's low complexity.

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 only defines orderNumber as a string with no description. The description compensates by indicating that 'podle čísla objednávky' means the order number is the lookup key, giving semantic meaning.

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 a specific verb 'Vrátí' (returns) and a clear resource: order status, further specifying it includes payment and processing status. This distinguishes it from sibling tools like create_order and get_quote.

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 implies this tool is for checking order status based on order number. While it doesn't explicitly name alternatives, the context is unambiguous and no exclusion is needed.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds that the price includes VAT, which is useful behavioral context, but it does not disclose return format, error cases, or any other operational details.

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 a single sentence, front-loaded with the verb and purpose, with no redundant information. It efficiently conveys the core behavior.

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 no output schema, the description should ideally convey what the tool returns, but it only states the pricing function. Given the read-only annotation and clear purpose, it is minimally complete, but the omission of printSideHeightsCm and the required product parameter leaves gaps for an agent trying to invoke it correctly.

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 only 50%, and the description should compensate for undocumented parameters. It mentions quantity/sizes, printed sides, and promo code, but omits the required product parameter and printSideHeightsCm. For the parameters it does mention, it adds little beyond the schema, leaving key semantics unexplained.

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 calculates the price of a configured T-shirt including VAT, distinguishing it from siblings like create_order or get_order_status. The verb 'Spočítá' (calculates) and resource 'cenu nakonfigurovaného trička' are specific and unambiguous.

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 context for when to use the tool: when pricing a configured T-shirt before placing an order. It does not explicitly state exclusions or alternatives, but the sibling tool names and the read-only nature make the intended usage obvious.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read-only behavior is known. The description adds context about the returned data (colors, sizes, prices, discounts) and that output varies based on whether the product parameter is provided.

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?

One concise sentence that front-loads the action and resource, contains no filler, and is easy to scan.

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?

The tool is simple, with one optional parameter, full schema coverage, and annotations covering safety. The description adequately explains the return behavior. Although it does not mention pagination or response format, these are not essential for this low-complexity tool.

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 fully describes the optional 'product' parameter as id/slug, and the description echoes that role. However, it does not add extra syntax or formatting details. With 100% schema coverage, the baseline of 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 clearly states it returns a catalog of Suorigo t-shirts/hoodies (colors, sizes, prices, discounts) or a single product by id/slug. The verb and resource are specific, and it is easily distinguished from sibling tools like create_order or get_quote.

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 when to use it: to fetch product catalog or a specific product. It does not explicitly name alternatives or exclusions, but the sibling tool names are distinct enough that no ambiguity arises.

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