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

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

AddedAug 27, 2026

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.2/5.0

Disambiguation5/5

Each tool is cleanly grouped by resource (marketplace, offers, orders, products, questions, reviews, sellers) and within a group every action is distinct. There is no real overlap between e.g. orders.place, orders.checkoutLink, and orders.status, or between offers.make and offers.respond.

Naming Consistency4/5

Tool names follow a predictable resource.action pattern with lowercase verb-like second segments (offers.list, products.create, questions.ask). Minor deviations exist: orders.checkoutLink uses camelCase and sellers.listings is a noun rather than a verb, but the overall convention remains easy to infer.

Tool Count3/5

18 tools sits in the 16-25 borderline-heavy range. The marketplace scope is broad enough that most tools feel justified, but the count is slightly above the ideal well-scoped band and could be seen as heavy for a single API server.

Completeness3/5

The server covers core marketplace browsing, product draft creation, order placement, offers, questions, and reviews well. However, there are notable lifecycle gaps: products can be created but not updated/deleted/activated via API, orders have no dispatch/confirm/receive actions, and offers have no cancel action, with several operations pushed to the web UI.

Resources

Need Help?