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

With no annotations provided, the description carries the full burden. It discloses the kg/l-only basis constraint and the reason (per-piece prices cannot be ranked), which is meaningful behavioral context. It partially covers limit behavior implicitly but doesn't discuss rate limits, auth, or grouping behavior in detail.

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, all earning their place. The description front-loads the primary purpose, then adds the critical constraint and the category-omission tip in a compact, efficient structure. Zero 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?

The tool has 5 parameters, no annotations, and no output schema, so the description must carry a lot. It clearly states purpose, ranking basis, and category behavior. However, with no output schema and 0% schema coverage, some gap remains for week/limit/per_ingredient semantics and return-form behavior, making it slightly incomplete for a complex ranked-list 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?

Schema description coverage is 0%, so the description must compensate for the 5 undocumented parameters. It explains `category` (omitting compares across all categories) and clarifies the `basis` constraint (only kg/l). However, `week`, `limit`, and `per_ingredient` semantics are not explained beyond their 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?

Description clearly states 'cheapest offers per ingredient, grouped and ranked by unit price' — specific verb (compare/rank), resource (ingredients), and scope. It distinguishes itself from siblings by describing the ranking-by-unit-price mechanism. Clearly the primary meal-planning entry point.

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 states when to use: 'primary meal-planning entry point'. Provides concrete exclusion: 'Only kg and l bases are included, because per-piece prices cannot be ranked against them.' Gives clear guidance on omitting category to compare across all categories. This differentiates it from search_offers and other siblings.

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 description provides critical behavioral disclosure by distinguishing two data fields: `discount_pct` (retailer's own claim) vs `vs_baseline_pct` (the tool's inference). It explicitly warns not to present the second as the retailer's claim. With no annotations provided, the description carries the full burden, and it does this exceptionally well by warning about a subtle data provenance pitfall.

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 with the core purpose ('Price one ingredient across every chain this week, with a baseline from earlier weeks'). It then adds essential field-disambiguation context. The warning clause is valuable but slightly wordy; could tighten 'is null for most offers' phrasing, but overall efficient.

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 only 2 parameters, no output schema, and no annotations, the description covers the essential aspects: what the tool does, temporal scope, and the critical dual-field semantics with a correctness warning. It's complete for an agent to correctly select and use the tool for this purpose.

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% (only `ingredient` has a description). The description meaningfully adds to parameter understanding by explaining the two computed fields (`discount_pct`, `vs_baseline_pct`) in the output, which relate to how results should be interpreted. However, it doesn't clarify `week` format/behavior beyond what the schema lacks.

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 specific verbs ('Price', 'Compare') plus the resource ('ingredient') and clear scope ('across every chain this week', 'baseline from earlier weeks'). It distinguishes from siblings by emphasizing the cross-chain comparison aspect, though it doesn't explicitly name alternatives.

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 usage context (weekly cross-chain pricing with historical baseline) but doesn't explicitly state when to use it vs price_history (which likely covers the historical angle) or cheapest_by_category (similar comparison but by category). No explicit exclusions or alternatives are named.

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 burden of behavioral disclosure. It does some work: it clarifies that pricing is chain-national (not per-store), which is a meaningful limitation the agent should know. However, it doesn't disclose what the tool returns (list of store objects?), whether it's a read-only operation, rate limits, or behavior with no stores in range. For a read-oriented lookup tool with zero annotations, it adds value but could deepen the behavioral picture.

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 zero waste. The first sentence states purpose and ordering; the second adds the key pricing limitation and the intended use case. Every word earns its place, and the tool name is not tautologically restated.

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?

This is a moderately simple tool with 5 params, no output schema, and no annotations. The description covers the core purpose and the main data limitation, but for a geospatial lookup with no output schema, the agent gains no information about the return shape (store names? distances? opening hours?) or what non-coordinate interactions look like (chain omitted behavior). Given the complexity (coordinate queries, radius, limit) and absence of output schema, additional description of the response would improve 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 description coverage is 0%, so the description must compensate for 5 undocumented parameters. The description helps marginally by implying the 'chain' param exists ('for a chain whose offer you already picked') and that coordinates are key. However, 'limit', 'radius_m', and the exact semantics of 'chain' (is it optional? what format?) are not explained in the prose, leaving the agent to infer from names and constraints alone.

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+resource ('Grocery stores near a coordinate'), and notably clarifies the scope ('nearest first', 'chain-national — no per-store pricing'). It distinguishes from siblings by explaining this answers 'which shop do I go to' rather than price comparison. However, it doesn't explicitly name sibling alternatives like search_offers or cheapest_by_category, so differentiation is implicit rather than explicit.

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 articulates a clear use case: answering which store to visit for a chain whose offer is already selected, and explains the limitation (chain-national pricing, no per-store). This provides strong context for when to use it. However, it doesn't explicitly state when NOT to use it or name alternative tools for per-store pricing/price comparison scenarios, leaving exclusion guidance implicit.

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 of behavioral disclosure. It reveals the output contains 'offer counts,' 'usable unit price' counts, and 'ingredient tag' counts, but doesn't disclose whether this is a read-only operation, how stale the data might be, what 'this week' means relative to the optional week parameter, or return format/pagination. For a seemingly non-destructive read tool with no annotation coverage, the description gives some content context but omits behavioral 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?

