VanAuto Campers

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

Annotations already cover readOnly/openWorld/idempotent, so the bar is lower, and the description adds real value: it discloses the shape of the returned statistics, the cohort-comparison behavior triggered by slug (percentile and deviation from median), and implies a sampling cap. It does not explain behavior on an empty or tiny cohort, which would be useful for a statistics 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?

Three tight sentences with no filler: the output shape is front-loaded, the optional comparison mode follows, and the intended question is last. Every sentence carries information an agent needs.

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 still enumerates the return contents, and all 12 parameters are documented in the schema itself. Minor gaps remain around cohort edge cases (empty results, how maxSample affects reliability) and how this differs from the market-stats sibling.

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, but the description meaningfully extends the slug parameter by stating that it yields a percentile and deviation from the median rather than merely being 'a listing to compare'. The other eleven parameters are left entirely to the schema, but the schema is thorough.

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 ('Market price statistics for a cohort of active sale listings') and enumerates the exact statistics produced (min, max, average, median, p25/p75, counts, average by year), so an agent knows precisely what comes back. It does not, however, distinguish itself from the sibling get_camper_market_stats, whose name suggests overlapping scope.

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 a clear usage context ('Use this to answer "is this a good price?"') and describes the optional slug comparison path, which tells the agent when to supply slug versus when to omit it. It stops short of naming alternatives or stating when not to use this tool versus get_camper_market_stats.

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 declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, covering the safety and idempotency profile. The description adds that results are 'compact rows' and 'the alternatives the platform suggests,' which provides some output context, but it does not elaborate on rate limits, authentication needs, or any other behavioral traits 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, front-loaded sentence that efficiently conveys the tool's purpose and output format without any superfluous 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?

Given the simple schema (2 parameters, high coverage) and the presence of annotations, the description is mostly complete. It could mention that the results are based on the platform's suggestion algorithm, but for a read-only retrieval tool, it covers the essential aspects.

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%, so both parameters ('slug' and 'limit') are fully documented in the schema. The description does not add any parameter-specific details; baseline 3 is appropriate since the schema carries the 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 states a specific verb ('Find') and resource ('sale listings similar to a given one'), and it clarifies the similarity criteria (same market segment, price bracket and specs). This distinguishes it from sibling tools like search_campers or get_camper_details, which serve 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 implies usage when one has a listing and wants alternatives, but it does not explicitly state when to use this tool versus similar siblings such as search_campers. No exclusions or alternatives are mentioned, leaving the agent to infer.

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 as a read-only, idempotent, open-world read, so the safety profile is covered. The description adds non-obvious behavior — slug resolution searches sale listings first then rentals, and camper_id pulls from the full catalog spec sheet — which is genuine context 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 three sentences are front-loaded with the primary action, then resolution behavior, then output content — each earns its place. Slightly dense but no filler.

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 7 parameters and no output schema, the description does the heavy lifting by summarizing what is returned (decoded specs, photo URLs, equipment, contact details, listing URL) and the includePhotos behavior. It is close to complete for the tool's complexity, though it doesn't note any rate or permission constraints (unneeded for a read-only 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%, so the baseline is 3, but the description adds interpretive value: it clarifies the slug/segment interplay and that includePhotos causes actual images to be attached for viewing. It notes the returned field groups (specs, photos, equipment, contact, URL), reinforcing what the parameters yield.

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+resource ("Get full details for one camper listing") and immediately distinguishes the two lookup modes (slug vs camper_id) so an agent can tell it apart from sibling tools like search_campers or get_marketplace_listing_details.

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 explains the resolution behavior for each identifier type and when to override with segment ("set segment to force 'sale' or 'rental'"), which gives clear context for choosing inputs. It stops short of naming which sibling tool to prefer over this one, so it lacks an explicit alternative-routing statement.

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 openWorldHint, so the safety and repeatability profile is covered. The description adds value by specifying the snapshot's contents, but says nothing about freshness/refresh cadence, caching, rate limits, or whether counts are scoped globally or to a region.

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 that front-loads the resource ('Current VanAuto market snapshot') and then lists the payload in a readable colon-delimited series. No filler, though the sentence fragment style omits any framing verb.

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, no output schema, and annotations covering the safety profile, the remaining burden on the description is to say what comes back — which it does by enumerating counts, body-type breakdowns, and makes with inventory. Only the freshness/scope of the snapshot is left unspecified.

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 no parameter semantics to clarify and the baseline of 4 applies. Nothing in the description misrepresents or over-constrains inputs.

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 verb+resource (market snapshot) and enumerates the exact aggregates returned: active sale/rental listing counts, campers by body type, makes with inventory. It is clearly distinguishable from list-style siblings like list_camper_makes or search_campers, though it never explicitly names an alternative to route against.

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 rather than stated: the word 'Current' signals a live overview snapshot, which suggests calling it for high-level market context before drilling into specific listings. No when-not conditions, prerequisites, or named alternatives (e.g., analyze_camper_prices) are 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?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description usefully adds that related offers and the seller's other listings are optionally bundled, but says nothing about auth requirements, rate limits, or what happens when a slug is missing/invalid.

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 tight sentences with the identifying verb/resource and the slug selector front-loaded, followed by the return payload. No filler, no repetition of the title, no wasted clauses.

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 carries the burden of describing the return payload and does so by enumerating the field groups returned. It is nearly complete for a read tool whose annotations already cover safety; only edge-case behavior (invalid slug, truncation interaction) is unaddressed.

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%, so all three parameters (slug, includeRelated, maxDescriptionChars) are already self-documenting. The description echoes slug and the optional-related behavior but adds no syntax, format, or default guidance beyond the schema, 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?

States a specific verb (get) and resource (marketplace listing details) and enumerates the fields returned — price, condition, shipping, compatibility, seller, photos, links. The singular 'by slug' implicitly separates it from the search-oriented sibling search_marketplace_listings, but no sibling is named outright.

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 only implied: the schema says the slug comes 'from search results', which suggests you call this after a search, but the description itself gives no when-to-use, when-not-to-use, or alternative-tool guidance versus get_marketplace_seller or search_marketplace_listings.

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 openWorldHint, so the safety profile is covered. The description adds the returned field categories but no extra behavioral context such as auth requirements or how includeListings interacts with the returned offers.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single compact sentence with the resource and its key fields front-loaded; every element is relevant. Slightly dense but no wasted filler.

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 carries the burden of describing return values and does so by listing the field categories. It is complete enough for an agent to call the tool correctly, though it omits error/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 description coverage is 100%, so both parameters (sellerId format example and includeListings default) are already fully documented in the schema. The description's mention of 'active offers' only loosely maps to includeListings and adds no syntax or format detail.

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 ('Marketplace seller profile by id') and enumerates the returned content (display name, verification and trust badges, ratings, offers). It does not explicitly contrast with the closely related sibling get_marketplace_listing_details, so it falls 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 only implied: the parenthetical '(from a marketplace listing's seller)' tells the agent where the id originates, but there is no explicit when-to-use or when-to-prefer-an-alternative guidance. Adequate but with a clear gap.

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 openWorldHint, so safety is covered. The description still adds real behavioral context: only published reviews are returned, and the payload contains ratings and review text — important since there is no output 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 short sentences, zero filler, with the resource and scope stated first and the exclusion last. Every sentence carries distinct information (what it returns, where the id comes from, what it excludes).

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 characterizes the return content (ratings and review text). It covers scope, id provenance, and return shape; only minor details like pagination behavior or review ordering are unaddressed, and the limit bound is already in the 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?

