Vitrine: Trending Fashion, Luxury, Sneakers & Design

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds plenty beyond that: unknown id produces an error result, keyless calls are capped at 5 and omit trend data and match reasons, how to obtain and send a key, and exact rate limits. The only redundancy is the terse 'Read-only' restatement of readOnlyHint; richer detail like whether the cap is truncation vs. ranking limit is left implicit.

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?

Dense but front-loaded: item, what comes back, selection logic, when to use, filters, response shape, then operational caveats. Every sentence carries information, though the single unbroken paragraph of roughly a dozen clauses would be easier to scan with any structural break, and the stale 'Read-only' duplicates an annotation.

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?

Despite nested filter objects and an optional agent block, the description covers the identity of the anchor, the ranking rationale, the response envelope, the error case, and the key/rate-limit constraints. With an output schema present it does not need to enumerate every field, and nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is moderate (67%), and the description clarifies the crucial semantics that filters apply to every added piece rather than the anchor, calling out max_price as per piece plus size and ship_to. It does not explain the tier enum, gender_exact behavior, or the agent object, but the schema already documents those inline, so the added meaning is well targeted.

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 concrete task (build an outfit/room around a given item id) and immediately specifies the two output shapes — missing outfit slots for fashion, complementary room objects for interior — including the dress exception. It also explicitly contrasts itself with the sibling find_similar, so an agent can separate the two without opening either schema.

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

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

Gives explicit trigger phrases ('what goes with this', 'style this', 'finish the room') and names the alternative tool plus the condition that selects it ('use find_similar for alternatives to the item itself'). It also states the id must come from an earlier result, which prevents a common misuse.

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, and the description reinforces this with "No key needed; read-only." Beyond that it adds real behavioral context the annotations cannot: results carry a note on the convention used and are flagged "approximate" or "ambiguous" when a size falls between or spans rows, which tells the agent how to hedge its recommendation. The only shortfall is that it leans on the output schema for the actual result shape.

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 trigger condition and the conversion scope are front-loaded, and the long enumeration sentence earns its length by covering genuinely distinct size families. It is dense and would benefit from breaking that one sentence into a short list, but no sentence 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?

For a three-parameter, read-only lookup with full schema coverage, an output schema, and complete annotations, the description supplies everything an agent needs: which kinds and systems pair, when to invoke it, how to interpret ambiguous results, and how to defer to brand charts. Nothing material is missing.

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

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

Schema coverage is 100%, so the baseline would be 3, but the description adds meaning the schema does not: it maps each `kind` value to the specific systems valid for it (e.g. jeans waist vs. rings in millimetres vs. sneakers with US_M/US_W/CM), which constrains `system` per `kind` in a way the free-text schema field cannot. It also gives concrete size examples matching the schema's format hints.

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 opens with a specific verb and resource ("Convert a size between systems") and then enumerates every supported size family and the systems each accepts, so an agent can immediately tell this apart from sibling tools like get_item or vocabulary. The goal statement ("so the shopper orders the right one") also anchors the purpose in the shopping flow.

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 states the exact triggering condition ("whenever the shopper's size and the item's sizes are in different systems") and the sequencing constraint ("before recommending a size"), plus a precedence rule that the brand's own chart always wins. There is no sibling tool performing conversion, so no alternative needs naming, and the guidance leaves nothing 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 readOnly/idempotent, yet the description adds substantial behavior: the source item is never included, an unknown id yields an error result, an empty list has a specific meaning, and anonymous calls are capped at 5 while omitting trend data and match reasons. It even documents the free key endpoint, auth header format, and per-minute rate limits for anonymous vs keyed callers.

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

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

Front-loaded with the core action and use cases, then return shape, error semantics, and auth/rate-limit caveats in a logical order with zero filler. It is dense and multi-clause, but nearly every sentence carries distinct 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?

Even though an output schema exists, the description sketches the return envelope ({anchor, count, results}) and the 'why' field, plus degradation without a key. For a filtered similarity search with nested objects, that covers everything an agent needs to invoke and interpret it.

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 schema does much of the work, but the description still adds value by clarifying that the id must come from an earlier result and by naming the filters that matter for the common shopping intents. The agent and limit parameters are left entirely to the schema, which keeps this below a 5.

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 ('Find alternatives to one item') and pins the input to 'id from an earlier result', which cleanly separates it from search and get_item. The scoping phrase 'pieces close in style, the same product type first' tells the agent exactly what kind of result set to expect.

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

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

Gives concrete when-to-use triggers mapped to specific filters ('something like this but cheaper' → filters.max_price, 'but in stock' → filters.availability, or a different color). It does not explicitly say when to prefer a sibling like search instead, so it stops short of full routing 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?

