catalog-feed

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds valuable context beyond annotations by clarifying that '24h' means shipment within 24 hours (not payment term) and that 'skarbiec CH' means release only to Loomis vault in Switzerland. This aids the agent in understanding the output semantics.

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 three sentences long with no fluff. It front-loads the status values immediately, then clarifies ambiguous terminology, and adds a caveat about 'skarbiec CH'. Every sentence adds essential information not available in the annotations or schema.

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 lists possible status values and explains their meanings, which is critical since there is no output schema. However, it does not specify the exact structure of the response (e.g., whether it's a string or an object), and it does not cover error conditions or edge cases (e.g., invalid SKU). Given the tool's simplicity, it is moderately complete but could be improved.

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%. The description does not mention either parameter ('sku' or 'waluta'). It does not explain what these parameters mean, how to use them, or any constraints. The agent receives no guidance on how to invoke the tool correctly apart from the raw schema definitions.

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 checks product availability (SKU) and enumerates the possible statuses: 'od ręki (24h)', 'na zamówienie (7-10 dni)', 'skarbiec CH'. The verb 'sprawdź dostępność' (check availability) combined with the resource 'produkt (SKU)' makes the purpose highly specific and distinct from sibling tools like get_live_price or get_product.

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 that this tool is used to check availability status of a product, but it does not explicitly state when to use it versus alternatives, nor does it provide exclusion criteria. No guidance on preferring this over search_products or get_product is given.

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?

Beyond the readOnly and idempotent annotations, the description discloses important behaviors: the price is approximate and bucket-based, independent of mint, dependent only on metal/type/weight, and not a binding offer. It also provides legal and informational limitations, which is valuable context an agent should know before presenting results to a user.

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 and then the key behavioral caveat, followed by legal disclaimers. The legal and disclaimer sentences add some length, but they are relevant for a financial pricing tool and do not obscure the operational content. Overall, it earns its place without excessive 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 tool with three optional parameters, clear annotations, and no output schema, the description is complete: it explains what the tool returns, how to invoke it with and without parameters, how the price model works, and what caveats apply. An agent has enough information to decide when and how to call it and what expectations to set with the user.

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 33%, so the description must compensate, and it does: it explains that metal, form, and weight drive the estimate, clarifies that all parameters are optional with no-parameter behavior returning the full price list, and describes how weight/type affect pricing. It does not enumerate the exact enum options, but those are self-descriptive from 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 states the specific purpose: it returns the buyback price IDFMETALE pays for gold or silver, and explicitly contrasts this with the sale price retrievable via get_live_price. It names the resource and the pricing perspective clearly, so an agent can distinguish it from sibling tools without inspecting 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 gives explicit usage guidance: provide metal, form, and weight to get an estimated valuation, or call with no parameters to receive the full buyback price list. It also names the alternative tool get_live_price for sale prices and explains when the tool's result is not binding, making selection straightforward.

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?

Beyond the readOnly/openWorld/idempotent annotations, the description discloses important behavioral traits: the price has a validity window, must be refetched after expiry, and the 24h term does not imply a price guarantee. This materially changes how an agent should use the result and is not visible from the schema or annotations.

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 core purpose is front-loaded in the first clause, and the subsequent sentences add valuable caveats without padding. The phrasing 'cena od (7-10 dni) i cena 24h jeśli od ręki' is slightly dense and colloquial, but overall the description is compact and well-ordered.

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 does a good job of listing the main returned information: current price, validity markers, and delivery cost. It does not describe the response shape, error cases for unknown SKUs or unsupported currencies, or the role of ilosc, leaving some gaps for an agent that needs to fully interpret the result.

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 description explicitly covers sku and waluta, explaining that the price is for a product SKU and in a chosen currency. However, it does not explain the ilosc parameter at all, and since schema description coverage is 0%, the description only partially compensates for the missing parameter semantics.

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 a product identified by SKU and the action as retrieving a current price in a selected currency. It also lists returned components such as validity timestamps and delivery cost, but it does not explicitly differentiate itself from siblings like get_buyback_price or get_product.

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 operational guidance: after cena_wazna_do the price is stale and must be refetched before showing to a customer, and a 24h payment term is not a price guarantee. It stops short of explicitly naming alternatives or saying when not to use this tool, so it loses the top score.

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 read-only, idempotent, non-destructive behavior. The description adds rich behavioral details: live price freshness (7-10 days), 24h price availability, delivery modes (e.g., exclusively to Loomis vault in CH), withdrawal right limitations, and VAT status. No contradictions with annotations.

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 well-structured with bullet points and complete sentences. Every sentence adds value, covering data fields, delivery nuances, legal disclaimers, and process notes. No unnecessary 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?

Given no output schema, the description thoroughly details the expected return data. It includes regulatory and process notes (KYC, withdrawal rights). However, it does not explicitly guide the agent on when to choose this tool over siblings, slightly reducing completeness.

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 50%: 'ref' parameter is described with examples, but 'waluta' parameter only has enum values without a description. The description does not explicitly explain the 'waluta' parameter, leaving it partially undocumented.

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 retrieves full product data by SKU or handle, listing specific attributes included (metal, shape, weight, mint, accreditation, live price, etc.). It distinguishes itself from sibling tools like check_availability and get_live_price by offering comprehensive data.

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 explains when to use this tool (to get full product details) and includes important context like the agent not finalizing purchases and KYC requirements. However, it does not explicitly state when not to use it or compare with siblings, leaving some ambiguity.

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, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds minor behavioral context by specifying that the result is separated into mints and accreditations, which does not contradict annotations.

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 that is front-loaded and to the point. Every word is necessary, with no redundancy or 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?

For a simple listing tool with no parameters and no output schema, the description adequately conveys what is returned (mints and accreditations, separated). However, it could additionally clarify the structure (e.g., two arrays) or mention if the list is paginated.

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, and the input schema coverage is 100%. The description adds no parameter details, but the baseline for 0 parameters is 4. No additional information is needed.

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 list of mints (producers) and accreditations (e.g., LBMA), using a specific verb ('Zwraca') and resource. It is distinct from sibling tools like list_categories or search_products, which have different purposes.

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 no guidance on when to use this tool versus alternatives. It does not mention context, exclusions, or prerequisites, leaving the agent to infer usage solely from the tool name and title.

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, idempotentHint, and destructiveHint false, which fully describe the behavioral traits. The description adds minor context by mentioning the returned fields (handle + name), but does not significantly extend beyond the annotations.

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 with no unnecessary words. It is front-loaded with the core purpose. However, it could be organized slightly better with more structured information, but it is sufficiently concise.

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 simplicity of the tool (no parameters, no output schema), the description is minimally adequate. It hints at output fields but does not specify ordering, pagination, or whether the list is exhaustive. For a simple list tool, this is acceptable but lacks some completeness.

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 no parameters, and schema coverage is 100%. Baseline for zero parameters is 4. The description does not need to add parameter semantics, but it also does not provide any additional details about parameter behavior.

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 that the tool lists product categories and includes fields 'handle' and 'nazwa'. The verb 'list' and resource 'categories' are specific. It is distinct from sibling tools like 'list_brands' and 'search_products', but no explicit differentiation is provided.

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 guidance on when to use this tool versus alternatives. There are no prerequisites or context for when listing categories is appropriate. The description relies on the name and title to imply usage.

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 signal read-only, idempotent, non-destructive behavior. The description adds useful behavioral boundaries: this is source material rather than guidance, and it deliberately does not answer individual, tax, or AML questions. It does not disclose output formatting or offset behavior, but the annotation coverage lowers the burden.

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, front-loaded with the core content scope, and every sentence adds value. The list format and two short caveats are easy to parse and free of 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 read-only retrieval tool, the description covers what content is returned and what the tool will not answer. No output schema exists, so a bit more return-format detail would help, and 'offset' semantics remain unexplained, but the overall picture is sufficient for basic correct 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?

The schema already documents the main 'page' parameter well, including slug/URL forms and exclusions. The description adds general topic context but does not clarify the 'offset' parameter, which is left undocumented at 50% schema coverage. No parameter information is repeated or contradicted.

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 (public IDF page content) and lists specific content categories: delivery, contact, how to buy, and purchase rules. It avoids tautology, though it does not explicitly name sibling tools to differentiate itself from search_knowledge.

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 scope and explicit exclusions: it provides source data, not instructions, and does not handle individual cases, taxes, or AML. It does not name alternative tools, but the exclusions are concrete enough to prevent common misuses.

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?

Beyond the readOnlyHint, openWorldHint, and idempotentHint annotations, the description discloses that the tool returns only titles and links rather than article bodies, that the content is informational and educational, and that it does not provide investment advice or price forecasts. This is useful behavioral context and does not contradict the annotations.

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 content types and topics, followed by return behavior and the legal disclaimer. It is slightly longer than necessary, but the disclaimer is important for a tool touching investment-related information, so the length is justified.

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 what the tool searches, what it returns, and its limitations, which is adequate for a simple search tool. However, with no output schema and only 33% schema coverage, the missing explanation of typ and limit leaves the calling contract partially underspecified and relies on enum names and the query parameter description alone.

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 33%, with only the query parameter described, and the description does not explain the typ enum or the limit parameter. The listed topics loosely map to some typ values but the mapping is implicit, so an agent gets insufficient guidance for constructing well-formed calls beyond a free-text query.

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 as a knowledge-base search over guides, FAQ entries, glossary terms, and IDFMETALE articles about investment metals, and states that it returns titles and page addresses. It is distinguishable from product/price siblings by its focus on educational content, though it never names a specific sibling or states 'search for knowledge articles' explicitly.

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 gives concrete topics such as taxes/VAT, storage, buyback, mints/LBMA accreditation, branches, and how to buy, which signal when to use the tool. It does not explicitly say when not to use it or name alternatives such as search_products, but the knowledge-base framing makes the intended context clear.

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?

Beyond the annotations (readOnlyHint, idempotentHint, openWorldHint), the description discloses several non-obvious behaviors: only products with complete data are returned, results are factually sorted by price rather than ranked, purchase completion requires KYC/AML, the agent never finalizes transactions, and IDFMETALE makes no price forecasts. This goes well beyond what the annotations alone communicate.

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 dense paragraph, front-loaded with the search purpose and then followed by operational and compliance caveats. It is slightly long, but every sentence earns its place given the financial/AML context; the disclaimer sentences could be compressed but are not redundant.

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 must explain return semantics, but it only vaguely says it returns 'structured attributes + live from-price and availability.' It also omits details about limit/pagination, default currency, and exact result shape. It does cover important edge behavior like complete-data-only and no future-price promises, but not enough to fully compensate for the missing output schema on a 10-parameter 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?

With only 30% schema description coverage, the description partially compensates by listing filter dimensions and clarifying that the text query narrows results rather than ranks relevance. However, it claims a 'próba' (fineness) filter and a price 'range' that are not fully represented in the schema (there is no próba field and only cena_max, no cena_min), which can mislead an agent. It also leaves limit, waluta, and dostepnosc semantics mostly implicit.

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 identifies a specific resource (the IDFMETALE investment-metals catalog) and describes a distinct filterable search behavior: filtering by metal, form, mint, mass, and price, and returning structured attributes plus live price and availability. This clearly separates it from sibling tools like get_product, get_live_price, and check_availability, even without naming them.

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 usage context: it is the catalog search endpoint, returns only complete data, and sorts by ascending price rather than relevance. It also provides explicit boundaries — the agent must not finalize transactions, KYC verification is required, and the data is not investment advice. It does not explicitly route to sibling tools, but the search-vs-single-record distinction is strong enough.

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