Soldgraph

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

Annotations already declare readOnly/idempotent/closed-world, and the description usefully adds context beyond them: the rolling 30-day accounting window, the one-time free credit distinction, the presence of extra requests and a rate limit, and the reassurance that these are 'the same numbers the API enforces.' The 'Free' note also signals no cost. Return format is only gestured at, not detailed.

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 short and front-loaded with the most important datum (plan and requests used), with trust/cost signals ('the same numbers the API enforces. Free.') placed last. The inventory form is slightly fragmentary but wastes no 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?

For a parameterless, read-only, idempotent utility with no output schema, the description provides an adequate field-level picture of what is returned and anchors it to the API's enforced values. Explanations of thresholds or what counts as 'extra requests' would be the only remaining 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 disambiguate. Baseline 4 is appropriate; no parameter-level confusion is possible.

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 enumerates the exact data returned — plan, requests used over a rolling 30 days or the one-time free credit, remaining allowance, extra requests, and rate limit — so the agent knows precisely what this tool surfaces. It is distinct from every sibling (all marketplace listing/search tools), though it reads as a noun-phrase inventory rather than a verb+resource statement.

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 explicit when-to-use guidance; the closest is the implied 'check your quota before/after calls' signaled by the quota contents and 'Free.' Since there is no real sibling alternative to route against, the omission is less costly, but it is still only implied rather than stated.

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

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

Annotations already declare readOnly, idempotent and non-open-world, so the safety profile is covered. The description adds two pieces of context not in the structured fields: 'Live' (real-time freshness of the readings) and 'Free' (no quota/cost), which is genuinely useful for deciding whether to poll it.

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 plus a one-word qualifier. The scope ('every marketplace') and the payload are stated first, with zero 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 no-parameter, read-only status endpoint with no output schema, the description conveys the three return dimensions an agent needs. It could state the shape of the per-marketplace result or whether it aggregates, but nothing essential 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?

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to disambiguate, and it correctly spends no words on inputs.

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

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

Names a specific resource (health, success rate, response time) and an explicit scope (every marketplace), which cleanly separates it from all the listing/sales siblings. It stops short of an explicit verb (e.g., 'returns' or 'checks'), but the deliverable is 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?

No when-to-use guidance, no preconditions, and no alternatives are named. The 'Live' qualifier implies freshness but nothing tells an agent when to reach for this versus the sibling marketplace 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?

Annotations only cover readOnly/openWorld/idempotent. The description adds genuinely new operational facts: 15-minute result caching, a billing model (1 request per completed search, cache hits included, failed searches free), cursor-based pagination and a 100-row cap. That is exactly the cost/caching context an agent cannot get from structured fields.

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

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

Three tight sentences, front-loaded with purpose, then pagination, then cost model, then a docs link. No filler or duplicated intent.

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 9-parameter search tool with full schema coverage, the description covers scope, paging, caching and cost, which is what an agent needs to call it correctly. With no output schema it could briefly hint at the response shape or result volume, but cursor/next_cursor behaviour is already handled by the schema.

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

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

Schema coverage is 100% and every parameter carries a rich description (range, defaults, enum values, currency semantics, cursor chaining rules). The description only restates keyword/country/row-limit at a high level, so it adds little beyond the schema – the baseline 3 is appropriate.

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 ... Depop active listings by keyword") plus the geographic scope (US, UK, Australia, Canada) and page granularity. Combined with the marketplace in the name, an agent can distinguish this from ebay_listings, vinted_listings, mercari_listings and the *_sold siblings without opening a 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?

Makes clear this returns active listings from one marketplace with cursor paging, and signalling "active" implicitly excludes sold-archive tools. It does not explicitly name an alternative or state when not to use it (e.g. when the user wants sold comps), so it falls short of 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 cover read-only/idempotent/open-world safety, but the description goes further with real operational facts: 15-minute result caching, a 1-request cost per completed search including cache hits, free failed searches, and the 200-vs-40 row page cap. Those are the kinds of billing and caching traits an agent cannot get from the annotations, though return-shape/pagination-truncation behavior is still unstated.

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 sentences, front-loaded with the core action and scope, then operational facts, then the docs URL. No filler, and each clause carries information an agent can act on.

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 12 params at full schema coverage and no output schema, the description supplies the missing non-parameter context (cost model, caching, page size, docs link). What it omits -- the shape of a returned listing row and multi-page traversal behavior -- is minor but nonzero given there is no output schema.

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

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

