Resollo Agent API

Search Resollo products

products.search

Read-only

Search active, publicly available product listings on the Resollo marketplace. Use this to browse or filter by keyword, category, price range, currency, or seller location. Returns only currently active, purchasable listings (never sold, expired, or moderation-hidden ones). For full details on one specific product you already have the ID for (including its Semantic Profile fields -- suitable_for, not_ideal_for, target_audience, key_strengths, evokes, is_similar_to -- which this search tool does NOT return), call products.get instead. Results are paginated via next_cursor; pass it back as the cursor argument to fetch the next page. No authentication required.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`q`	No	Free-text search across the listing's canonical name and description.
`sort`	No	Result ordering. Never influenced by paid placement.	newest
`limit`	No	Maximum number of results to return per page (1-50, default 20).
`cursor`	No	Opaque pagination cursor from a previous response's next_cursor.
`category`	No	Numeric top-level category id (see getMarketplaceInfo.categories). Subcategory ids are accepted but rolled up to their top-level parent in the response.
`currency`	No	ISO 4217 code used for price filtering and each result's converted_price. Defaults to USD. Must be one of getMarketplaceInfo.currencies.
`location`	No	Comma-separated seller-location filters. Each entry is a 2-letter ISO country code ("HU") or a "COUNTRY:REGION" pair ("HU:BU"). Reflects the seller's profile location, not a per-listing field.
`price_max`	No	Maximum price in the resolved `currency`.
`price_min`	No	Minimum price in the resolved `currency` (converted price, not the seller's native currency).
`seller_id`	No	Restrict results to one seller's listings. The uuid is the seller.id from any search or getProduct result.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`count`	Yes
`products`	Yes
`next_cursor`	Yes

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses that results are limited to active, purchasable listings (excluding sold, expired, or moderation-hidden), pagination behavior via next_cursor, no authentication required, and that sort order is never influenced by paid placement. These are meaningful behavioral traits not present in 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.

Conciseness5/5

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

Four sentences cover purpose, use cases, the key sibling relationship, pagination, and authentication. Information is front-loaded, and every sentence adds either essential scope or behavioral guidance; there is no filler or repetition of schema fields.

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

Completeness5/5

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

With a rich output schema available and readOnlyHint=true, the description fully situates the tool: what it filters, what it excludes, pagination mechanics, auth expectations, and where to go for deeper per-product data. Nothing needed for correct invocation is missing.

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

Parameters3/5

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

The input schema provides 100% description coverage for all 10 optional parameters, including defaults, formats, and constraints. The tool description adds only general filter categories already reflected in the schema, so it does not substantially elevate parameter understanding beyond the baseline.

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

Purpose5/5

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: 'Search active, publicly available product listings on the Resollo marketplace.' It clearly defines the scope ('browse or filter by keyword, category, price range, currency, or seller location') and explicitly contrasts with products.get, so an agent can distinguish it from the sibling tool without opening schemas.

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

Usage Guidelines5/5

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

The description gives explicit when-to-use instructions ('Use this to browse or filter...') and a direct when-not-to-use rule: 'For full details on one specific product you already have the ID for... call products.get instead.' It also names what this tool does NOT return, which prevents misuse.

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

All Resollo Agent API tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation5/5

Each tool targets a distinct resource and action (marketplace metadata, offers, orders, products, questions, reviews, sellers), so an agent can reliably select the right one. The few same-domain tools (products.get/search, sellers.get/status) are clearly separated by their descriptions.

Naming Consistency4/5

Names mostly follow a clear domain.action pattern (products.create, questions.ask, orders.place), with domain prefixes making the surface predictable. Minor deviations like orders.checkoutLink (camelCase) and noun-style endpoints (marketplace.info, orders.status, sellers.status) keep it from being fully uniform.

Tool Count5/5

Fifteen tools is a well-scoped size for a marketplace API; each tool supports a distinct part of browsing, buying, selling, or marketplace reference data. No obvious redundant tools or bloated surface.

Completeness3/5

The tool set covers a wide marketplace workflow, but there are notable gaps: no endpoint to list the authenticated user's own orders, offers, or listings, and no product update/delete/activate after draft creation. Agents can work around some gaps via returned IDs and manual web steps, but certain user requests will dead-end.

Resources

Need Help?