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

No annotations are provided, so the description carries the full burden. It discloses that only unseen listings are returned, which suggests a stateful 'seen' mechanism. However, it omits what happens to the seen state (e.g., marking listings as seen by default), any side effects, or rate limits, leaving significant behavioral gaps.

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, efficient sentence that front-loads the core action and outcome. It earns its place but could benefit from slightly more detail given the lack of annotations and schema descriptions.

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?

An output schema exists, so return values needn't be explained. However, with no annotations and 0% schema coverage, the description should do more to cover parameter semantics and side effects. It is adequate but leaves clear gaps for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain the parameters. It only mentions 'run a saved hunt' (implying 'name') and 'seen before' (implying 'mark_seen'), but does not clarify that 'mark_seen' defaults to true or what the parameter does. Most parameter meaning is left to inference from titles.

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 ('Run a saved hunt'), and clarifies the output scope ('return only listings not seen before'). It's distinguishable from siblings like run_hunt, but the description doesn't explicitly say how it differs from that tool, leaving a small ambiguity.

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 tool is used to check for new matches from a saved hunt, but it doesn't specify when to use this versus run_hunt or check_saved_search. No explicit when-not or alternative tool guidance is provided.

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 present, the description carries the full burden and does disclose the key non-obvious trait: mark_seen=True persists returned IDs as seen, mutating state that affects subsequent calls, and False gives a dry-run. It omits any note on permissions or what happens to deleted/expired saved searches, but the critical side effect is surfaced.

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 sentence of purpose followed by a compact Args block; every line earns its place and the core behavior is front-loaded. Slightly verbose line-wrapping on mark_seen, but no 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?

An output schema exists, so the description rightly does not explain return values. It covers the tool's novelty filter and state-mutation semantics; the only gap is routing guidance relative to similar siblings (check_new_matches, run_hunt).

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 — and it does, documenting both required 'name' and the optional 'mark_seen' with its default and exact behavioral consequence. Nothing beyond what's stated is needed to call it correctly.

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: 'Re-run a saved search and return only listings not seen before' — an agent immediately knows it re-executes a stored search with a novelty filter. It does not, however, distinguish itself from the sibling check_new_matches, which sounds like it could serve a similar role.

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 tool presumes a saved search already exists (created via save_search). The description gives one conditional instruction ('Set False for a dry-run') but never says when to prefer this over check_new_matches, run_hunt, or search_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?

With no annotations, the description carries the full behavioral burden and does not meet it. "Remove" implies a mutation, but it never says the deletion is permanent/irreversible, whether a confirmation is needed, what happens if the name doesn't exist, or whether any permission is required.

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 short, front-loaded sentence with no filler. It is efficient, though its brevity here reflects under-specification rather than disciplined concision.

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?

An output schema exists so return values needn't be explained, but for a destructive tool with zero annotations the description is too thin: no irreversibility warning, no auth note, no failure mode, and no help interpreting the single undocumented parameter.

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 single required parameter "name" has 0% schema description coverage, and the description does not compensate at all — it never clarifies whether name is the saved search's identifier, a label, or a case-sensitive match. A destructive operation keyed on an unexplained name is a real gap.

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 ("Remove a persisted search"), which is more precise than the bare name. It does not, however, differentiate itself from siblings like save_search, list_saved_searches, or check_saved_search, so an agent must infer the division of labor from the names 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?

There is no guidance on when to use this tool versus list_saved_searches or check_saved_search, and no stated precondition (e.g., the search must already be saved). The agent gets no signal about when this is the right call.

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 whole burden. It implies a read/discovery operation but never states that it is side-effect free, whether it is cached, or what happens when category/subcategory are omitted (both default to null).

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 verb and the object of discovery come first.

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?

