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

Annotations already declare readOnlyHint and idempotentHint, but the description adds crucial behavioral context: results cover only auctions changed in the scanned window, not the whole catalogue, and instructs to 'Always report the window and coverage alongside any number.' This exceeds the baseline safety hints and prevents misuse.

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 longer than average but every section earns its place: when-to-use, key parameters, examples, returns, and a critical caveat. Clear formatting with headers and bullet-like structures makes it scannable without redundant 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 8 parameters and no output schema, the description thoroughly covers return structure (totals, status histogram, soldSharePercentOfSettled) and the critical sampling caveat. It provides enough information for an agent to correctly select, invoke, and interpret results, leaving no major gaps.

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

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

Schema covers 100% of parameters, but the description adds substantial meaning: explains 'since / until' omission behavior, 'scan_pages' default and sampling trade-off, and clarifies group_by semantics with examples. This goes far beyond the schema's field descriptions.

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 action: 'Counts, price statistics and sold-share over a window of auction activity, broken down by a dimension of your choice.' It clearly distinguishes from siblings by emphasizing 'volume and trends rather than individual lots', with concrete example questions like 'how much land was auctioned last week'.

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?

An explicit 'WHEN TO USE' section lists question types, and the description implies not to use it for single-lot queries (which siblings like get_auction handle). Two example JSON payloads demonstrate realistic invocations, providing clear guidance on when this tool is appropriate.

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, openWorld, idempotent, and non-destructive, so the bar is lower. The description adds valuable context beyond annotations: 'Re-listings of the same lot are excluded' and 'The sample comes from recent activity, not full history — say so when quoting a figure.' These are important behavioral caveats not evident from the 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?

The description is organized with clear sections: core purpose, when-to-use, key parameters, examples, and returns. Each section is concise and every sentence adds value. Despite its length, it never feels padded, and the examples are well-integrated.

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 5 parameters, no output schema, and moderate complexity, the description covers usage, parameter semantics, return contents, and important caveats (re-listing exclusion, recency). It even advises how to communicate results to users ('say so when quoting a figure'), making it complete for an agent to invoke 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 100%, but the description greatly enriches parameter meaning: explains each match_on enum option ('same auction format and programme', 'same CAV asset category', 'region — same oblast', 'valueRange — within ±50%'), explains the impact of adding criteria, and clarifies concluded_only and limit/scan_pages. The examples further illustrate parameter combinations.

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+resource: 'Takes one auction and finds recent comparable ones, then reports median prices and how often that kind of lot actually sells.' This clearly distinguishes it from sibling tools like search_auctions (searching) or get_auction (fetching a single record).

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?

An explicit 'WHEN TO USE' section states 'valuation and risk questions' and gives concrete example queries. It does not mention when not to use or name alternatives among sibling tools, so it falls short of a 5 but is clearly actionable.

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 readOnly, openWorld, idempotent, and non-destructive. The description adds behavioral details beyond these: bid amounts only appear after the auction concludes, lease auctions carry propertyOwner/ownershipType/currentTenants, and redacted personal data appears as '[redacted]'. No contradiction exists.

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?

Though moderately long, the description is well-structured into WHEN TO USE, KEY PARAMETERS, EXAMPLES, and RETURNS. Each section earns its place: the examples show concrete usage, the RETURN section describes conditional fields, and the alternative guidance prevents misuse. 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 2-parameter tool with no output schema, the description fully compensates. It explains return structure (summary, seller, per-section counts, requested sections), conditional data (bid amounts, lease fields), redaction behavior, and provides complete examples. Combined with sibling differentiation, an agent has everything needed to invoke 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 coverage is 100%, with each parameter already described. The description adds extra value with examples, clarifies accepted id formats (public or internal), explains default include values, and provides a plain-language breakdown of each include option. While redundant in part, the examples and clarifications go 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?

The description clearly states 'Everything about a single auction: the asset, the financial terms, the seller, and whichever sub-sections are asked for.' It differentiates from sibling tools by explicitly naming get_auction_timeline and get_auction_results for narrower needs, and implies document-only access via get_auction_documents.

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?

An explicit 'WHEN TO USE' section states 'the user names an auction, or a search result needs expanding.' It also provides exclusions: 'For deadlines alone use get_auction_timeline; for the outcome alone use get_auction_results — both are much smaller responses.' This gives clear guidance on choosing alternatives.

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

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

Beyond the annotations (readOnlyHint, idempotentHint), the description discloses that download URLs are public and require no authentication, explains the default attachment scope, and notes that documents attached to bids are never published. This adds meaningful behavioral context without contradicting 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 well-structured with clear sections (main statement, WHEN TO USE, KEY PARAMETERS, EXAMPLES, RETURNS). Every sentence adds value; there is no redundancy or filler. It is long enough to be thorough yet remains skimmable.

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 RETURNS line fills the gap by describing the response fields. The description also explains defaults, edge cases, and the fact that bid attachments are excluded, making it self-contained for an agent to understand behavior and limitations.

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?