Schema description coverage is 100%, so the baseline is 3. The description still adds decision-relevant meaning beyond the schema by tying count to page yield ("up to 200 rows with count=200, or 40 without it") and noting a search costs one request at any size, which informs page-size choice rather than just restating the enum.

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 precise verb+resource+scope: "Search one page of eBay active listings by keyword" across a named set of marketplaces and sort orders. The word "active" cleanly separates it from the sibling ebay_sold tool, so an agent can route between them 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 useful operating context (one page at a time, page size cap, cached results) but never names an alternative or a condition that selects one. It never says when to prefer ebay_sold or a marketplace-specific sibling, so routing still has to be inferred from the name.

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

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld), and the description adds genuinely non-obvious behavior: 15-minute result caching, per-search request cost that is charged even on cache hits, free failures, and the maximum page size of 200 rows. That is exactly the cost/limit context an agent needs before calling, and it goes well beyond the structured fields.

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

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

Four sentences, front-loaded with the core purpose, then sizing, caching and cost, then the docs link. Every sentence carries distinct operational information and none restates the title or schema verbatim.

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 12-parameter read-only search with no output schema, the description covers the high-risk unknowns (cost, caching, page limits) and points to the docs URL. It stops short of describing the shape of a result row, which an agent with no output schema would benefit from knowing before committing requests.

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

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

Schema description coverage is 100% and the schema already explains q, page, sort, count, fields, country, condition, prices, category_id, buying_format and item_location in detail. The description's only parameter-level additions are the 200-vs-40 row behavior and the country count, so it does not meaningfully exceed the schema. Baseline 3 applies when the schema carries the load.

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 one page of eBay sold listings by keyword') plus the geographic scope (US or seven other countries). The word 'sold' cleanly separates it from the sibling ebay_listings, which covers active inventory, so an agent can route correctly 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 concrete operating context – page size semantics (200 rows with count=200, 40 without), 15-minute caching, and cost accounting (1 request per completed search including cache hits, failures free). It never explicitly names an alternative tool or when not to use this one, so the routing guidance is implied rather than stated.

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

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

Annotations already cover the safety profile (readOnly, idempotent, open-world), and the description adds substantial behavior on top: 15-minute cache, a request-cost model including cache hits, free failed searches, and a caveat that status is seller-set rather than a verified sale. These are billing and data-trust facts an agent cannot get from the schema or 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?

Two dense sentences front-load the purpose, then move through return fields, the status caveat, caching, and cost before the docs link. All content earns its place, though the cost and cache clauses make the sentence long and slightly crowded for a one-parameter tool.

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?

There is no output schema, so the description carries the burden and does so by naming the returned fields (description, condition, posted date, coordinates, delivery, photos). Combined with the caching, cost, and status caveats, an agent has everything needed to call and interpret this 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?

Schema description coverage is 100% for the single parameter, so the schema already documents the ID-or-URL format and length bounds. The description's 'by ID or URL' merely restates that, adding no format, validation, or resolution detail beyond the schema. Baseline 3 applies.

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

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

The description states a specific verb and resource ('Fetch one Facebook Marketplace listing') with an explicit cardinality ('one'), which cleanly separates it from the plural sibling facebook_listings. It also enumerates the returned fields, so an agent knows exactly what it gets. No ambiguity about what the tool does.

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 identifier source is only implied: the schema says the ID comes from 'search results', and the description says to fetch 'by ID or URL', which hints at a search-then-detail flow. However, it never names facebook_listings as the discovery counterpart or states when not to use this tool. Usage is inferable but not 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?

Goes well beyond the readOnly/openWorld/idempotent annotations: result cap (~24 rows), seller-ask price semantics, 15-minute cache, and a concrete billing model ('1 request per completed search, cache hits included; failed searches are free'). An agent can predict both cost and freshness 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?

