Painto

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates content topics and does not mention whether the tool is read-only/static, where the information comes from, how current it is, or what format the answer takes. It is not misleading, but it is thin.

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 core question and followed by concrete specifics. Every part is informative and there is no filler or redundancy.

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 zero-parameter informational tool with no output schema or annotations, the description covers the relevant subtopics adequately: carriers, prices, free shipping threshold, and payment methods. A small gap is that it does not explicitly state what the tool returns, but this is not critical for such a simple 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 input schema has zero parameters, so there are no parameter semantics for the description to clarify; the baseline for 0-parameter tools is 4. The description still adds value by enumerating the information domains the tool covers.

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 identifies the tool's resource: delivery and payment information, and lists concrete subtopics (carriers, shipping prices, free-shipping threshold, payment methods). This differentiates it from siblings like painto_dostupnost, painto_kontakt, and painto_sortiment without needing to open the schema.

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 the tool through its topic coverage, but it does not explicitly state when to use it versus alternatives or name any sibling tools. An agent can infer that delivery/payment questions belong here, but the guidance is not explicit.

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 the full burden. It discloses the core behavior—checking stock quantity by code or EAN—but does not explain edge cases, exact return format, or behavior when the code is not found. This is adequate but not richly transparent.

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 short, front-loaded sentences with no filler or redundancy. Every word contributes meaning: the action, the resource, and the lookup key.

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 lookup tool, the description tells the agent what to pass and what it returns (stock quantity). It could add detail about zero-stock or not-found behavior, but the core context needed for correct invocation is present.

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%, and the parameter description already states 'Katalogový kód nebo EAN produktu.' The tool description repeats the same information without adding new semantic detail, so 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 uses a concrete action and resource: 'Zjisti, kolik kusů konkrétního produktu je skladem' (find how many pieces of a specific product are in stock). It clearly distinguishes this from siblings like painto_hledej (general search) and painto_sortiment by focusing on stock quantity lookup via catalog code or EAN.

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 the agent has a catalog code or EAN and needs a stock count. It does not explicitly name alternatives or exclusion cases, so it stops short of a full 5.

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 transparency burden and does a good job by stating what the tool returns: name, price incl. VAT, stock availability, and a link. It implicitly communicates a read-only search operation, though it does not cover edge cases such as no results or ordering behavior.

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 compact and front-loaded: it states the action, gives representative examples, and then lists the return fields in one additional sentence. Every part 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?

For a relatively simple search tool, the description plus fully covered schema gives an agent enough to invoke it correctly. It states the return payload, parameter semantics are documented, and no output schema exists to explain further. A minor gap is the lack of explicit failure/no-result behavior.

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 all three parameters with 100% coverage, so the baseline is 3. The description adds value by giving real example values for 'dotaz' such as 'váleček', 'špachtle', and 'maskovací páska', which helps the agent form valid queries.

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 action ('Najdi nářadí nebo příslušenství') and lists search keys (name, code, EAN, need) with concrete examples. It is easy to understand what the tool does, but it does not explicitly differentiate it from sibling catalog or assortment tools.

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 intended use is implied clearly: search for products by various identifiers or needs. However, there is no explicit guidance about when to prefer this tool over painto_sortiment, painto_katalog_pdx, or painto_dostupnost, and no exclusions are mentioned.

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 transparency burden. It usefully discloses that the customer can act without creating an account and that the interaction results in an order or inquiry being sent. It does not describe what happens after submission or the exact return behavior, but the added behavioral context is meaningful.

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 only two sentences. The first frames what the tool is and how it behaves, and the second gives the invocation triggers. Every clause adds value, with no filler or redundant schema repetition.

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 zero-parameter catalog tool, the description covers the purpose, user flow, account requirement, and when to use it. The only minor gap is that it does not explicitly state what the agent should return or display to the user, but that is not critical given the interactive nature of the catalog.

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 tool has zero parameters and the schema is already 100% covered by the empty properties object. The description appropriately adds no parameter details. Per the baseline for no-parameter tools, this is a 4.

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 resource (interactive Painto catalog) and explains the core action: customers check off goods and send them as an order or inquiry. It also distinguishes itself from siblings by calling out catalog, price list, and multi-item ordering use cases, which sets it apart from search, availability, and contact tools.

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 an explicit trigger condition: 'Use when someone asks for a catalog, price list, or wants to order multiple items at once.' This is clear context for when to invoke the tool. It does not explicitly name alternatives or state when not to use it, so it stops short of a 5.

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 at all, the description carries the full burden of behavioral disclosure. It discloses the data categories involved, but it does not explicitly state the operation (e.g., read-only lookup), the output form, or whether any side effects occur; these are only inferred from the informational nature of the content.

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?

A single compact sentence conveys all relevant categories without filler. It is front-loaded with the key term 'Kontakt' and organized with a dash and commas for readability.

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 zero-parameter, no-output-schema informational tool, the description is sufficient: it tells the agent exactly what kind of information will be found. Sibling tool names further disambiguate the context, and no input/output documentation is required.

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 tool has zero parameters and the input schema is empty, so the baseline is 4. No parameter documentation is needed because there are no inputs to describe.

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 identifies the resource as Painto.cz contact information and enumerates concrete contents: e-shop, physical store in Znojmo, phone, e-mail, invoicing data, and wholesale terms. It lacks an explicit action verb such as 'returns' or 'provides', so it stops short of the clearest possible definition, though the resource is clearly distinct from sibling tools like painto_doprava_platby or painto_sortiment.

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 listed data categories give an agent a clear context for when to select this tool: whenever contact, store, invoicing, or wholesale-condition information is requested. It does not explicitly name alternatives or state when not to use it, but the specificity of the content makes the usage scenario apparent.

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 must carry the behavioral disclosure. It discloses that the tool reports counts of products and stock availability, which is useful. However, it does not explicitly state that the operation is read-only, nor describe response format, latency, or any side effects. For a simple overview tool this is adequate but not richly transparent.

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 well-structured sentence that front-loads the main purpose, includes the specific metrics, and ends with a clear usage recommendation. No filler or redundant content.

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 zero-parameter tool with no output schema, the description fully explains what the tool does, what information it provides, and when to use it. The sibling tools are not needed to disambiguate because this tool's role as an assortment overview is self-contained. Nothing essential is missing.

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 tool has zero parameters, so parameter-level documentation is unnecessary. The schema confirms an empty parameter object, and the description adds the relevant context of what the output will summarize. The baseline of 4 for zero-parameter tools 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 the tool provides an overview of the e-shop assortment with two specific metrics: total products and in-stock products. It names the resource (Painto.cz assortment) and the scope (painting and construction tools), making the purpose understandable. It does not explicitly contrast with siblings, but the purpose is specific enough to stand on its own.

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 includes an explicit usage cue: 'Začni tímhle' (start with this) to learn what the shop offers. This gives clear context for when to call the tool. It does not mention when not to use it or name alternatives, but for a zero-parameter overview tool this is reasonably complete guidance.

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