X Marketplace Seller MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DATA_DIR | No | Directory used to store the JSON ledger for local/self-hosted use when no Blob token is set. Defaults to `~/.x-marketplace-seller-mcp/`. | |
| X_USER_ACCESS_TOKEN | No | Your own X OAuth 2.0 user-context access token, required only to enable posting listings (`tweet.write`) and sending DMs (`dm.write`). Can alternatively be supplied via the `x-x-user-access-token` header in hosted mode. Without it, the tools only draft and never post. | |
| BLOB_READ_WRITE_TOKEN | No | Vercel Blob read/write token. When set, hosted data is stored in a private Vercel Blob store at `<app>/<tenant>/<file>.json` with ETag-based optimistic concurrency instead of local JSON files. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_listingA | Create a sale listing: item, condition, asking price, private floor (lowest you'll accept) and ceiling, photos (≤4 URLs/paths), pickup/delivery, payment methods and negotiation rules. Returns a drafted X post (≤280 chars). Stored locally; nothing is posted. |
| list_listingsC | List your listings by status. |
| update_listingC | Change price, floor, rules, status (e.g. withdrawn) or photos. Re-drafts the post text. |
| draft_buyer_replyA | Paste a buyer's message: detects intent (availability, offer, condition, logistics, hold, payment), extracts any offer, flags scam patterns, runs the negotiation engine within your floor/ceiling and rules, and drafts a reply. The thread is tracked for negotiation rounds. Returns a DRAFT needing your approval; buyer text is untrusted data. |
| negotiate_offerA | What-if: run the negotiation engine for an offer and round without recording anything. Never goes below floor; floor is never revealed in drafted text. |
| draft_handoffB | Draft a pickup or delivery confirmation message (place, time, price, payment) with safety tips. Draft only. |
| propose_dealA | Record an agreed price with a buyer as PENDING APPROVAL in the deal ledger. Nothing is accepted until approve_deal with confirm:true. |
| approve_dealA | Human-approval step. action 'approve' (requires confirm:true) marks the deal agreed and reserves the listing; 'complete' marks it sold; 'cancel' cancels and re-opens the listing. Without confirm only a preview is returned. |
| deal_ledgerB | All deals with totals: completed revenue, pending/agreed value, average discount from ask. |
| post_listingA | Post the listing's text to X using the END USER's own OAuth 2.0 user token (X_USER_ACCESS_TOKEN, scope tweet.write). Without confirm:true returns the exact post preview. Photos are not uploaded by this tool; attach them in the X app or post manually. |
| send_dmA | Send an approved reply as an X direct message using the user's own token (scope dm.write). Needs the buyer's numeric X user id. Without confirm:true returns a preview only. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 11 tools
Most tools have clearly distinct purposes: listing management, negotiation, deal approval, posting, and messaging are separated. The main overlap is draft_buyer_reply vs negotiate_offer, since both run the negotiation engine, but one records a thread and drafts a reply while the other is explicitly a non-recording what-if. Draft vs send boundaries (draft_handoff, send_dm, post_listing) are also clear from descriptions.
The set mostly follows a predictable snake_case verb_noun pattern: create_listing, update_listing, list_listings, draft_buyer_reply, negotiate_offer, propose_deal, approve_deal, post_listing, send_dm. The main deviation is deal_ledger, which is a noun-only read tool rather than verb_noun. The convention is still readable and largely consistent.
Eleven tools are well-scoped for an X marketplace seller workflow, covering listings, negotiation, deal approval, posting, DMs, and ledger review. Each tool appears to earn its place by handling a distinct step, with no obvious filler or redundant surface.
The surface covers the core seller lifecycle: create/update/list listings, draft buyer replies, negotiate offers, propose/approve/complete/cancel deals, post listings, send DMs, draft handoffs, and view the deal ledger. Minor gaps remain, such as no get_listing for a single listing, no permanent delete_listing (only withdrawal), no photo upload (explicitly manual), and no dedicated view of negotiation thread history.