Give your listing a factual starting point

product-describe turns a product name and supplied context into copy for a retail listing. You get a description alongside selling points, plus fields for suggested titles and product features.

The boundary is your input. The endpoint's instructions require copy to stay within the facts you supply. Treat the result as a draft to check against those facts before publishing.

For an agent routing a merchant's request, the fit is specific: the merchant has product details and wants listing copy. A request to discover missing specifications needs a separate step before this call.

Build the product context

Send a JSON body using POST. Only product is required: a nonempty string of up to 2,000 characters. Use the product's name or a short description.

The optional fields let you separate factual details from writing direction:

  • category identifies the kind of product you're selling.
  • audience describes the intended reader.
  • attributes contains known features as an array of strings.
  • tone gives the copy a voice, such as “plain and practical.”

Here's an example request body for a fictional notebook: 

{
  "product": "Field Notes A5 notebook",
  "category": "notebooks",
  "audience": "people taking handwritten meeting notes",
  "attributes": [
    "A5 size",
    "160 lined pages",
    "Hardcover",
    "Elastic closure"
  ],
  "tone": "plain and practical"
}

Keep facts separate from aspirations. “People taking handwritten meeting notes” tells the endpoint who'll read the listing. It doesn't establish paper quality or ink compatibility.

And “plain and practical” controls wording. It doesn't add evidence for a performance claim.

The endpoint accepts up to 20 nonempty string attributes. Put the facts you want represented within that limit, especially details that distinguish this item from another variant. If you've got a 160-page edition and a 240-page edition, each request needs the correct page count.

Read the returned copy by field

The response echoes product and provides description. It also includes selling_points and key_features as arrays, a marketing_angle string, and a suggested_titles array.

This illustrative response excerpt shows how the notebook facts can become listing copy. It's an example, not a recorded paid response: 

{
  "product": "Field Notes A5 notebook",
  "description": "Take handwritten meeting notes in an A5 hardcover notebook with 160 lined pages. An elastic closure keeps the notebook closed between uses.",
  "selling_points": [
    "A5 format for handwritten notes",
    "160 lined pages",
    "Hardcover format",
    "Elastic closure"
  ],
  "key_features": [
    "A5 size",
    "160 lined pages",
    "Hardcover",
    "Elastic closure"
  ],
  "marketing_angle": "An A5 notebook for people who take meeting notes by hand.",
  "suggested_titles": [
    "Field Notes A5 Hardcover Notebook",
    "Field Notes Notebook with 160 Lined Pages"
  ]
}

Map description to the listing's main copy field. Use selling_points where your storefront accepts bullets, after checking its length limits.

Suggested titles need review too. A marketplace's title policy still applies, and this request doesn't include a marketplace-specific format.

But don't treat key_features as newly verified product data. Compare those entries with the supplied attributes before writing them into a catalog. Keep the original specifications available so a reviewer can trace each claim.

Put the call inside a listing workflow

product-describe is listed at 0.01 USDC per call, paid through x402 on Base mainnet. Have your payment-capable client inspect the payment requirements before authorizing the request.

Save the returned draft with the exact input used to create it. That gives your editing step a direct comparison: did “160 lined pages” survive correctly? Did the copy add a claim about recycled paper that nobody supplied?

Check factual additions explicitly. The endpoint is instructed to avoid invented specifications, but your publishing step still needs to enforce that boundary.

If a merchant later confirms the notebook has 100 gsm paper, add that fact to attributes before requesting revised copy. Leave unsupported details out of the request, and remove unsupported claims from the draft before it reaches the listing.