Raise a bug with FLUF support. Two situations call for it, and the second is the one that gets missed:

1. The user describes a problem with FLUF that you can't resolve yourself.

2. YOU hit the problem — a FLUF tool keeps failing, returns something that contradicts itself or the user's account, or leaves you unable to finish the task. The user never has to mention it first, and being stuck is not a reason to keep retrying quietly. File the report, then tell the user what you filed. KEEP IT SHORT. This arrives as a direct message in a human inbox: a title, two or three sentences, and the identifiers. Long reports get read last. Don't file for things the user can fix themselves (expired token, lapsed plan, a channel needing reauthorisation) — tell them the fix instead. Their account identity is attached automatically — don't ask for it. Replies arrive in the user's FLUF inbox.

List the authenticated seller's FLUF products. Each row carries a vid — the product handle the crosslist tool takes — plus title, price, stock, source channel and the channels it is already live on.

IMPORTANT for audits and counts: status is what the channel last told FLUF, not a live check, so an ended listing keeps reading 'active'. Each row also carries liveness ('confirmed' | 'unconfirmed' | 'unknown'), last_seen_at and last_seen_age_hours — when a channel scan last returned that listing. When counting a seller's live catalogue, or deciding whether two rows are duplicates, pass liveness: "confirmed" and say so. Do not filter the rows yourself and quote total — total counts everything the filter did not exclude, so an unfiltered call reports the seller's whole index history as if it were live. Two 'active' rows for the same item are usually one listing that ended and its relist, not a duplicate — channels mint a new listing id on relist. Never advise ending a listing on the strength of this tool alone; tell the seller to confirm on the channel first.

Get the seller's orders across every connected marketplace, in one unified shape.

List existing FLUF products on one or more marketplaces. IMPORTANT: this is not always synchronous. Some channels are completed by the seller's own browser extension, so they come back queued and go live minutes later — report that honestly rather than telling the user the item is listed. Read status per channel in the response. Repeats of the same (product, channel) pair within 30s are ignored as accidental double-submits.

List the marketplace channels available on this account: which are already connected, and which this seller's plan can list to. Call this before crosslist rather than guessing channel names — the roster differs per account and changes over time.

Ask Intesa, the FLUF assistant that runs inside the seller's own account. Intesa can do things this MCP server cannot: diagnose why a channel stopped syncing, explain a listing error, run bulk jobs, search the seller's history and read FLUF's support docs. Prefer the direct tools (list_products, crosslist, get_orders) for simple reads and writes — they are faster and cheaper. Reach for this when the question is diagnostic or open-ended, e.g. 'why did my last five Vinted listings fail?'. Replies can take up to a minute because Intesa runs its own multi-step tool loop.

Delete FLUF products. By default only the FLUF record is removed and every marketplace listing is left untouched; pass also_delist: true to also end the listings on every marketplace they are live on, which cannot be undone. Deleted FLUF records go to Recently Deleted in the dashboard and can be restored for 60 days. Always confirm with the user first and list which products will be deleted (by title or id). Suited to sold-out or obsolete inventory. Requires Pro plan (API tokens on lower plans are read-only and the request will return a 403 'plan limit' error).

List the seller's review drafts: listings FLUF has prepared but not sent. A failed draft is one a marketplace refused for a reason the seller can fix — the reason says what it objected to, and fields holds every value with editable: true on the ones that can be changed (a select field lists its options). A pending_review draft is simply waiting for a go-ahead. Read a draft, decide the corrected value from the product itself (never invent one), then call approve_draft with the edits. Once the item is live on that marketplace its draft leaves this list on its own.

Approve a review draft and send it to the marketplace, optionally correcting fields first — the way to resolve a failed draft. Read the draft with list_drafts before calling this, take the new value from the product's own details (its measured size, its actual brand), and confirm with the user before you send: this publishes a real listing. state comes back as listed (live now), pending (accepted, publishes shortly — do not resend) or failed (the marketplace refused again; message says why and draft is the refreshed draft to try once more). Requires Pro plan (API tokens on lower plans are read-only and the request will return a 403 'plan limit' error).