Resollo Agent API

Reserve a Resollo product

orders.place

Destructive

Creates a RESERVATION for the given product -- it does NOT complete a purchase and does NOT charge any payment method. After calling this tool, a human (the buyer) MUST log in to Resollo and complete payment manually through the normal checkout flow (Stripe-hosted checkout page, or cash-payment confirmation). Never tell the user their order is 'placed' or 'paid' after calling this tool -- tell them the item is reserved and they need to complete payment themselves at resollo.com to finalize it. Only fixed-price listings can be reserved this way (not auctions). Requires an 'Authorization: Bearer ' header -- generate a key from the Resollo profile page. The buyer must have explicitly approved this specific order before you call this tool (confirm must be true).

Input Schema

TableJSON Schema

Name	Required	Description
`comment`	No	Optional note to the seller, attached to the order chat.
`confirm`	Yes	Human-confirmation gate. Must be true, and only set it after the user has explicitly approved this specific order having seen the payment-safety text. An agent must never set this on its own initiative.
`currency`	No	Informational only, used solely to detect a currency mismatch worth surfacing to the buyer (payment_safety.currency_mismatch). Does NOT change what gets charged -- the order is always recorded and settled in the listing's own native currency regardless of this value.
`quantity`	No	Units to reserve (1-20, default 1).
`product_id`	Yes	The uuid of the fixed-price listing to reserve.
`address_key`	No	Key of one of the buyer's own saved addresses (never a free-text address). Required unless shipment_method is `personal`; defaults to the buyer's active address when omitted.
`payment_method`	Yes	How buyer and seller will settle payment off-platform. Must be one the seller accepts (see get_product.seller.accepted_payment_methods).
`shipment_method`	Yes	How the item will be handed over. Must be one the seller accepts (see get_product.seller.accepted_shipment_methods).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`state`	Yes
`product`	Yes
`order_id`	Yes
`quantity`	Yes
`created_at`	Yes
`total_price`	Yes
`payment_method`	Yes
`payment_safety`	Yes
`shipment_method`	Yes

TDQS

A4.5/5.0

Behavior5/5

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

The description goes well beyond the annotations by explaining the reservation semantics: no payment is charged, the buyer must complete payment through Resollo's checkout flow, and the agent must never tell the user the order is placed or paid. It also discloses auth requirements and the mandatory confirm gate. These behavioral details are not derivable from the annotations alone.

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?

The description is dense but every sentence earns its place: it clarifies what the tool does, what it does not do, what the user must do afterward, what the agent must not say, constraints on listing type, required authentication, and the confirmation gate. The most important distinction (reservation vs purchase) is front-loaded in the first sentence.

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?

Given the tool's complexity, the description fully covers the operational context: post-call buyer steps, auth requirements, safety guardrails, listing-type restrictions, and confirmation obligations. With an output schema present, the description does not need to explain return values, and nothing essential to calling this tool correctly 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?

Schema description coverage is 100%, so the baseline is 3. The description adds some workflow-level context around confirm and product eligibility, but most parameter meaning is already thoroughly documented in the schema, such as confirm being a human-gate boolean, payment_method being off-platform settlement, and currency being informational only. The description does not materially enrich the individual parameter semantics beyond the schema.

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: 'Creates a RESERVATION for the given product.' It immediately distinguishes this from a purchase by stating it does NOT complete a purchase or charge a payment method, and it scopes the tool to fixed-price listings only, excluding auctions. This clearly separates orders.place from purchase/checkout sibling tools.

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

Usage Guidelines4/5

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

The description gives clear context for when to use the tool: to reserve a fixed-price product, with the buyer required to finalize payment manually afterward. It also states an important exclusion ('not auctions') and caller requirements such as the Authorization header and explicit buyer approval. It does not explicitly name alternative tools like orders.checkoutLink or offers.make, so it stops short of fully routing between siblings.

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?