Moja Serowarnia: kultury i przepisy na sery

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely non-obvious behavior: the tool never hard-fails on an unknown name but returns the closest matching names, and the return payload includes shop offers with price per liter and product links. Missing only finer points such as match tolerance or result ordering.

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?

Front-loaded with the core purpose, then the field inventory, then the fallback caveat — a logical order with no filler. The long enumeration of returned fields is dense but each item is informative for an agent with no output schema; a bulleted form would read slightly better.

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 fully absorbs the burden by listing the returned card fields (composition by species, application, temperature, dosage, producer, strain proportions, shop offers with price and link). It also covers the input source and the not-found behavior, leaving nothing an agent needs in order to call 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 100% and the schema already says the value is a trade name from the packaging or from szukaj_kultur. The description contributes mainly illustrative format examples (mixed alphanumeric codes), which is mild added value rather than new semantics — baseline 3 applies when the schema carries the 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?

States a specific resource ('pełna karta jednej kultury') and the key it is fetched by ('po nazwie handlowej'), then enumerates exactly what the card contains. The concrete example names ("Choozit MA 4001", "ALPHA 10", "DELTA 2") make it easy to distinguish from search-oriented siblings like szukaj_kultur, which returns candidate names rather than a full card.

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 right context — you already have a trade name from packaging or from szukaj_kultur — and explicitly handles the negative case ('Gdy nazwy nie ma, zwraca najbliższe nazwy'), so an agent knows a miss is not fatal. It stops short of naming a sibling tool or an exclusion rule directly in the description text (that hint lives only in the parameter schema).

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 readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds behavior the annotations do not: it is a one-shot metadata read intended to be called once, and it enumerates what information it surfaces. It does not describe the return shape, which keeps it from 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?

Two sentences, no filler. The content enumeration comes first and the invocation advice is second, which is the right ordering for an agent deciding whether to call it now.

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, rich annotations and no output schema, the description covers what an agent needs to decide to call it. The only residual gap is that it never hints at the response format (structured vs. prose), which would matter for a tool with no output schema.

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 takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter guidance is needed or missing.

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 concrete resource (database metadata) and enumerates its contents: number of cultures and stores, types, price-verification date, license, citation format. The opaque name 'o_bazie' is rescued by the title and this enumeration. It does not explicitly contrast itself with the query-oriented siblings, so it lands at 4 rather than 5.

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?

'Warto wywołać raz, zanim przedstawisz bazę użytkownikowi' gives a clear timing and cardinality rule (once, before presenting the database). No exclusions or named alternatives, but the siblings are all data-lookup tools whose purpose is self-evidently different.

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 cover read-only, idempotent, local-database, and non-destructive behavior, so the description focuses on disclosing return content: full recipe sections plus database-matched cultures with shop, price, price per liter, and card link, plus optional 'dziennik warzeń' when present. This conditional availability and the mixing of recipe data with joined commerce data is genuinely useful context the annotations do not provide.

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 dense, front-loaded sentence that opens with the resource and scope before listing contents. The enumeration of recipe sections is long but each item conveys what the agent will receive, so it earns its space despite being a single run-on sentence.

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?

There is no output schema, so the description carries the full burden of describing return values — and it does so thoroughly, covering recipe sections, joined culture data, and the optional author batch log. Nothing an agent needs in order to call this correctly appears to be 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?

Schema coverage is 100%, so the single 'nazwa' parameter is already documented as 'name or id from szukaj_przepisow results'. The description repeats that dual name/id acceptance and adds example values ('mozzarella', 'gouda', 'ser topiony'), which helps slightly but stays at the baseline for a fully documented 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 clearly states it returns a complete recipe for a specific cheese by name or id, and enumerates the contents (milk, starter culture, coagulant, dosing, steps, salting, aging, tips). It does not explicitly name the sibling search tool (szukaj_przepisow), so differentiation is only implicit through the word 'Pełny' and the id reference.

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 implies the tool is used when you already have a specific cheese name or id, but it never says when to use this versus szukaj_przepisow or szukaj_kultur, nor any prerequisites. Usage is inferable from the phrase 'po nazwie albo id' but not 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds non-obvious behavior: the returned field set (name, type, application, temperature, shop, price, price per litre, card link) and the strict per-word AND matching across name/application/type/composition. It stops short of covering empty-result behavior or how relevance ordering ('trafnosc') is computed.

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?