Five short sentences, front-loaded with what/how/limits, then behavior, then cost, then docs. Every clause carries decision-relevant information 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 a 13-parameter, no-output-schema tool it covers scope, row caps, caching, billing, and a docs link. The main remaining gap is return-shape guidance (what a row contains, and when 'full' vs 'summary' matters functionally), though the fields enum in the schema partly covers this.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds interpretation the schema lacks: prices are asking prices (not sold), result counts vary by sort (24 vs ~15 for best_match), and the docs link. It stops short of describing the lat/lon vs zip mutual exclusion already spelled out in 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 precise verb+resource+scope: search Facebook Marketplace US active listings near a ZIP or point. The 'active' qualifier and 'No sold search' cleanly separate it from sold-price siblings like ebay_sold/mercari_sold without opening a 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 clear context (location-scoped active listing search) plus an explicit exclusion ('No sold search'), which is the key selection axis against the sold/aggregate siblings. It does not, however, name the alternative tools (e.g. facebook_item for a single listing, the *_sold tools) the way a 5 would.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so safety is covered. The description adds genuinely new context: the call is free and won't re-charge, which matters against paid marketplace search siblings. It stops short of saying what happens if the search is still pending after this call.

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 short sentences, with the core action stated first and the cost note second; nothing extraneous. "Free" and "it never charges again" are mildly duplicative, which keeps it from 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 should carry more of the return/behavior burden, but it doesn't say whether a still-collecting search yields another pending state or whether the agent should re-poll. For a two-parameter resumption tool this is adequate but leaves a real operational gap.

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

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

Schema description coverage is 100% — both request_id and the fields enum are documented in the schema itself. The description adds no syntax, format, or selection guidance beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description states a specific action (finish/resume a search that was still collecting) on a specific resource (a pending search result), which is distinct from the marketplace-listing siblings. It does not name the initiating search tool that produced the pending result, so the agent must infer which call it pairs with.

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?

"Finish a search that was still collecting when its tool call returned" gives a clear trigger condition for when to reach for this tool. What's missing is an explicit when-not (e.g., don't call it if you have no pending request_id) and any naming of the sibling search tools it follows.

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

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld), and the description adds genuinely non-obvious behavior: 15-minute result caching, per-search request billing including cache hits, free failed searches, cursor-based paging, and the 100-row page cap.

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

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

Four short sentences, each carrying distinct information (capability, pagination, caching, cost) with a doc link last. Front-loaded with the core capability and zero 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 11-parameter read tool with no output schema and rich annotations, the description covers capability, cost, caching, and paging well. It could say slightly more about the returned shape (e.g. that results carry a next_cursor), but the cost/cache disclosure is the higher-value content and it is present.

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

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

Schema description coverage is 100%, so the schema already documents all 11 parameters in detail. The description restates the 'up to 100 rows' cap and cursor paging but adds no syntax or semantic detail beyond the schema, so the baseline 3 applies.

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

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

The first sentence names a specific verb (Search), resource (Mercari US active listings), scope (one page), and primary input (keyword), plus a row cap. 'Active' implicitly distinguishes it from the sibling mercari_sold, and 'Mercari' separates it from the other marketplace_* 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 'search by keyword' and the cursor note tells the agent how to paginate, but there is no explicit when-to-use/when-not guidance and no mention of when to prefer mercari_sold or a different marketplace tool instead.

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, so the safety profile is covered. The description adds genuinely useful operational context not in the schema: 15-minute result caching, the 1-request cost (including cache hits), and that failed searches are free. It does not reveal anything contradictory.

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

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

Four short sentences, each carrying distinct information (scope, paging, caching, cost, docs link), with the core purpose front-loaded. 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 an 11-parameter, annotated read tool it covers paging, caching, cost, and links docs, which is strong. However, with no output schema, it never indicates what a sold listing row contains (sale price, sold date, condition), which is the point of a sold-listings tool, leaving a small completeness gap.

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

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

Schema description coverage is 100%, so every parameter is already documented in the schema. The description only loosely reinforces keyword scope and the 100-row cap; it adds no new parameter semantics beyond what the schema provides, so baseline 3 applies.

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

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

The description uses a specific verb and resource ('Search ... Mercari US sold listings by keyword') and bounds the scope ('one page ... up to 100 rows'). The 'sold' qualifier implicitly separates it from the sibling mercari_listings, but no sibling is actually named, so routing still requires inference.

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

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