An output schema exists, so return values need not be described. However, with no annotations and completely undocumented parameters, the definition leaves the calling contract underspecified for a 3-parameter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All three parameters (site, category, subcategory) have 0% schema description coverage, and none are explained in the description. Defaults such as site='marktplaats' and nullable category/subcategory are left for the agent to interpret, so the description fails to compensate for the coverage gap.

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 ('Discover') and resource ('the attribute filters available within a category'), which is clearly distinct from siblings like list_categories or get_listing_details. It stops short of explicitly naming those siblings as alternatives, but an agent can tell what this tool returns.

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 when-to-use context, no prerequisite (e.g. needing a known category id), and no mention of how this differs from list_categories. The agent must infer the workflow entirely.

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 behavioral burden. It discloses the return fields, but omits whether authentication is needed, rate limits, error behavior for invalid IDs, and whether this is a read-only operation. For a fetch tool with zero annotation coverage this is a gap.

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 purpose and return fields, followed by a compact args block. No wasted sentences, though the args formatting is informal.

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?

An output schema exists, so the description needn't explain return types; it still lists the fields, which is a slight redundancy but harmless. Parameter coverage is complete and the purpose is clear. The main gap is usage context against siblings, but for a simple detail-fetch this is close to 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 0%, so the description must compensate and it does: it gives a concrete example for listing_id and explains the 'm' prefix normalization, and it enumerates the valid values for site. Both parameters are documented with enough detail to call the tool correctly.

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 (Fetch) and resource (listing page) and enumerates the returned fields, so the agent knows exactly what this tool retrieves. It does not explicitly distinguish itself from siblings like search_listings or hunt, though the singular 'listing page' implies detail-fetch versus search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this versus search_listings or the hunt tools. The agent must infer that this is a detail lookup, but there are no stated conditions, 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?

With no annotations, the description carries the full burden, and it usefully discloses a negative behavioral trait: the endpoint does not return seller name/id and only exposes verification flags, payment method, and aggregated review stats. It says nothing about auth requirements, rate limits, error behavior, or that this is a read-only lookup.

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?

Purpose is front-loaded in the first sentence and the caveat follows in a compact second sentence. No filler, though the parenthetical and note could be tightened into one line.

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?

An output schema exists, so return-value detail is not required, and the description adds the non-obvious negative caveat. However, with 0% parameter coverage and no annotations, the missing param and safety context leaves it only minimally adequate for calling the tool 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 description coverage is 0% with two parameters, so the description must compensate. It only indirectly alludes to seller id via the listing-response note and never explains the 'site' parameter or its 'marktplaats' default, leaving both parameters semantically undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('fetch a seller profile') and enumerates the payload contents (verification status, payment method, reviews). It does not name or differentiate from siblings like get_listing_details, 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?

No explicit when-to-use, when-not-to-use, or alternative selection guidance. The note that name/id come from the listing response hints at a workflow but never says when to call this tool versus the listing tools.

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 it does disclose real behavior: deduplication by Marktplaats listing ID, the found_by provenance list, and hard limits (max 20 searches, max 25 listings per search). It does not clarify whether the hunt is persisted or has side effects (the existence of save_hunt/run_hunt makes this ambiguity meaningful), nor does it state read-only status or request cost.

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-loads the purpose, then example, then hard limits as a scannable list; each block earns its place. Slightly verbose around the example/limits but nothing is 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?

An output schema exists so return structure needn't be explained, and the description covers the nested searches argument and result semantics (dedup, found_by) adequately. The remaining gap is the unclear relationship to save_hunt/run_hunt, which an agent needs in order to choose correctly among these siblings.

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, and it does well for the complex searches parameter: it explains that each entry is a dict of search_listings arguments plus an optional label, and provides a concrete two-element example. The per_search_limit parameter is not named directly, though the stated 25-listing cap gives implied bounds on it.

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: 'Run several complementary Marktplaats searches as one bounded hunt,' which distinguishes it from the single-search sibling search_listings. However, it never differentiates itself from run_hunt or save_hunt, leaving an agent to guess how 'hunt' relates to those near-identical siblings.

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 by 'several complementary searches as one bounded hunt' and the multi-search example, so an agent can infer it is for batching related queries. But there is no explicit when-to-use rule and no named alternative (e.g., why pick this over run_hunt or individual search_listings calls), which matters given the crowded hunt-related sibling set.

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 full burden. It's clearly a read-only list operation, but the description doesn't state that explicitly or describe rate limits, caching, or pagination. It mentions the same IDs work on both sites, which is useful cross-site context, but nothing about behavior beyond that.

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?