Goes well beyond the readOnly/idempotent annotations: it discloses the anonymous result cap of 5 items, which fields are withheld without a key, how to obtain a key and pass it, and the exact rate limits (10/min anonymous, 60/min keyed). It also states the failure mode for an unknown id ('returns an error result telling you to search again').

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 opening sentences are tightly front-loaded and earn their place, but the final sentence spends ~60 words enumerating trend_reason, trend_sources and trend_review fields, which duplicates the existing output schema. Rate limits and auth could also be compressed into one clause.

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 single-record lookup with an output schema present, everything an agent needs is covered: valid id provenance, expected envelope {item, meta}, auth path, quotas, gated fields and error behavior. Nothing material 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?

Schema coverage is 50% and the required 'id' parameter is already documented identically in the schema; the description repeats rather than extends it. The only added meaning is auth-related (Bearer key), which is not a parameter, and the optional 'agent' object is never discussed.

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 ('Get the full record for one item') and immediately scopes the input to ids from search, trending or find_similar, which separates it from those lookup siblings. An agent can distinguish it from search/trending without opening any schema.

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

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

Gives a concrete when-to-use condition ('before recommending a piece, to check sizes, materials, colors, shipping regions and seller') and points to the sibling tools that produce valid ids. It stops short of an explicit when-not or a named alternative for the case where the agent has no id.

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

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

Beyond the read-only and idempotent annotations, the description discloses authentication limits, rate limits, anonymous-result caps, omitted trend data and match reasons, and where checkout happens. It also explains that hard filters exclude while query wording and taste_profile only rerank, which is behavior an agent needs before calling.

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 long but front-loads the decision rule and then organizes filters, ranking, return behavior, authentication and rate limits in a useful order. A few statements repeat structured annotations or schema details, such as read-only and no pagination, but the density is justified by the tool's complexity.

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 nested filters and taste_profile schema, the presence of an output schema, and the authentication differences, the description is complete enough for correct invocation. It explains return shape, missing behavior, key-gated fields and failure handling without needing to restate every schema field.

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 meaningful semantics beyond the schema, especially that category, gender, tier, price, colors, size, brand, availability and ship_to are hard exclusions, and that gender includes unisex unless gender_exact is true. It covers the most important fields, though it does not mention the optional agent identity fields and leaves some nested taste_profile details to 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 states a specific verb and resource, finding fashion, accessories or interior pieces for a shopper request. It explicitly distinguishes this tool from trending and find_similar, so an agent can identify the correct sibling without opening schemas.

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 explicit routing guidance: use this first for needs stated in words, use trending when there is no specific need, and use find_similar to vary an existing item. It also says what empty results mean and instructs to loosen filters rather than paginate.

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, and the description goes beyond them by disclosing matching behavior (case- and accent-insensitive, partial matches) and a tiered response: trend status, trend score and top style tags only when a key is supplied. That key-gated data difference is exactly the kind of behavioral detail annotations cannot convey. It says nothing about error or empty-result behavior beyond the empty-query ordering.

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

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

Three dense sentences, front-loaded with the matching modes before scoping options and return contents. Every clause carries information an agent would otherwise have to infer from the schema, and nothing is repeated verbatim from structured fields.

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?

All five parameters are optional and the description covers the one that carries the semantics, while an output schema exists so the return-value summary is a convenience rather than a necessity. For a read-only search with a rich schema and annotations, the only real omission is guidance that agent is optional self-identification and that limit is capped for anonymous callers.

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 60%, so the schema already documents tier, agent and limit reasonably well, including the 5-20 range and the anonymous-caller cap. The description meaningfully deepens the query parameter (accent/case handling, partial names, style-word matching, empty-string behavior) but adds nothing about agent, limit, or the tier vocabulary beyond "optionally within a category or catalog tier".

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 ("Find brands in the index") plus the two match modes (name or style word) and the scoping options (category, catalog tier). The result fields are enumerated, so an agent knows what comes back. It stops short of naming siblings like similar_brands or trending_brands, so differentiation is inferred from the phrasing rather than stated.

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

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

Gives clear operative context: use a name fragment for brand lookup, a style word for discovery, and an empty query to list everything ranked by item count. It does not exclude or route to alternatives such as similar_brands or trending_brands when those would be the better choice, so no explicit when-not 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, non-destructive and closed-world, so safety is covered. The description does add non-obvious behavior: unknown brand names produce an error, and each result carries a short reason. It does not say how results are ordered or how the reason text is generated, which is modest added value on top of 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 three tight sentences with the core purpose front-loaded, followed by optional filters and then the error/routing note. The parenthetical examples are compact and useful; there is 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 an output schema present, the description needn't describe return shape, yet it still mentions the per-result reason. It covers the required input, error behavior and optional filters. Minor omissions such as result ordering or how limit interacts with anonymous callers are acceptable at this complexity.

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 80%, so the schema already documents brand, tier, category, limit and agent. The description reinforces the exact-name semantics and case/accent insensitivity of brand, and restates the meaning of the tier/category filters. It adds marginal detail rather than new syntax, which fits given high schema coverage.

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 the resource (brands similar to a given brand) and states what similarity is based on: style tags, categories, price level and catalog tier, plus a per-result reason. This is enough to distinguish it from search_brands (name lookup) and find_similar (item-level similarity).

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

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