It tells the agent how paging works (cursor) and the cost model, which implies when the tool is worth using, but it never states when to choose this over mercari_listings or the other marketplace sold tools. Usage context is implied rather than explicit.

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 read-only, idempotent, open-world behavior, and the description adds material context beyond them: a 15-minute cache TTL, the cost model (1 request per completed lookup including cache hits, failures free), and the semantic warning that status is seller-declared rather than a verified sale. This is exactly the operational detail an agent needs for budgeting and result 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?

Front-loaded with the core action and return contents, then billing/caching, then semantics and docs link — each sentence carries distinct information. Slight inefficiency: the cost sentence uses 'search' terminology for an item-fetch tool, which could momentarily confuse an agent.

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

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

With no output schema, the description competently enumerates returned fields and adds caching, cost, and status semantics, which is enough for correct invocation. Missing only explicit failure-mode behavior (e.g., what an invalid/expired ID returns) and rate-limit ceilings.

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

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

Schema coverage is 100% and the single q parameter is fully documented in the schema (listing ID, numeric item number, or offerup.com/item/detail/... URL). The description only echoes 'ID or URL' and adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

"Fetch one OfferUp listing by ID or URL" names a specific verb and resource, and the enumeration (description, posted date, condition, coordinates, shipping, photos, seller and vehicle details) tells the agent exactly what detail is returned. The singular 'one listing' contrasts implicitly but clearly with the sibling offerup_listings search 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?

The description gives clear context for use: fetch a single listing by ID or URL obtained from search results, with the caveat that 'status is the seller-set state, not a verified sale.' It does not explicitly name offerup_listings as the alternative for browsing/discovery, so the routing is inferred rather than stated.

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

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

Annotations already declare readOnly/idempotent/openWorld, and the description goes well beyond them: 15-minute result cache, one request charged per completed search including cache hits, failed searches free, ~50 rows per page, and that prices are seller asks rather than transaction prices. Cost and caching semantics are exactly the kind of behavior an agent cannot infer from structured fields.

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

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

Four short sentences with zero filler, and the most important framing (what is searched, geographic scoping, no sold data) is front-loaded ahead of billing and caching notes. Every sentence carries distinct, actionable information.

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

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

For an 18-parameter, high-complexity tool with no output schema, the description covers result size, pricing semantics, caching, and cost, which is most of what an agent needs. It leaves pagination/cursor usage entirely to the schema, which is acceptable but means the description does not fully stand on its own for multi-page retrieval.

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

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

Schema description coverage is 100%, so the schema already documents all 18 parameters in detail (radius fallback behavior, cursor chaining, sort enum limits, etc.). The description only restates that the search centers on a ZIP or point, adding no new syntax or format guidance beyond what the schema provides; baseline 3 is appropriate.

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 (Search) and resource (OfferUp US active listings) with scope qualifiers: one page, near a ZIP code or point, about 50 rows. It also explicitly excludes sold search, which matters because sibling tools like ebay_sold and mercari_sold exist. An agent can distinguish this from offerup_item (single item) and the *_sold siblings on name+description alone.

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

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

Gives clear context (active listings near a location, not sold data) and a useful exclusion ("No sold search"), so the agent knows this is a live-listing search. It does not, however, point to a specific alternative or spell out when a different search tool (eBay, Mercari, etc.) would be preferred; the routing is implied by the OfferUp name rather than stated.

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

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

Adds substantive traits the annotations don't carry: 15-minute result caching, request-cost accounting including cache hits and free failures, and cursor-based pagination. It stops short of disclosing result volume per page, rate limits, or error behavior beyond the 422 note embedded in 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?

Four tight sentences plus a docs link, front-loaded with the core action and scope before cost and pagination details. No filler or repeated schema content.

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 scope, pagination, cost and caching for a 9-parameter read tool with no output schema. The main omission is any hint of what a page returns (e.g. next_cursor availability or result counts), which matters slightly given there is no output schema to fall back on.

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

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

Schema description coverage is 100%, so the schema already documents every parameter including enums, ranges, currency and the 422 condition rules. The description only reinforces cursor/pagination behavior, adding little beyond the structured fields — baseline 3 applies.

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

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