Very concise, two short sentences. Front-loaded with the main purpose. The second sentence about IDs working across sites is useful but could be integrated more clearly. No 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?

With an output schema present, return values needn't be explained. However, for a reference tool with no annotations and an undocumented parameter, the description is minimal. It doesn't explain what 'main categories and common subcategories' look like or how to use them, nor does it clarify the site parameter's effect. Adequate but incomplete.

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% and there's 1 parameter ('site' with default 'marktplaats'). The description mentions 'marktplaats.nl and 2dehands.be' which implies the site parameter controls platform, but it doesn't map the parameter values to the domains or explain the default. This adds marginal value but leaves the parameter's enum/usage 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?

States a specific verb (list) and resource (categories/subcategories) with clear scope. Distinguishes itself from siblings like get_category_filters which presumably returns filters for a category, and from search_listings. The description makes it clear this is a reference/list tool.

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 guidance or alternatives are named. The description implies it's a reference tool for discovering categories before searching, but it doesn't say when to use it vs get_category_filters or search_listings. No prerequisites or exclusions 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?

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: no read-only confirmation (only implied by 'List'), no note on auth, ordering, or size of the result set. With zero annotation coverage, this is a real gap even for a simple read 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?

A single front-loaded sentence with no filler, which is appropriate for this trivial tool. It is efficient but so brief that it leaves the sibling ambiguity unaddressed.

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?

An output schema exists, so return values need not be explained, and there are no parameters to document, which keeps the required scope small. However, with no annotations and no clarification of how 'hunts' differ from 'saved searches', the definition is only minimally 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?

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing parameter-related the description could add, and the empty schema is consistent with 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 (List) and resource (locally saved hunts), so an agent knows exactly what the tool returns. It does not, however, distinguish itself from close siblings such as list_saved_searches or the hunt/run_hunt family, leaving the 'hunts vs searches' boundary 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?

Naming it a lister implies the usage context, and 'locally saved' hints that this reads persisted state rather than running a live search. There is no explicit when-to-use statement or exclusion versus list_saved_searches, so the agent must infer the boundary.

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 behavioral burden, yet it says nothing about read-only safety, result ordering, pagination, or authorization scope. Beyond confirming the operation is a listing, it discloses no behavioral traits.

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 short sentence with no filler and the key concept front-loaded. It is appropriately sized for a zero-parameter listing tool, though it borders on under-specification rather than tight editing.

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 0 parameters and an output schema covering return values, the tool's complexity is low, so the minimal description is nearly sufficient. It still omits any hint of ordering, auth scope, or relation to the sibling saved-search tools, leaving a modest 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?

The tool takes zero parameters, so there is nothing for the description to clarify and the baseline of 4 applies. Schema coverage is 100% but empty, and the description correctly implies a no-argument call.

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?

"List all persisted searches" gives a clear verb and resource, so an agent knows the operation is a read of stored searches. However, "persisted" is essentially a paraphrase of "saved" in the name, and nothing distinguishes it from siblings like list_hunts or check_saved_search. It is minimally viable rather than specifically 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?

There is no guidance on when to use this versus check_saved_search, list_hunts, or save_search/delete_saved_search. The agent must infer the retrieval role purely from the name and description.

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 behavioral burden yet discloses almost nothing beyond the verb. It doesn't say whether running a hunt mutates state, triggers notifications, is long-running, or what happens if the named hunt doesn't exist.

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 wasted words. It is efficient, though arguably terse to the point of under-specification rather than optimally concise.

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

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

The output schema covers return values, so that need not be described. However, with zero annotations, an undocumented parameter, and no usage context, the description leaves an agent without enough information to invoke this confidently relative to its siblings.

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% and the single parameter 'name' is unexplained. The description implies 'name' identifies the saved hunt, but adds no format, matching rules, or case-sensitivity details to compensate for the undocumented schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb+resource pair ("Run a previously saved hunt") that is distinguishable from siblings like save_hunt and list_hunts. It does not explicitly contrast itself with the bare 'hunt' tool or explain what a hunt is, but the purpose is immediately clear.

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 when-to-use guidance, no prerequisites (e.g., the hunt must already exist), and no pointers to alternatives such as list_hunts to discover a name or save_hunt to create one first. The agent must infer the workflow entirely.

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 bears full responsibility for behavioral disclosure. It states 'locally', which hints at storage scope, but it doesn't disclose persistence behavior, whether saving overwrites existing hunts with the same name, or return/error behavior. An output schema exists, so return format is partly covered, but mutation semantics remain opaque.

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 short sentence with zero waste, front-loading the action and object. No filler or repetition.

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

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

