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

No annotations are supplied, so the description must carry the behavioral load; 'List' correctly signals a read-only lookup and the examples clarify the payload shape. It does not disclose whether max_values caps values per aspect or overall, whether results are cached or rate-limited, or how large a category's aspect set can be.

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

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

A single front-loaded sentence with the resource and purpose stated first; the parenthetical examples are somewhat long but they meaningfully illustrate what an 'aspect' is, so they earn their place.

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

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

An output schema exists, so return values need not be described, and the read-only nature is implied. However, with no annotations and zero schema coverage, the undocumented max_values parameter leaves a real gap an agent must guess at.

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

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

Schema description coverage is 0% for two parameters, and the description compensates only partially: '(e.g. ... for a category)' implies category_id identifies the category, but max_values is never mentioned, leaving unclear whether it limits values per aspect or total values returned.

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: lists item-specific aspects and their common values for a category, with concrete examples (Size, Inseam, Voltage, Phase) and the downstream purpose ('for use in search aspects filters'). It is clearly distinguishable from siblings like suggest_ebay_categories, though it never names or contrasts with them explicitly.

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

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

Usage is only implied: the phrase 'for use in search aspects filters' hints that this should be called before search_ebay to build aspect filters, but there is no explicit when-to-use, no when-not-to-use, and no named alternative for discovering categories versus aspects.

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

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

No annotations are supplied, so the description carries the full burden; it enumerates what is returned, which signals a read-only listing fetch. It says nothing about permissions, authentication, rate limits, or whether the call works for ended/removed listings — behavioral gaps that matter without 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 tight sentences with the payload contents front-loaded and the identifier syntax immediately after. Minor waste in the parenthetical field list (size, measurements, brand, model, MPN), which largely restates what the output schema already exposes.

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

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

Return-shape detail is redundant given an output schema, and the description omits the one genuinely non-obvious control (`description_chars` truncation) plus any failure modes for invalid or ended item ids. Adequate to call correctly for the common case, but incomplete for the schema it ships with.

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

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

With 0% schema coverage, the description does valuable work by explaining that `item` accepts a RESTful id (v1|...|0), a numeric legacy id, or an ebay.com/itm/ URL. However, the second parameter `description_chars` (default 4000) is never mentioned anywhere, leaving a real truncation behavior undocumented.

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

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

States a specific verb+resource ('Full listing details' for a single item) and the second sentence clarifies the identifier type, making it clearly distinct from search_ebay (discovery) and get_ebay_item_photos (media subset). An agent can route to it 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 rather than stated: 'full listing details' suggests fetching one known listing, in contrast to the search siblings. There is no explicit when-to-use/when-not guidance and no mention that a search step is typically required to obtain the item id.

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

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

No annotations exist, so the description carries the full burden. It does disclose useful behavior: photos are returned as images, indexing is 0-based with 0 as the main photo, paging is via start, and max_px is bounded to 512-1600. It says nothing about how many photos a listing may have, failure modes, or request costs.

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, front-loaded with the purpose followed by operational hints. The telegraphic "Page with start" phrasing is slightly clipped 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?

An output schema exists, so return-value explanation is not required, and the image-return behavior is covered. However, the required item parameter and max_photos remain unexplained, and there is no route to the closely related zoom tool, leaving gaps for a 4-parameter tool with zero annotation coverage.

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

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

Schema description coverage is 0%, so the description must compensate for four undocumented parameters. It explains start (paging) and adds a real constraint for max_px (512-1600, beyond the default-1024 schema), but never explains what the required item identifier is or what max_photos controls.

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

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

The description names a specific verb and resource ("Download a listing's photos") and states the result form ("return them as images for visual inspection"). It does not distinguish itself from the sibling zoom_ebay_photo, which also deals with eBay photos, so sibling differentiation is only partial.

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 and no mention of alternatives such as zoom_ebay_photo or search_ebay_by_image. The phrase "for visual inspection" hints at the intent, but an agent must infer the selection criteria itself.

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

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