Three sentences, front-loaded with the search target and examples before the filter list and the matching rule. The return-field enumeration is somewhat listy but pulls double duty since there is no output schema. Slight redundancy with the schema's own example values ("camembert", "twaróg") is the only waste.

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 steps in and enumerates the return fields, and it documents the non-obvious matching semantics and filtering behavior for a six-parameter tool. An agent has everything needed to construct a correct multi-filter query and interpret the response.

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 100%, so baseline is 3, but the description genuinely adds meaning the schema does not: a multi-word 'zapytanie' must match on every word across name, application, type or composition — including 'skład', which is not even a filter parameter. That clarifies how zapytanie behaves together with the typ/temperatura filters, beyond the schema's example list.

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 and resource ('Szuka kultur') and immediately narrows the domain to cheese/yogurt/kefir/twarog cultures with concrete example queries ("camembert", "twaróg", "mozzarella"). This makes it trivially separable from siblings like kultura or szukaj_dodatkow, which are single-item lookup and additive search respectively.

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 clearly establishes the use case: free-text search by cheese name or application, optionally narrowed by type, working temperature and shop. The matching rule ('Każde słowo zapytania musi wystąpić w nazwie, zastosowaniu, typie albo składzie') tells an agent how to phrase queries, which is real usage guidance. It does not, however, name an alternative or say when to prefer a sibling tool over this one.

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 readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real context beyond them: it enumerates the returned fields (nazwa, trudność, wydajność, czas dojrzewania, opis, link) and states the no-query default, which is exactly the lightweight-summary behavior an agent needs to know.

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?

Three sentences, each doing work: purpose, no-query behavior, return shape plus sibling hand-off. Nothing is repeated and the most important disambiguation is 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 output schema, the description correctly compensates by listing the returned fields, and it explains the optional-parameter default. For a 3-parameter read-only search tool, an agent has everything needed to call 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 100%, so the baseline is 3; the description earns an extra point by widening the meaning of 'zapytanie' beyond the schema examples to attribute-style queries ('z mleka koziego', 'ser pleśniowy') and by explaining the empty-query case. The limit/trudność parameters are only covered by the schema, but those are self-explanatory.

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 and resource ('Szuka przepisów na domowe sery') plus the search axis (nazwa sera albo cecha), and explicitly distinguishes itself from the sibling tool 'przepis' which returns the full recipe. An agent can pick between the two without opening any 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?

Gives a concrete usage rule ('Bez zapytania zwraca wszystkie przepisy') and routes the agent to 'przepis' when cultures and shops are needed. It does not address the other siblings (szukaj_kultur, zamienniki, dobierz_proporcje), but the boundary that matters most here is 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?

Beyond annotations (readOnly, idempotent, non-destructive, closed-world), the description discloses three non-obvious behaviors: results are sorted by price per litre, the response flags groups that mix different applications or different strain ratios, and the output carries a disclaimer the agent must relay to the user. That last point is a genuine consumption instruction not available anywhere in the structured fields.

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?

Three tight sentences: what is returned and in what order first, then the flagging behavior, then the disclaimer obligation. Nothing is redundant and the key constraint is 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 output schema present, the description does a good job of describing what the result contains (ranked alternatives plus caveats). It leaves the exact shape of an entry — fields, whether prices or links are included — implicit, which is the only remaining gap for a one-parameter lookup.

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 100% and the single parameter 'nazwa' is already documented in the schema as the trade name to find a substitute for. The description adds no format, matching, or fallback guidance beyond it, so the baseline 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 states precisely what the tool returns: cultures with identical species composition to the given one, ordered from cheapest per litre of milk. That is far more specific than the name 'zamienniki' alone and separates it from the search/recipe siblings. It stops short of naming which sibling to use instead (e.g. szukaj_kultur), so it is clear but not fully differentiated.

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 cost-per-litre ordering makes the intended scenario obvious: the user has a named culture and wants a cheaper equivalent, not a general search. There are no explicit exclusions or named alternatives, so the agent must infer when to prefer szukaj_kultur instead.

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