States a specific verb and resource ('Search one page of Poshmark active listings by keyword'), plus the two supported marketplaces and the sort dimension. The word 'active' implicitly distinguishes it from poshmark_sold, so an agent can route between 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 operational context ('Pages use a cursor', 15-minute cache, 1 request per completed search, failures free) but never explicitly states when to choose this over poshmark_sold or the other marketplace listing tools. Usage is implied by the word 'active' rather than spelled out.

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 a safe, idempotent, open-world read, and the description layers on real behavioral detail beyond them: cursor-based pagination, a 15-minute result cache, per-search request billing that includes cache hits, and free failed searches. That is exactly the operational context an agent needs before spending requests.

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?

Five short sentences: purpose first, then pagination, caching, billing, and a docs link. Each sentence carries distinct information and nothing is padded, though the cursor sentence partially overlaps the schema and the docs URL is an added tail.

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

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

With no output schema, the description still gives the agent the essentials: what a call returns (one page of sold listings), how paging works, and what it costs. It does not describe the shape of result rows or how the fields=summary/full toggle affects output, a minor remaining gap given the schema covers parameters.

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%, with the schema itself documenting q, page, cursor, fields, country, condition, and price bounds in detail. The description only restates keyword search and country in passing, adding no syntax or format meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Search one page of Poshmark sold listings by keyword') plus scope ('on Poshmark US or Canada'). This clearly distinguishes it from the sibling poshmark_listings (active listings) and from other marketplaces' *_sold tools.

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 'sold listings' framing implies this is the tool for sold/comparable pricing data versus poshmark_listings, and the cursor/caching notes set invocation context. However, no sibling is named and there are no explicit when-to-use/when-not conditions, so the agent must infer the choice.

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 read-only, open-world, idempotent, so the bar is lower; the description still adds substantial operational context: a hard ceiling of at most five rows, an explicit statement that this is not complete history, a 15-minute cache window, and a precise request-cost model including that cache hits count and failures are free. That is exactly the behavior context annotations cannot carry.

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

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

Four short sentences, purpose front-loaded, and each remaining sentence earns its place by disclosing a distinct constraint (row cap, cache TTL, cost model). No filler or restatement of the tool name.

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

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

For a simple two-parameter read tool with no output schema, the description covers purpose, data coverage limits, caching, cost, and a docs link. Return-value shape is only indirectly addressed via the fields enum, but nothing critical to calling 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 100% and both parameters are self-documented, including the enum for 'fields', so the schema does the heavy lifting. The description adds only the notion of an 'exact' product ID, which is already stated in the q property 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?

States a specific verb and resource (fetch recent individual sales) and constrains the scope to an 'exact product', which implicitly separates it from tcgplayer_search. An agent can tell immediately this returns sold-transaction rows for one known product ID rather than search results.

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 the 'exact product' framing and the warning that this is not a complete sales history, but no alternative sibling is named and no explicit when-to-use/when-not rule is given. Adequate but leaves routing to inference.

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

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

Annotations already cover readOnly/openWorld/idempotent, but the description adds real operational context beyond them: 15-minute caching, a cost model (1 request per completed search, cache hits billed, failures free), and a docs link. It stops short of auth or rate-limit details, so not a 5.

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

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

Front-loaded with the core action, then terse cost/cache facts and a docs pointer in one dense sentence. Every clause carries information, though the semicolon-chained cost sentence is slightly packed.

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

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

With no output schema, the description usefully characterizes the return payload and adds caching/cost behavior, and annotations carry the safety profile. Pagination behavior is left to the schema, but nothing an agent needs to call 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 description coverage is 100%, so the schema already documents all five parameters including the q format, pagination, count cap, and product_line naming. The description only alludes to 'by keyword' and adds no syntax or format beyond the schema, so the baseline 3 applies.

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

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

States a specific verb+resource ('Search TCGplayer products by keyword') and enumerates what comes back (catalog identity, market-price estimate, active seller asks), which implicitly separates it from the sold-comps sibling tcgplayer_sales. An agent can identify the tool's job without opening the 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?

Usage is implied by 'search products by keyword' and the return contents (current asks vs sold data) hints at when it beats tcgplayer_sales, but the description never names an alternative or an explicit when-not condition. Adequate but leaves routing to inference.

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

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