No annotations are supplied, so the description carries the full burden. It does disclose two non-obvious behaviors: buying_options defaults to fixed_price + auction (deviating from eBay's Buy It Now default), and local_pickup_radius_miles is measured from the server's EBAY_POSTAL_CODE. It says nothing about pagination via offset, what show_refinements returns, rate limits, or auth/error behavior, which is a meaningful gap for a 15-parameter tool.

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

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

The core capability is front-loaded in one sentence and the rest is scoped to individual parameters with no filler. Minor inefficiency: sort's 'distance' enum and offset pagination are never tied into the surrounding guidance, so the notes are not fully 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?

An output schema exists, so return values needn't be spelled out, and the size/format tips are appropriate for a large search tool. Still, for a 15-parameter search tool with no annotations, the description leaves pagination, sort/location interaction, and tool-selection versus siblings 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 coverage is 0% with 15 parameters, so the description must compensate, and it only covers aspects (including the '|' = OR syntax and category_id dependency), buying_options, local_pickup_radius_miles, show_refinements, and limit. The other parameters (sort, condition, price bounds, item_location_country, offset, contact_sheet, free_shipping) get no explanation, though most are self-descriptive by name.

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 ('Keyword search of active eBay listings') plus the result shape (numbered results, thumbnail contact sheet). The word 'keyword' implicitly separates it from the sibling search_ebay_by_image, but no sibling is named explicitly, so it stops short of a 5.

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

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

Gives real in-tool guidance: aspects require category_id, use show_refinements=True to discover valid names/values, limit is best kept 1-50. It does not say when to pick this tool over search_ebay_by_image or suggest_ebay_categories, nor any when-not conditions, so usage is implied rather than routed.

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

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

With no annotations, the description carries the burden and delivers real behavioral facts: the API is experimental, the source inputs are mutually exclusive (one and only one), and results include a contact sheet. It omits operational details such as rate limits, cost, or what happens if multiple sources are supplied.

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

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

Three tight sentences with the core constraint front-loaded and zero filler; the parenthetical notes earn their place by clarifying input formats. Slightly dense for a 13-parameter tool, but nothing is wasted.

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

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

The output schema covers return values and the description covers the source-selection rule, which is the main complexity. However, for a 13-parameter tool with zero schema documentation, the filtering and pagination parameters are left entirely unexplained, which is a meaningful gap for an agent composing a query.

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

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

Schema description coverage is 0% across 13 parameters, so the description must compensate, and it does for the most important ones: image_path (local file), image_url, similar_to_item (item id or URL, uses main photo), and category_id's relevance impact. The remaining filters — aspects, condition, buying_options, min/max_price, sort, limit, offset, contact_sheet — get no explanation beyond their names, and "aspects" in particular is opaque.

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?

"Visual-similarity search (eBay's experimental searchByImage)" states a specific verb and a distinct resource, and the visual-similarity framing inherently separates it from the keyword-based sibling search_ebay. An agent can pick this tool 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?

The description gives the critical selection rule — supply exactly one of image_path, image_url, or similar_to_item — and a quality tip (category_id greatly improves relevance). It stops short of explicitly naming when to prefer this over search_ebay or get_ebay_item_photos, so there is no full when-not guidance.

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

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

No annotations are supplied, so the description carries the burden; "suggest" implies a non-mutating lookup, but that is only implied. It does not state how many suggestions come back, whether results are ranked or confidence-scored, or whether authentication is required. The presence of an output schema excuses it from explaining return values, keeping this at a middling score.

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, front-loaded with the purpose and followed by the downstream instruction; there is no filler and no redundancy.

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 one-parameter lookup tool with an output schema, the description covers what the tool does, what to pass in, and what to do with the result. Only the shape of the returned suggestions and any reliability caveats are left implicit.

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

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

The single query parameter has 0% schema description coverage, and the two bracketed examples ("men's waxed cotton jacket", "hydraulic gear pump") do real work here, showing the input is a free-form natural-language product description rather than a category name or ID. It still does not mention constraints such as length limits or language.

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 verb and resource ("suggest eBay category ids") and clarifies the input with two concrete examples, so the agent can tell it is a lookup-style categorizer rather than one of the search_ebay retrieve tools. It stops short of naming a sibling explicitly, which would earn a 5.

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

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

"Use the id as category_id in searches and aspect filters" tells the agent both the downstream purpose and the workflow it plugs into (search_ebay, get_ebay_category_aspects). No explicit when-not guidance or prerequisites are given, but the usage context is clear.

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

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

With no annotations, the description carries full behavioral burden and does disclose the resolution ceiling and cropping semantics. It omits prerequisites (must the item/photos be fetched first?) and says nothing about what the crop returns or whether max_px overrides the stated 1600px full-resolution behavior.

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

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

Two sentences, zero waste: the action and motivation come first, then the box syntax with a concrete example. Every phrase earns its place and the hard-to-guess detail is front-loaded.

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

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

The output schema exists, so return values needn't be described, and the box semantics are fully covered. Gaps remain around how item and photo_index are sourced and what max_px does relative to the 1600px claim, which matters for a four-parameter tool with no annotations.

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

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

Schema description coverage is 0% across four parameters, so the description must compensate. It does an excellent job on the hardest parameter, defining box as fractional [x0,y0,x1,y1] with a worked example, but leaves item, photo_index, and max_px entirely unexplained, including the potential tension between max_px's default of 1400 and the advertised 1600px full resolution.

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

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

The description gives a specific verb and resource ("Crop one listing photo") plus an explicit resolution ceiling (1600px), so it is unmistakable what the tool does. It does not name the sibling it pairs with (get_ebay_item_photos), leaving the agent to infer which call supplies the photo to crop.

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 clearly states the situations that call for zooming: reading tags, labels, nameplates, serial plates, or inspecting a flaw. There is no explicit when-not guidance and no named alternative, so it stops short of a full routing rule.

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