For a mutation tool with 3 params, no annotations, and a 0% schema coverage, the description is minimally adequate but missing critical context: what a hunt is versus a search, overwrite behavior, and parameter meanings. The output schema covers return values, but the input and behavioral aspects are underspecified.

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%, and the description adds no parameter information. All three parameters (name, searches, per_search_limit) are undocumented beyond their titles. The description does not compensate for this gap, though the parameter names are partially 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 clear verb+resource: 'Save a reusable named hunt locally.' The agent can distinguish this from sibling save_search (saves a search, not a hunt) at a high level. However, it does not clarify what a 'hunt' is or how it differs from a 'saved search' beyond the noun.

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 word 'reusable' implies the purpose (create a saved collection for future use), but the description provides no explicit when-to-use guidance or alternatives. With siblings like save_search and run_hunt, the agent must infer the relationship without help.

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 it discloses a genuinely non-obvious state trait: seen_ids starts empty, so the first check_saved_search backfills all current matches, plus the workaround to suppress it. It omits idempotency/overwrite behavior on duplicate names and any auth or rate-limit 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?

The purpose leads, followed by per-argument notes and the one non-obvious behavioral caveat. Every sentence carries information an agent needs; nothing is restated from the schema.

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

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

An output schema exists, so return values are covered elsewhere, and the description adds the creation-time semantics that matter for correct invocation. Only the duplicate-name/overwrite contract and prerequisite for the delegated 'params' shape are 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 description coverage is 0%, so the description must compensate, and it does: it gives the name format ('trek-bike-antwerp'), states that params mirrors search_listings kwargs, and flags the required 'site' key. It still leaves the full param vocabulary to the agent's knowledge of search_listings rather than enumerating it.

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 ('Persist a search') and immediately names the sibling that consumes it ('re-run via check_saved_search'). An agent can distinguish this from search_listings (transient) and list_saved_searches 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?

Clearly establishes the use case (persist for later re-running) and links the required params to search_listings, giving the agent a concrete pattern to follow. It does not state exclusions (e.g., when to prefer save_hunt instead) or whether an existing name errors versus overwrites.

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 reasonably well: it discloses defaults (limit 10, distance 1000), cross-parameter constraints (distance_km requires zip_code), pagination shape (next_offset) and the return dict contents. It omits anything about rate limits, error behavior, or result ordering guarantees, which keeps it out of the top band.

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 one-line summary followed by a tight, scannable Args list where each line maps to one parameter; for a 16-parameter tool this is appropriately sized. The 'Returns:' block lightly duplicates the existing output schema, but it is one sentence and does not bloat the definition.

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?

An output schema exists so return values need not be explained, and the description nonetheless summarizes it. Combined with full per-parameter documentation at zero schema coverage and explicit inter-parameter conditions, an agent has everything needed to call this tool 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 description coverage is 0%, so the description is the only source of parameter meaning, and it documents all 16 parameters: allowed site values, per-site zip formats ('1016LV' vs '2000'), the five condition enums, seller_type aliases (business/zakelijk, private/particulier), sort_by options, and limit bounds. This is exactly the compensation the low schema coverage demands.

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 for listings') plus the exact marketplaces (marktplaats.nl, 2dehands.be), which is more specific than a generic search tool. However it never distinguishes itself from sibling search-like tools such as hunt, save_search, or check_saved_search, so an agent must infer that this is the ad-hoc/one-shot search.

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 conditional notes, e.g. 'query: required if no category specified' and 'attribute_ids: use get_category_filters', which is genuinely useful routing. But there is no explicit when-to-use/when-not statement relative to hunt, save_search, or check_saved_search, so guidance is only partial.

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