drukarnia

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

No annotations are provided, so the description must carry the burden. It explains what the tool returns and how width_mm/height_mm affect pixel dimensions, but it does not explicitly state that this is a read-only operation, mention authentication prerequisites, or address invalid inputs. This is a partial disclosure.

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 sentences, front-loaded with the primary purpose, and the second sentence adds a specific use case (AI image generation) without redundancy. Every word earns its place.

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 main purpose, a special feature (ai_generation), and parameter behavior. Since an output schema exists, return values need not be detailed. Minor gaps include prerequisites and error conditions, but overall it's sufficient for an AI agent to decide invocation.

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 0%, so the description must compensate. It explains width_mm and height_mm as trim size in millimeters used to compute custom pixel dimensions, which adds value. However, product_slug is not explicitly described, though it is implied by 'barwa.pl product'. Partial compensation.

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 verb 'Get' and the resource 'print-file preparation requirements for a barwa.pl product', specifying format, color mode, resolution, bleed. This distinguishes it from sibling tools like get_quote or list_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 gives clear context for when to use the tool — when print-file specs or AI-generator pixel dimensions are needed. It doesn't explicitly exclude alternatives, but the sibling tools have distinct purposes, so the context is sufficient.

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?

No annotations are provided, so the description carries full burden. It describes that the tool returns a full set of quotable parameters, including mandatory finishes. It is transparent about the output without mentioning side effects or auth, which is acceptable for a schema retrieval tool.

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, with the main purpose upfront ('Get the full set...') followed by specific details. Every sentence adds value, no fluff.

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 one input parameter and an output schema (not shown), the description covers what the tool returns and when to use it. It could be improved by mentioning that product_slug should be a valid slug, but for a schema retrieval, it is mostly complete.

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 parameter product_slug is not described in the schema (0% coverage) and the description only indirectly implies it's a product identifier. It does not give examples or format, but the tool name and purpose provide enough context for a single parameter. Baseline 3 for single param with no schema description.

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 verb 'get' and the resource 'product pricing schema'. It lists specific contents like sizes, quantity limits, materials, etc., and distinguishes from sibling tools by noting it should be called before get_quote, differentiating it from get_quote, get_file_specs, and others.

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 says 'Call before get_quote to know valid option ids', providing clear usage context. It implies when to use it but does not explicitly mention when not to use it or list alternatives, but the context from siblings is sufficient.

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, the description carries the full load and does well: it discloses that default finishes are pre-included, that remove_finish_groups works only for groups with removable=true, that warnings can be returned and must be relayed, the per-design minimum rule, and a named error/retry path. It does not cover permission/auth needs, rate limits, or whether the call is purely non-mutating, which keeps it short of a 5.

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?

Well front-loaded: purpose and the schema-prerequisite come first, then parameter semantics, then the finish/warning handling. It is dense and somewhat run-on (two independent ideas packed into the final sentence), but almost every clause conveys a distinct rule an agent would otherwise get wrong, so little is wasted.

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?

An output schema exists, so return values need not be documented, yet the description still names the useful ones (net/gross price, currency, delivery time, matched product name/link). Combined with the usage and error guidance, an agent has nearly everything; the only real gap is the unexplained double_sided flag and no note on permissions or limits.

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 0% across 11 parameters, so the description must compensate, and it does for most: width/height units (mm), format_id vs size, the TOTAL-quantity semantics, the liczba_wzorow interaction with the minimum, pages scope and step rules, material_id requirement, and remove_finish_groups. double_sided is never explained, leaving one parameter opaque.

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+resource ('Get a price quote for a barwa.pl product') and goes further to pin down semantics ('calculated by the same engine as the on-site calculator, so the price is identical'). It is clearly distinguishable from sibling get_product_pricing_schema, which it explicitly names as a prerequisite rather than a substitute.

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?

Gives an explicit ordering rule ('Use get_product_pricing_schema first for valid option ids') plus conditional branch guidance: width/height for free-size vs format_id for predefined, pages only when the schema lists options.pages, material_id when material is required with no default. It even prescribes recovery behavior on the quantity_not_multiple error, so the agent knows both when and how to call.

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?

No annotations are present, but the description clearly states what data is returned (thresholds and free-shipping with context). For a read-only tool with no side effects, this is sufficient transparency.

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, clear sentence with no unnecessary words. It is perfectly concise and front-loaded.

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 parameters and an existing output schema (implied), the description fully specifies what the tool returns. No additional context is needed given the tool's simplicity.

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?

There are zero parameters, so the baseline is 4. The description adds value by explaining the output, which goes beyond the empty input 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 explicitly states it retrieves shipping cost thresholds based on order weight and the free-shipping threshold, all in the shop's country and currency. This is specific and distinct from sibling tools which deal with files, pricing, quotes, products, and recommendations.

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?

No explicit usage guidance or alternatives are provided. However, the tool's purpose is straightforward with no parameters, making when to use it self-evident. The lack of explicit direction keeps this at a 3.

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?

No annotations provided; the description describes a simple list operation with no destructive actions. It could be improved by stating read-only or authentication requirements, but the current description is adequate.

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 sentences, front-loaded with purpose, no extraneous words. Every sentence adds value.

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 parameterless list tool with an output schema, the description covers the purpose and cross-references the pricing tool, making it complete.

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?

No parameters exist, so the baseline is 4. The description adds no parameter info, which is acceptable since there are none.

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 lists printing products from a specific shop, with examples, and distinguishes from sibling tools like get_quote which handles pricing.

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?

Explicitly mentions when to use this tool (to list products) and directs the agent to use get_quote for pricing, including the required slug parameter.

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?

No annotations are provided, so the description carries full burden. It discloses that the tool returns products with links and directs pricing to get_quote. It also instructs on handling empty results. For a recommendation tool, this sufficiently covers behavioral traits.

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 extremely concise with two sentences. It front-loads the core purpose and adds necessary guidance without any wasted 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?

Given the presence of an output schema (not shown), the description does not need to detail return values. It covers the essential behavior: recommending products, mentioning links, and referencing pricing. The instruction for empty results adds completeness. The tool is simple enough that this is adequate.

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 single parameter 'purpose' has no description in the schema (0% coverage). The description adds meaning by providing examples of needs ('trade fair', 'gift packaging') and implies it is a free-text customer need. This adequately compensates for the schema gap.

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 'Recommend' and clearly identifies the resource 'barwa.pl products'. It provides concrete examples ('something for a trade fair', 'gift packaging') that distinguish it from sibling tools like list_products 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 states when to use the tool (to match a customer need) and what to do if no results (ask for clarification). It also references a related tool (get_quote) for pricing. However, it does not explicitly exclude scenarios or mention alternatives.

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