FridgeBase (US)

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

Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile needs no repetition. The description repeats the 2-to-4 bound that the schema's minItems/maxItems already enforce, and adds 'side by side on the same criteria' without explaining what happens on invalid slugs or partial matches.

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 front-loaded sentence with no filler. The phrase 'from FridgeBase's comparison (slugs)' is slightly awkward packed mid-sentence, but nothing 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?

For a two-parameter read-only tool with no output schema, the description covers the core action but leaves the comparison result shape ('same criteria' is undefined) and slug sourcing unclear. Adequate but with noticeable gaps an agent would hit on first use.

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%: market is fully documented in-schema, while slugs has only min/max item constraints. The parenthetical '(slugs)' signals that slugs are FridgeBase comparison identifiers, which adds a little meaning beyond the bare array type, but the description does not clarify slug format or where to obtain them.

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?

Names a specific verb and resource ('Compare ... fridges') plus a scope (2 to 4, side by side on the same criteria) that distinguishes it from the sibling retrieval tools like get_model and search_models. It stops short of naming those siblings explicitly, so the differentiation is implied rather than spelled out.

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 2-to-4 cardinality hints at when the tool applies, but there is no explicit guidance on when to prefer this over calling get_model repeatedly, or what to do for a single model or more than four. Usage is implied rather than 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 declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds the useful detail that the response contains filter values, official data and an address, but labels like 'our data' and 'official data' are undefined, and the 'fridges' terminology risks confusing the agent about the resource type.

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 front-loaded sentence that identifies the resource and then lists contents; nothing is redundant. The parenthetical insertion and the comma-separated tail make it slightly harder to parse than necessary.

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 carry the return-value burden, and it does so only at a high level with vague labels ('our data', 'official data', 'its address'). For a simple single-record read with full safety annotations this is adequate, but an agent cannot predict the actual shape or field names of 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?