Even though the schema covers all parameters, the description enriches each one with operational meaning: common document_type values, the semantics of include_attachments_of ('outcome paperwork', 'withdrawal justification'), and the default of include_superseded. Two concrete examples show how to combine parameters, making the API easier to invoke 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?

The description opens with a specific verb and resource: 'Files published for one auction, each with a direct public download URL...' This clearly identifies the tool's purpose and distinguishes it from sibling tools like get_auction, get_auction_timeline, or get_auction_results, which handle other aspects of an auction.

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 'WHEN TO USE' section lists concrete user phrases such as 'show me the documents' and 'where is the technical specification', giving clear context for when this tool is appropriate. It also hints at when to extend scope with include_attachments_of or include_superseded. However, it does not explicitly name alternative sibling tools, so it stops short of a full 5.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description enriches this by disclosing that in-progress auctions return 'in_progress' rather than failing, winner identities are redacted, bid amounts appear only after conclusion, and attemptNumber indicates prior sale failures. These are meaningful behavioral details 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 organized into clear sections (intro, WHEN TO USE, KEY PARAMETERS, EXAMPLE, RETURNS), with the most important information front-loaded. It is somewhat lengthy, but every section contributes useful detail, so it earns a 4 rather than a 5.

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 takes on the burden of explaining return values. It enumerates possible outcome values, starting vs final price with priceUpliftPercent, bid/disqualified-bid counts, attemptNumber, awards, contracts, and cancellation reasons. It also covers platform redaction and timing of bid amounts. This is thorough for a single-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?

The input schema already provides 100% coverage for the single 'auction' parameter, including format examples. The description's KEY PARAMETERS section largely repeats this ('public auction id or 24-character procedure id') and adds only a concrete example. This aligns with the baseline of 3 for high schema coverage; it does not add meaningfully new 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 opens with a clear, specific verb+resource: 'How one auction ended: sold or not, for how much, to how many bidders.' This directly states what the tool returns and distinguishes it from siblings like get_auction (likely auction details) and get_auction_timeline (event history). The addition of in-progress auctions further refines the 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?

The 'WHEN TO USE' section provides explicit example queries: 'what did it go for', 'did it sell', 'how many people bid', 'why was it cancelled'. This gives clear usage context. However, it does not name alternative tools or explicitly state when not to use this tool, so it falls 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?

Despite having annotations (readOnlyHint, idempotentHint, etc.), the description adds substantive behavioral context beyond them: it details return contents (status with plain-language meaning, past/current/upcoming stages, next deadline, bidding block with closesAt/stillOpen/hoursRemaining) and notes cancellation reasons appear when appropriate. This fully informs the agent about what the tool does and returns.

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 well-organized with clear sections (initial description, WHEN TO USE, KEY PARAMETERS, EXAMPLES, RETURNS) and uses concise, high-signal language. Every sentence contributes to understanding the tool, and the examples are particularly efficient at conveying usage.

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

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

The tool has only 2 parameters and no output schema, but the description fully covers its input and output behavior, including edge cases like cancellation. The RETURNS section explains the response shape without an output schema, making it complete for agent decision-making.

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 already has 100% parameter coverage, but the description adds significant value with a KEY PARAMETERS section explaining each parameter's meaning and when to use them (e.g., include_revisions 'when the user suspects the conditions changed'). Concrete JSON examples illustrate usage, going well beyond schema descriptions.

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

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

The description clearly states the tool's function as 'the stage clock for one auction' and specifies exactly what it provides: what has passed, what is running now, what comes next, and time left to bid. It also distinguishes it from get_auction by noting it is 'far smaller' for time-related queries, making it easy to select among 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?

The 'WHEN TO USE' section explicitly lists example questions like 'how long do I have' and 'when is the auction', and directly compares with get_auction, stating it is 'far smaller for this'. This provides clear when-to-use guidance and an alternative, exceeding the minimum.

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 non-destructive behavior; the description adds valuable context that the value is computed live and not cached. It also clarifies that a family name checks all supported formats at once, which is non-obvious behavior beyond the 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?

The description is well-organized with clear headers, key parameters, examples, and return structure. Every sentence adds value, and the format makes it easy to scan for purpose, usage, and behavior.

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 having no output schema, the description fully explains return values (earliestAuctionStart and noticeDays) and their behavior. It covers parameter semantics, examples, and placement within the tool family, making it self-sufficient 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?

The schema only describes procedure_type as a selling method, but the description enriches it significantly by documenting family-name support, the ability to compare formats, and concrete examples. This goes well beyond baseline 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?

Clearly states the tool's purpose as seller-side planning for the earliest possible auction date. The description explicitly identifies it as the only forward-looking tool among siblings, effectively distinguishing it from tools that describe existing auctions.

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?