Schema description coverage is 100% and the schema already documents both parameters, including the 'rls_...' example that the description repeats. The description adds no new meaning for the limit parameter or the id format beyond what the schema states, 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?

States a specific verb and resource: retrieving published customer reviews for a rental listing. It also draws a scope boundary ('Sale listings do not have reviews') that separates it from the marketplace/camper siblings. It stops short of naming a sibling tool directly, so it is clear but not maximally 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?

It tells the agent where the required id comes from ('id from search results') and when the tool does not apply ('Sale listings do not have reviews'), which is useful implied usage guidance. However, no alternative tool is named for the sale-listing case, so the routing is left to inference.

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 openWorldHint, so the safety profile is covered. The description contributes beyond them by disclosing the return shape (grouped by category) and the semantics of the returned strings (English identifiers reused in filters and specs) — valuable since there is no output schema. It does not mention pagination or catalog stability, which keeps it short of 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, with the core purpose front-loaded and the identifier-format note second. Every clause carries information for an agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, no-output-schema tool, the description supplies the essential missing piece: what comes back (catalog grouped by category) and what the entries mean. Only secondary details like size of the catalog or pagination behavior are absent.

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 declares zero parameters, so per the rubric the baseline is 4. The description correctly implies a no-argument call and adds no conflicting parameter expectations.

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 ('List the camper equipment catalog') and adds the grouping structure ('grouped by category'). The resource ('equipment') cleanly separates it from the analogous sibling list_camper_makes without needing to name it.

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 explicit when-to-use or when-not-to-use statement. The clause 'Equipment names are English identifiers used in listing filters and camper specs' implies the tool is the lookup source for valid filter values, which is useful but left for the agent to infer rather than stated as guidance.

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 and openWorld, so the safety profile is covered structurally. The description adds that the data is a reference set 'known to VanAuto' and that results carry listing counts, but it says nothing about result volume, truncation at the limit boundary, or the fact that counts are live. Adequate but not rich.

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, with the core scope stated first and the intended workflow second. Every clause 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 two-parameter, no-output-schema lookup tool with full annotation coverage, the description conveys purpose, return content (makes plus counts), and usage intent. The only gap is that nothing hints at pagination or result-set size against the 250 maximum, which is minor here.

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%, so the baseline is 3: both 'limit' and 'query' are already documented in the schema, and the description adds no syntax, defaults, or filtering nuance beyond it. The example filter in the schema ('ben' for Benimar) is not echoed or extended in the description.

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+resource ('List camper makes (brands)') and enriches it with what each entry contains (active sale and rental listing counts). It is clearly distinguishable from siblings like search_campers or get_camper_details, though it never explicitly names a sibling to contrast against.

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?