Annotations already cover read-only, idempotent and open-world behavior, and the description goes further by disclosing a 15-minute cache and an explicit cost model ('each completed search costs 1 request, cache hits included; failed searches are free'). It also warns that 'Status is not a verified sale', a useful data-semantics caveat. Minor ambiguity: the cost sentence says 'search' in a tool that fetches a single item, which slightly muddies the billing statement.

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 compact sentences, front-loaded with the core action and payload, then behavioral caveats, then the docs link. 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?

With no output schema, the description usefully enumerates the returned fields, and it covers caching and cost. It stops short of error/failure behavior (e.g., what a not-found or rate-limited response looks like) and doesn't restate that country should match the originating search site beyond the schema note.

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

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

Schema description coverage is 100%, so both q and country are already fully documented, including the ID-or-URL formats and the per-country site list. The description's 'by ID or URL' merely restates the schema, so baseline 3 applies.

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

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

States a specific verb and resource ('Fetch one Vinted listing by ID or URL') and enumerates the returned payload (description, condition, brand, size, colour, category, photos, seller rating). The singular 'one' implicitly separates it from the sibling vinted_listings search tool, but the alternative is never named.

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

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

Usage is implied rather than stated: the q parameter note ('Vinted item ID from search results') and the country hint ('Use the country you searched') tell the agent this follows a search, but there is no explicit when-to-use/when-not guidance or named alternative such as vinted_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?

Beyond the readOnly/idempotent annotations it discloses non-obvious operational traits: 15-minute result caching, a 1-request cost even on cache hits, failed searches being free, and that prices are seller asks rather than transaction prices. This is exactly the context annotations cannot convey.

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

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

Four short sentences, front-loaded with what the tool is and what it is not, followed by cost/caching facts. No filler and nothing buried.

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 10-parameter search tool with no output schema and full schema coverage, the description covers scope, geographies, pagination size, caching and cost. It stops short of describing result shape or how 'next_page' terminates, though the schema's page description partly covers that.

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

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

Schema description coverage is 100%, so every parameter is already documented (including currency behaviour, brand/category ID lookups, and next_page). The description adds almost nothing parameter-specific beyond repeating that searches span US/UK/EU sites. Baseline 3 applies.

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

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

States a specific verb and resource ('Search one page of Vinted active listings by keyword') and scopes it to a geography. The 'No sold search' clause disambiguates it from sold-data siblings such as ebay_sold, poshmark_sold and mercari_sold without needing the 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?

Gives a clear exclusion ('No sold search'), pagination workflow ('96 rows a page', implied by the schema's next_page), and a docs URL. It never names a concrete alternative sibling for sold data, so routing is inferred rather than stated.

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

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

Annotations only cover the safety profile (readOnly, idempotent, openWorld), so the description's disclosure of 15-minute result caching, the 1-request cost including cache hits, and free failed searches is genuinely additive operational context an agent cannot get elsewhere. It stops short of 5 because it does not describe the response shape or whether this is a synchronous call versus a job requiring get_result.

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 and hard constraint ('No sold search') are front-loaded in the first two sentences, followed by caching and cost facts, then the docs link. Every sentence carries information, though the cost/caching detail is packed densely enough that it borders on reference material rather than tool guidance.

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 13-parameter search endpoint with no output schema, the description covers the things an agent most needs before calling: currency scope, pricing semantics, cache staleness, and per-call cost. The remaining gap is the return contract (row shape, cursor usage in practice, sync vs. polled via get_result), which the absence of an output schema leaves partly unaddressed.

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

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

Schema description coverage is 100% with 13 well-documented parameters, so the schema already carries the semantics of q, sort, country, price bounds, cursor, etc. The description only echoes a few of these (up to 24 rows, US/Canada, seller asks) without adding syntax or format guidance the schema lacks. Baseline 3 applies when the schema does the heavy lifting.

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 Whatnot Buy It Now active listings) plus scope (one page, up to 24 rows, US or Canada sellers). The clause 'No sold search' explicitly carves out the sold-data variant, distinguishing it from siblings like ebay_sold, mercari_sold and poshmark_sold without the agent 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?

'No sold search' is a clear when-not signal, and 'Prices are seller asks' tells the agent these are not transaction prices, which matters for comparability against the *_sold siblings. It does not name an explicit alternative tool or spell out when to prefer another marketplace endpoint, so it stops short of a 5.

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