Gives clear prerequisites and routing: the brand argument must be an exact name, and search_brands is named for resolving unknown names, with an error reported for unknown brands. It also explains when to use the optional category/tier filters. The one gap is that it doesn't contrast with its sibling find_similar, which also performs similarity.

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 cover the safety profile (readOnly, idempotent, non-destructive), but the description adds substantial behavioral context beyond them: anonymous results capped at 5 with trend data and match reasons withheld, rate limits of 10/min anonymous vs 60/min keyed, the exact key acquisition endpoint and header format, and the three extra per-item fields (trend_reason, trend_sources, trend_review) unlocked by a key. The one redundancy is restating 'Read-only', which is already in 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?

Front-loaded with purpose and routing before credentials and rate limits, and nearly every clause carries decision-relevant information. It is dense to the point of being a run-on in the key/rate-limit sentence, but trimming it would cost an agent real operational detail.

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?

Return shape is delegated appropriately ('same shape as search, plus meta.updated_at') and an output schema exists, so values needn't be re-explained. Combined with auth, quota, and the category/gender semantics, an agent has everything needed to call this correctly on the first attempt.

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 only 40%, so the description carries real weight: it clarifies that 'men' and 'women' include unisex pieces and lists the category values (fashion, accessories, interior). It does not explain the `tier` enum values (luxury_anchor, trend_brand, streetwear, etc.) or the `agent` block semantics, leaving half the parameters to the schema alone.

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

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

States a specific verb and resource ('List what is hot or rising right now, ranked by trend score 0 to 100') and immediately scopes the optional filters (category, tier, gender). It also distinguishes itself from the sibling `search` by naming the exact condition that selects each ('open questions ... use search when the shopper has a specific need').

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

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

Gives explicit when-to-use routing against `search` with example phrasings ('what's trending in bags', 'in menswear'). It also defines the two ambiguous terms an agent would otherwise guess at: 'hot' means confirmed by demand data, 'rising' means early momentum not yet confirmed.

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 establish the safe, read-only, idempotent profile, so the description is free to add the genuinely useful behavioral detail: the two-score methodology (reviewed brand-level signals vs. item aggregates) and the trend_source field that exposes which was used. That is real context an agent could not get from annotations or 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?

Two sentences, no filler. The identity of the tool and its ranking come first, and the methodology and trend_source explanation follows as supporting detail.

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, and annotations cover safety. The description fills the remaining high-value gaps — ranking basis, filtering dimensions, and score provenance — with only limit and agent behavior left implicit.

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?

With only 25% schema description coverage across four parameters, the description partially compensates by explaining that category and tier are optional scoping filters. It says nothing about the limit parameter or the agent self-identification object, leaving the anonymous 5-result cap and agent metadata meanings to the schema alone.

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

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

The description states a specific resource (brands) and a specific ranking basis (brand trend status and score), plus the optional category/tier scoping. It does not explicitly name sibling tools like trending or search_brands, so an agent must infer the brand-vs-item distinction rather than being told.

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 or when-not-to-use guidance, and no alternative is named. An agent reading only this description cannot tell under what circumstances to prefer trending_brands over trending, search_brands, or similar_brands.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description goes beyond them by disclosing that values are 'read from the live catalog with item counts' (freshness and richness of the payload) and that the result is cacheable for the session — real behavioral context. It stops short of describing payload shape or size, but an output schema exists to carry 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?

Purpose and the caching instruction bracket the description, so it is front-loaded and closes with the actionable rule. The long enumeration of vocabularies earns most of its length by telling the agent what it will receive, though it could be trimmed slightly without losing meaning.

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-required-argument lookup with a full output schema and complete annotations, the description covers what it returns, why to call it, and caching strategy — enough to invoke it correctly. The only omission is any mention of the optional agent identification block, which is minor given the tool works without it.

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 reported at 0%, so the description would normally need to compensate for the single optional 'agent' parameter. It instead says 'No arguments', which is functionally true for required inputs but never mentions the optional self-identification object, whose purpose (better ranking) lives only in the schema. Adequate to drive a correct zero-argument call, but it does not add meaning beyond 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?

States a specific resource and payload: 'the exact controlled values agents should use in filters and taste profiles', then enumerates the vocabularies (categories, price tiers with bands, trend statuses with meanings, sizes, conditions, ship-to regions) plus 'every filter field name with its type'. This clearly separates it from siblings like search or trending, which consume these values rather than define them.

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

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

Gives explicit when-to-use and how-often: 'call it once per session, before building filters', and explicitly excludes the need for inputs with 'No arguments'. An agent knows both the trigger point and the call cadence without inference.

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