'Use this to resolve a brand name before searching' establishes a clear context for invocation and implicitly points at the search tools as the downstream step. No explicit when-not-to-use or named alternative is given, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, openWorldHint and idempotentHint, so the safety profile is covered. The description adds value on top: return shape ('compact rows with price, specs, city and a link'), the fact that listing text is Polish, and that currency is PLN. It stops short of discussing pagination or result limits beyond what the schema's cursor field implies.

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?

Four compact sentences, front-loaded with the core action and domain, then segment semantics, then return shape, then currency. Nothing is padded, though the price/currency sentence slightly overlaps what the schema already says.

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 20 optional parameters and no output schema, the description carries a fair load: it explains the segment switch, the currency and language environment, and the shape of returned rows. The main gap is that it never routes the agent away from the sibling marketplace/wanted-ad search tools, which matters given the crowded search family.

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%, so the baseline is 3. The description still contributes beyond the schema by clarifying that prices are PLN and that priceMin/priceMax filter the daily/per-period rental rate for rentals, plus the Polish-language constraint on free-text and city matching. These are meaningful additions, though the schema already covers most parameter intent.

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 with domain anchoring: 'Search active camper listings on VanAuto (vanauto.pl)'. An agent knows exactly what is searched and where. It does not, however, distinguish itself from the sibling search_marketplace_listings or search_wanted_ads, so it falls 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?

The description gives real guidance on the segment values ('sale' for campers for sale, 'rental' for rentals) and notes the rental-specific price semantics, which is useful. But it offers no when-to-use-this-tool versus sibling search tools, no prerequisites, and no exclusions — 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 readOnlyHint, idempotentHint and openWorldHint, so the safety/idempotence profile is covered. The description adds the return shape ("compact rows plus facets with category/condition counts"), which is genuinely useful given no output schema, but says nothing about pagination limits or result caps.

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 with no filler; the resource and scope come first and the return-shape detail second. Slightly denser than ideal 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?

For a read-only search tool with no output schema, the description covers the domain scope and the return shape (rows plus facets). The main gap is pagination/limit behavior and how the filters combine (AND vs OR), which an agent might 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 100%, so every parameter is already documented in the schema. The description groups the filters (text, manufacturer, category, condition, compatibility, price) at a high level but adds no syntax, format or example detail beyond what the schema provides, 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?

States a specific verb and resource ("Search the VanAuto marketplace") and scopes it to camper parts and accessories. This implicitly distinguishes it from siblings like search_campers and search_wanted_ads, but the differentiation is not stated explicitly, so it falls 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?

The description enumerates supported filters but never states when to use this tool versus alternatives such as get_marketplace_listing_details or search_campers. No when/when-not conditions are given, leaving routing to inference.

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 openWorldHint, so safety and repeatability are covered. The description adds the available filter dimensions but says nothing extra about pagination limits, result ordering, or freshness of these ads.

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 tight sentences: purpose first, supported filters second. Zero filler and nothing that could be cut.

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 5-parameter, all-optional, read-only search with no output schema and full schema coverage, the description supplies what is needed to invoke it correctly. A brief note on result shape or paging behavior would make it complete.

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% — every parameter (page, query, perPage, category, subcategory) is documented in the schema, including slugs and defaults. The description only restates the filter categories, adding no syntax or constraint detail beyond the schema, 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?

Specific verb+resource: 'Search marketplace wanted ads ... posted by buyers looking for camper parts'. The domain gloss (kupię / poszukuję) and the buyer-side framing distinguish it from listing-search siblings, though no sibling is named.

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 only implied: an agent can infer this is for finding buyer demand rather than seller listings, but the description never states when to prefer it over search_marketplace_listings or search_campers, nor any exclusions.

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