Two sentences, each earning its place: the first specifies content, the second gives usage purpose. No filler, no redundancy, appropriately front-loaded with the core purpose. This is a model of concise structuring.

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 there's no output schema, no annotations, and one ambiguous optional parameter, the description should carry more burden. It touches on what the output contains (counts) but doesn't explain the week parameter semantics, how 'usable unit price' and 'ingredient tag' are defined, or how results might be ordered/filtered. For a coverage-overview tool alongside 6 siblings, more detail on how results relate to the broader toolset would improve 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 is one parameter (week) with 0% schema description coverage, and the description mentions 'this week's offer counts' which implies the week parameter affects the data window. However, the description doesn't clarify the expected format of the week value (ISO date, week number, date range) or what happens when it's omitted versus provided. The description adds modest meaning beyond the bare schema but leaves the week parameter's format and optionality semantics ambiguous.

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 clear verb-resource pair ('List covered chains') and specifies the content scope: this week's offer counts, usable unit price counts, and ingredient tag counts. It distinguishes itself from siblings by the 'coverage' focus (which chains a meal plan can rely on), contrasting with siblings like search_offers or price_history. However, it doesn't explicitly name sibling alternatives or define what 'covered' precisely means against the set of available chains.

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 a clear usage context ('Use it to see what coverage a meal plan can rely on'), implying it's a planning-level overview tool rather than a specific search. However, it doesn't give explicit when-to-use vs. when-not-to-use guidance or name alternatives like search_offers or cheapest_by_category for more targeted queries. No exclusions or explicit comparison to siblings.

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 burden of behavioral disclosure, and it does reasonably well: it discloses that history is limited to how far back this installation has been syncing, which is a genuine data-availability caveat. It also clarifies the aggregation (cheapest unit price per week), which is meaningful behavioral detail. It doesn't mention pagination, return format structure, or error behavior, but the key caveat is disclosed.

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, zero waste. The first sentence states function and granularity; the second adds a critically useful data-availability caveat. 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?

For a relatively simple two-parameter tool with no output schema and no annotations, the description is largely complete: function, granularity, purpose, and data caveat are all present. Minor gaps exist around what the output columns/rows look like and whether chain is optional (schema shows not required), but these aren't critical for a read-only price-history 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 description coverage is 0%, so the description must compensate for both params. It explains the ingredient param contextually ('for one ingredient') and that chain is a filter ('per chain'), giving meaning beyond the bare schema. It doesn't explicitly spell out parameter formats, but the natural-language usage conveys the semantics adequately.

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+resource construct: it explains the tool returns the cheapest unit price per week per chain for one ingredient. It clearly distinguishes what it does from a generic 'price lookup' by specifying granularity (weekly, per chain, unit price), and its purpose (judging whether a tilbud is genuinely good). This clearly distinguishes it from siblings like search_offers and compare_ingredient.

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 on when to use: to judge whether a discounted price is genuinely good. It implies historical/reference comparison use. However, it doesn't explicitly mention when NOT to use it or name alternative tools (e.g., use compare_ingredient for direct comparisons), so it stops short of 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, the description carries the full burden and does well: it discloses that unit prices are not always comparable across basis units (kr/kg vs kr/stk), that 'computed' confidence means unverified against the flyer, that results sort cheapest-first, and that priced_only defaults to true (hiding unpriced offers). This is meaningful behavioral context beyond the bare schema.

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, zero filler. Every sentence adds distinct value: what it searches, how it sorts, and the two critical interpretation caveats. Front-loaded with the purpose, caveats appended as the essential reading guidance.

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 10-parameter no-output-schema search tool, the description covers the key behavioral hazards (unit comparability, confidence status, sorting, pricing filter default). It doesn't enumerate each filter's semantics, but the critical correctness risks are addressed. With no output schema, the description adequately orients the agent on what to expect and how to interpret results.

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%, with several parameters (basis, category, limit, priced_only, max_unit_price, min_discount_pct) lacking descriptions in the schema. The description partially compensates by explaining the basis-unit comparability caveat, but does not individually clarify basis, category enum semantics, or limit behavior. The most behaviorally critical caveat (unit_price_basis pairing) is covered in prose, adding real value.

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 ('Search') with a clear resource ('this week's Norwegian grocery offers'), and explains matching behavior. It distinguishes itself from siblings by explicitly noting free-text matching on product heading plus filtering, and its cheapest-first sorting.

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 the matching/filtering behavior and sorting. It gives clear guidance on interpreting unit_price with unit_price_basis and treating computed confidence as unchecked. It doesn't explicitly state when NOT to use it vs alternatives like cheapest_by_category or compare_ingredient, but the search-orientation is 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?

No annotations are provided, so the description carries the burden. It explains the refresh behavior (re-fetch from upstream API) and the auto-trigger condition (missing current week). It also implies a network/upstream dependency without spelling out failure modes, but for a zero-param sync tool this is reasonable context.

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, zero waste. Front-loaded with the primary action, then the pragmatic guidance about rarity of use and the mid-week use case.

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-param, no-output-schema tool, the description is complete: it states what it does, when it's needed, and when it isn't. It could mention rate-limit or cost implications but these are minor gaps for a simple refresh action.

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 0 parameters, so schema coverage is trivially 100%. The description explains there's nothing to configure, which meaningfully clarifies that the call is side-effect-only and requires no input.

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 specific verb+resource ('Re-fetch current flyers from the upstream API'), distinguishing it from the sibling tools which are all query/search operations. It's unambiguous what this tool does.

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?

Excellent guidance: explicitly states it runs automatically when the current week is missing, 'so you rarely need to call it', and tells when to use it ('pick up a mid-week update'). This contrasts clearly with the sibling search/query tools.

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