Provides an explicit WHEN TO USE section with concrete user queries and contrasts with siblings by noting everything else describes existing auctions. However, it does not name a specific alternative tool, leaving the exclusion slightly less direct than naming search_auctions or get_auction.

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 state readOnly/idempotent, and the description adds non-obvious traits: cheap/cached behavior, the exact scope (33 families, 10 statuses), and the silent-empty-result behavior when an unrecognised procedure_type is passed. This goes beyond annotations without contradicting them.

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?

Well-structured with clear headings (WHEN TO USE, KEY PARAMETERS, EXAMPLE, RETURNS). Every section contributes—the intro establishes its role, examples demonstrate syntax, and returns set expectations. No redundant 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?

Covers the full scope of output (33 families, sellingMethod values, id prefixes, status glossary), explains when to disable the glossary, and warns about failure modes. For a read-only vocabulary tool with 2 optional params and no output schema, this is 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 already describes both params with 100% coverage. Description adds concrete examples for filter ('land', 'lease', 'privat', 'timber'), shows how include_status_glossary can be set false, and provides example JSON calls. This adds usability but schema already handled the core 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 explicitly states its purpose: 'The vocabulary every other tool filters on' and details that it lists programme families, auction formats, statuses, and id prefixes. This distinguishes it from siblings like search_auctions or get_auction by positioning it as the vocabulary/lookup 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?

Includes a 'WHEN TO USE' section specifying to call before a search when an asset programme is unclear, when the user asks about auction kinds/statuses/prefixes, and explicitly says 'Call this rather than guessing a procedure_type value'. It also warns about silent returns for unrecognised values, which is actionable 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 readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond these: it explains the 'scanned' window semantics, warns that 'an empty result means not in the scanned window, never does not exist', and documents the per-type feeds behavior with procedure_type expansion. It also distinguishes owner vs seller data provenance, which is critical for correct interpretation.

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 structured with clear sections (WHEN TO USE, KEY PARAMETERS, EXAMPLE, RETURNS), each sentence earning its place. It front-loads the core purpose, then progressively details parameters and examples without redundancy. Despite its length, it remains scannable and information-dense, with 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?

For an 18-parameter, 0-required tool with no output schema, the description is remarkably complete. It covers selection criteria (what to search), key parameter semantics, usage examples, and return-value behavior including the important 'scanned' block warning. The only minor gap is lack of explicit pagination/limit guidance beyond scan_pages, but the three examples and RETURNS section provide enough operational completeness.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds substantial meaning beyond schema: it clarifies the semantic distinction between seller and property_owner (the body running the auction vs the asset's owner), explains the procedure_type family/format expansion behavior, and provides three concrete examples mapping real user intents to parameter combinations. This is meaningful added value, though the schema already documents individual parameter meanings well.

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 ('Find auctions of Ukrainian public assets') and clearly positions itself as the entry point for 'what is available' questions. It distinguishes itself from get_auction ('For a specific auction id, call get_auction instead'), making its scope unambiguous.

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

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

The description provides an explicit WHEN TO USE section and names the alternative (get_auction) for specific IDs. It also gives detailed guidance on when to use property_owner vs seller, when to use open_for_bids, and how to use changed_since/scan_pages for historical searches, far exceeding mere context.

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, idempotentHint, and destructiveHint=false, but the description adds substantial behavioral depth beyond these: cursor-based forward progress, the inclusive-cursor caveat ("the last auction may repeat once"), default `since` behavior, and the distinction between new and updated items via `isNew`. This enriches the agent's understanding without contradicting 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 well-structured with clear sections (WHAT, WHEN TO USE, KEY PARAMETERS, EXAMPLES, RETURNS) and uses bold labels. Every paragraph earns its place: two examples, one for first poll and one for follow-up, and the return fields are summarized without restating the schema verbatim. Despite its length, it is dense with useful information and free of 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?

The tool has 8 parameters, no output schema, and moderate complexity due to cursor semantics. The description covers the monitoring use case, parameter roles, default behavior, examples, and return fields (changedAt, isNew, newlyPublished, nextCursor). It also mentions the inclusive-cursor edge case. This is sufficient for an agent to invoke the tool correctly across both initial and follow-up calls.

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% with per-parameter descriptions, so the schema already handles literal meaning. The description adds semantic value by grouping parameters (procedure_type/status/keyword/region as niche narrowers), giving practical advice for `since` (pass back nextCursor), and explaining when to raise `limit`/`scan_pages` (busy window truncation). It doesn't cover `until` but the schema does; overall the added context exceeds the baseline.

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

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

The description opens with a specific, behavior-rich statement: "What appeared or changed in a niche since a given moment." This clearly identifies the action (tracking new/updated auctions), the resource (auctions in a niche), and the time-based scope. It also explicitly differentiates from search_auctions by framing monitoring vs. one-off searching, making the tool's purpose unmistakable.

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 includes a dedicated "WHEN TO USE" section with concrete examples ("anything new since yesterday", "keep me posted") and directly instructs to "use search_auctions instead" for one-off questions. This is explicit, actionable guidance that names the alternative tool and the decision criterion.

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