The description adds real meaning for the required id parameter by stating its provenance (an id returned by search). At 50% schema coverage, the remaining market parameter is fully documented in the schema itself (enum, default, per-market catalog explanation), so the description does not need to repeat it, but it also offers nothing about how market affects the returned content.

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 clear verb and resource: retrieves the full content of a single model identified by an id, enumerating the four content blocks returned (data, filter values, official data, address). It does not, however, distinguish itself from the sibling get_model, and the recurring use of 'fridges' for what the title calls a 'model' muddies what is actually being fetched.

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 parenthetical '(an id returned by search)' implies the search-then-fetch workflow, which is genuinely useful context. But there is no explicit statement of when to use this over get_model or search_models, and no exclusions or prerequisites beyond that hint.

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, closed-world and non-destructive behavior, so little is left to disclose on safety. The description adds that the response is the full record plus a page link, which is useful since there is no output schema, but it says nothing about what happens for unknown slugs or that the catalog is market-scoped.

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 sentence with the resource and key mechanism front-loaded; no filler. Slightly awkward phrasing ('one of the fridges in FridgeBase's comparison') but nothing 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?

For a simple two-parameter read tool with no output schema, the description covers what is fetched and that a page link is included. It is still incomplete on the market-scoping requirement and on not-found behavior, both of which an agent may need.

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%: 'market' is well documented in the schema (us/fr with Amazon domain and language), while 'slug' has no schema description at all. The description only restates that lookup is keyed by slug and does not explain its format or provenance, so it adds marginal value over 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 names a concrete resource and key ('All the data of one of the fridges ... by its slug') plus a return element ('the link to its page'), so an agent knows this is a single-model detail lookup. It does not name any sibling (search_models, compare_models, fetch), so the boundary with those tools is left implicit.

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?

'By its slug' implies the prerequisite (you must already have a slug, presumably from search_models) and the singular 'one of the fridges' implies detail retrieval rather than searching. There is no explicit when-to-use/when-not guidance and no mention of compare_models or search as alternatives.

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 the safety profile is covered. The description's contribution is describing the shape of the returned records, which is genuinely useful given there is no output schema, but it says nothing about whether results vary per market, ordering, or caching.

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 compact sentence with no filler, and the resource identity is front-loaded. The phrasing ('The filters of ... : key, label, ...') is slightly elliptical — it never states the verb 'returns' — but nothing 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?

For a one-parameter read-only metadata tool this is close to sufficient, and enumerating the returned fields compensates for the missing output schema. However, it never links the returned filters to the `market` parameter or explains how the output should be used with compare_models, leaving a small but real gap.

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 `market` parameter has a thorough enum description explaining us/Amazon.com vs fr/Amazon.fr and separate catalogs. The description adds no additional parameter meaning, 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 names a specific resource — the filter definitions used in FridgeBase's fridge comparison — and enumerates what each entry contains (key, label, possible values or range, unit, meaning). It is a noun phrase rather than a verb+object statement, so the agent must infer 'returns/list' from the title, but the resource is unambiguous and no sibling (search, get_model, compare_models, list_guides, fetch) does the same thing.

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?

There is no statement of when to call this versus the siblings. An agent gets no hint that this is a prerequisite/metadata lookup useful before calling compare_models or search_models, nor any exclusion. Usage must be inferred entirely from the resource name.

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 this is a read-only, idempotent, non-destructive, closed-world operation, so the safety profile is fully covered. The description adds only that results include an 'address', which is vague and does not clarify return format, pagination, or market-specific 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 a single front-loaded sentence with no wasted preamble. However, the trailing phrase 'with their address' is imprecise and does not clearly earn 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 simple one-parameter list tool with no output schema, the description is minimally adequate. It omits what a guide 'address' means, whether results differ by market, and any return-value details, leaving moderate gaps.

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 schema fully explains the single market parameter and its enum values. The description adds no parameter meaning beyond what the schema already provides, so this meets the baseline.

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: listing FridgeBase's buying guides for fridges. It differentiates from siblings like search_models or list_filters by naming a distinct resource, though the phrase 'with their address' is slightly ambiguous.

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?

There is no guidance on when to use this tool versus alternatives such as search, fetch, or list_filters. The description gives no context about prerequisites or exclusions.

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, idempotentHint=true and openWorldHint=false, so the safety profile is fully covered elsewhere. The description adds genuine context beyond that: it is a free-text search and it returns id, title and address. It stops short of describing result volume, pagination, or ordering, which are the remaining unknowns for a search 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?

One front-loaded sentence that opens with the action and then supplies scope and return fields. It is slightly overstuffed with nested parentheticals and duplicates the market definitions that the schema already carries, which is wasted effort for an agent that reads both.

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 two-parameter read tool with no output schema, the description usefully names the return fields, which offsets the missing output schema. However, it omits how results are ranked or capped and how it relates to the similarly named sibling 'search_models', leaving real gaps for an agent choosing between them.

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%: 'market' is fully documented in the schema (and the description merely repeats it, earning no extra credit), while 'query' has no schema description at all. The description partially compensates by labelling the query as free text, but it adds no detail on matching behavior, syntax, or what an empty/ambiguous query does.

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 ('search the fridges in FridgeBase's comparison') plus the two supported markets and the fields returned (id, title, address). It is clear what the tool does, but it never distinguishes itself from the sibling 'search_models', so an agent cannot tell the two apart from the description alone.

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?

Implies usage via 'free text' and the market enum, so an agent knows it is a keyword search over the fridge catalog. There is no explicit when-to-use guidance, no statement of when to prefer 'search_models' or 'get_model' instead, and no mention of prerequisites or result limits.

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 (read-only, idempotent, non-destructive, closed-world), so the description's job is to add context. It does add one genuinely useful fact: price and ratings are not returned but live on the model's site page, plus that each market has its own catalog. It says nothing about the 50-item cap, default result count, or what happens when filters match nothing.

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 dense sentence that front-loads the action and resource, then the markets, then the inputs, then the returns. It is slightly run-on in the trailing parenthetical, but every clause carries information.

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 usefully enumerates the returned fields and points out where price and ratings actually live. Given a 4-parameter tool with one nested object, the remaining gap is minor: no mention of pagination via limit or empty-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?

Schema coverage is 75%, so the baseline is 3. The description reinforces that query is free-text need and filters are exact, but largely restates the schema for market ('us = Amazon.com, in English') and adds nothing on limit semantics or the shape of nested filter values.

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 gives a specific verb and resource: search FridgeBase's fridge comparison catalog, with the two supported markets named explicitly. It is clear what the tool does, though it never names a sibling (compare_models, get_model, list_filters) to sharpen the boundary, so it is one step short of a 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?

Usage is implied through 'by need (free text) and exact filters,' which suggests a query-plus-facet search versus something narrower like list_filters. There is no explicit when-to-use or when-not, and no guidance on choosing between this and compare_models or get_model for downstream lookups.

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