Prepares Vinted listings from photos by importing attachments and creating local drafts with title, description, price, category, brand, size, condition, and package details. After explicit confirmation, it uploads photos, creates a remote draft, completes/publishes the listing, and returns the outcome or link when confirmed. Includes mock simulation and live web-adapter modes.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Personal Vinted MCP Use these photos to prepare a Vinted listing draft and show me for review."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Server MCP personale e self-hosted per preparare un annuncio da foto in ChatGPT, rivedere il riepilogo e pubblicarlo con un pulsante. Progetto indipendente, non affiliato a Vinted. Licenza Apache-2.0.
Stato: MVP sperimentale. Flusso MCP, widget, OAuth e persistenza sono implementati e testabili in simulazione. L'adattatore web per account normali è implementato ma non validato su un account reale. Gli endpoint privati possono cambiare o rifiutare le richieste. Non c'è garanzia di pubblicazione su qualsiasi account o di assenza di ban.
Vinted vieta strumenti esterni non autorizzati nei suoi termini. La documentazione pubblica trovata per pubblicare annunci è quella delle integrazioni Pro: non dimostra che un normale account abbia accesso a un'API ufficiale di pubblicazione. Per minimizzare il rischio di restrizioni, richiedi autorizzazione a Vinted o pubblica manualmente il testo preparato. Questo progetto non implementa occultamento del bot, imitazione di fingerprint, rotazione di proxy o risoluzione di CAPTCHA. Si ferma ai rifiuti del servizio.
Alleghi le foto a ChatGPT e chiedi di usare la tua app Vinted MCP.
ChatGPT propone titolo, descrizione e prezzo; ti chiede ciò che non può verificare.
Il server importa gli allegati e salva una bozza locale senza inviare nulla a Vinted.
Un riquadro mostra foto, prezzo, categoria, marca, taglia, condizioni e pacco.
Premi Conferma e pubblica: solo allora parte l'invio a Vinted.
Ricevi l'esito e, se confermato dall'API, il link. Gestisci il resto su Vinted.
In modalità mock il pulsante dice Conferma simulazione e non contatta Vinted.
Il prezzo è una proposta del modello, non una quotazione basata su confronti di mercato.
Non serve una chiave OpenAI: la preparazione è svolta da ChatGPT.
sequenceDiagram
actor U as Tu
participant C as ChatGPT
participant M as Il tuo MCP
participant V as Vinted
U->>C: Foto e informazioni
C->>M: import_photos
C->>M: prepare_listing
M-->>U: Foto e riepilogo con pulsante
U->>M: Conferma dal widget
M->>V: Foto, bozza remota, pubblicazione
V-->>M: Esito
M-->>U: Link o richiesta di verifica manualeRelated MCP server: DevSpace
Python 3.12+ e uv.
uv sync --extra dev --locked
uv run vinted-mcp stdiostdio serve ai client locali. ChatGPT remoto richiede HTTP raggiungibile tramite
HTTPS; non può raggiungere direttamente il tuo localhost.
Su questo PC è disponibile anche il virtualenv preparato durante lo sviluppo:
.\.venv\Scripts\vinted-mcp.exe stdioIl codice può essere pubblico; la tua istanza e i suoi dati devono restare privati. La cartella di lavoro può essere in OneDrive: non metterci sessioni o password. Il server usa di default:
Sistema | Directory privata |
Windows |
|
Linux/macOS |
|
Quella directory contiene .env, session.json, profiles.json, foto e SQLite.
Non sincronizzarla nel cloud. I dati non sono cifrati dall'app: usa permessi privati
del sistema e cifratura disco. Preparazione su Windows:
$vintedPrivate = Join-Path $env:LOCALAPPDATA 'VintedMCP'
New-Item -ItemType Directory -Force -Path $vintedPrivate
Copy-Item .env.example (Join-Path $vintedPrivate '.env')
.\.venv\Scripts\python.exe -c "import secrets; print(secrets.token_urlsafe(32))"Incolla il valore generato in MCP_OWNER_SECRET nel .env privato, mai in chat.
Per un'altra configurazione imposta VINTED_ENV_FILE a un percorso assoluto.
Le variabili d'ambiente già impostate hanno precedenza sul file.
Non committare cookie, HAR, database o foto personali. .gitignore include le
esclusioni principali ma non impedisce a OneDrive di sincronizzare i file.
Vedi SECURITY.md per i confini di fiducia.
Predisponi un endpoint HTTPS tramite reverse proxy o tunnel verso 127.0.0.1:8000.
Non esporre la directory dati.
Nel .env privato imposta MCP_PUBLIC_URL=https://tuo-dominio.example e il segreto.
Avvia uv run vinted-mcp http.
In un ambiente ChatGPT che supporta app MCP personalizzate crea una connessione
a https://tuo-dominio.example/mcp con OAuth. Disponibilità e autorizzazioni
dipendono dal piano e dalle impostazioni del workspace.
Nella pagina del tuo dominio autorizza il client inserendo MCP_OWNER_SECRET:
è il segreto del server, non la password Vinted.
Lascia VINTED_MODE=mock e prova prima foto e conferma simulata.
Il server espone discovery OAuth, registrazione dinamica, PKCE e token vincolati alla risorsa. Non richiede un servizio di autenticazione esterno. I token durano 24 ore; il riavvio li revoca. Riconnetti l'app quando necessario. Usa un solo worker. Disabilita log di header, corpi e query OAuth nel tunnel/reverse proxy; gli access log dell'app sono disabilitati.
Il widget usa MCP Apps e le estensioni ChatGPT compatibili. Una semplice GPT Action non basta: questa implementazione è un'app MCP con risorsa UI. Il pulsante richiede un host con MCP Apps; con client solo testuali, la conferma va gestita dal client prima di chiamare il tool di scrittura.
Il tool dichiara openai/fileParams e riceve allegati con download_url e file_id,
più mime_type e file_name opzionali. Percorsi sandbox:/... non sono scaricabili
dal server. Se il client non consegna gli allegati corretti, riassocia le foto.
Se usa un altro dominio, aggiungi l'host esatto e fidato a PHOTO_DOWNLOAD_HOSTS,
separando gli host con virgole. Non usare wildcard o URL arbitrari.
Riferimenti ufficiali: server MCP, widget MCP Apps, file input e runtime. Connessione e rendering dentro ChatGPT non sono stati verificati in questa sessione.
Non c'è login con password in questo progetto. Accedi manualmente su Vinted e conserva solo sul tuo PC i cookie di sessione e il token CSRF usato dal sito. Puoi leggerli dagli strumenti sviluppatore nelle richieste del tuo account. Non esportare HAR e non incollarli in chat, issue o file nel repo.
Nel session.json della directory privata, con i valori reali locali:
{
"cookies": {"nome_cookie_sessione": "VALORE_LOCALE"},
"csrf_token": "TOKEN_CSRF_LOCALE",
"anon_id": "OPZIONALE_SE_PRESENTE_NELLA_TUA_SESSIONE"
}Il nome del cookie è un segnaposto: usa quelli effettivamente richiesti dalla tua sessione. Non tutti i cookie sono necessari. Sessione e CSRF possono scadere e vanno aggiornati manualmente. Una sessione valida nel browser potrebbe essere rifiutata via HTTP. Il server non aggira challenge o autenticazione.
Configura anche profiles.json: una lista di combinazioni categoria/marca/taglia/
condizione/pacco che usi. Ricava gli ID dai dati effettivi del modulo del tuo account,
senza inviare un annuncio di prova. Non usare gli ID mock in live. Esempio strutturale
(sostituisci tutti i segnaposto con interi reali):
[
{
"name": "Magliette marca X taglia M",
"catalog_id": "SOSTITUISCI_CON_INTERO",
"category_label": "Magliette",
"brand_id": "SOSTITUISCI_CON_INTERO",
"brand": "MARCA_REALE",
"status_id": "SOSTITUISCI_CON_INTERO",
"condition_label": "CONDIZIONE_REALE",
"size_id": "SOSTITUISCI_CON_INTERO_O_NULL",
"size_label": "M",
"package_size_id": "SOSTITUISCI_CON_INTERO",
"package_label": "Piccolo"
}
]Questa versione non scarica automaticamente l'intera tassonomia Vinted. Per categorie o attributi speciali non modellati (libri, elettronica, materiali obbligatori), l'invio può essere rifiutato: usa il modulo Vinted o estendi modelli e adattatore con i campi necessari. Non nascondere attributi extra nel testo per aggirare le validazioni.
Per abilitare consapevolmente l'adattatore nel file privato:
VINTED_MODE=live
VINTED_ENABLE_UNOFFICIAL_API=true
VINTED_BASE_URL=https://www.vinted.itRiavvia e crea nuove bozze: una bozza mock non può essere pubblicata live. Gli endpoint implementati sono upload foto, creazione bozza remota e completamento. Preparare il riepilogo non contatta Vinted. Un completamento fallito può lasciare una bozza remota: controlla dal sito.
La libreria suggerita ha una release 0.3.9 del luglio 2025 e descrive soprattutto lettura di cataloghi e prodotti. Non è una dipendenza perché non stabilisce un contratto ufficiale per questo flusso di scrittura. L'adattatore separato permette di passare a un'API autorizzata in futuro.
Le bozze scadono dopo 30 minuti; ogni modifica richiede nuova bozza e conferma.
SQLite registra l'inizio dell'invio prima delle richieste di rete.
Dopo un successo, un doppio clic restituisce l'esito senza ripubblicare.
Timeout, crash e risposte inattese richiedono verifica manuale, senza retry automatici.
Gli errori live sospendono gli invii con un blocco persistente, inclusi HTTP 401/403/429.
Dopo aver controllato account, bozze e annunci: uv run vinted-mcp unblock.
Le bozze già tentate restano non reinviabili; creane un'altra solo dopo aver
verificato che non esista già un annuncio.
Almeno 60 secondi fra tentativi live. È un limite locale, non una soglia dichiarata sicura da Vinted né una garanzia contro i ban.
uv sync --extra dev --locked
uv run pytest -q
uv run ruff check .
uv pip checkI test coprono OAuth/PKCE e accesso HTTP, contratto MCP e allegati, persistenza, concorrenza, duplicati, scadenza, isolamento mock/live, rifiuti API, host non fidati e rimozione EXIF. Il contratto Vinted usa risposte simulate: i test non dimostrano compatibilità con il servizio reale.
server.py espone MCP/UI; auth.py gestisce l'accesso personale; service.py
orchestra l'invio; storage.py conserva stati; photos.py importa gli allegati;
vinted.py contiene l'adattatore sostituibile. La CI usa dati sintetici senza
credenziali Vinted o OpenAI.
Non sono stati pubblicati repository, plugin, siti o annunci durante lo sviluppo.
Read exact listing summary and publication status without contacting Vinted.
| Name | Required | Description | Default |
|---|---|---|---|
| draft_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint=false; the description reinforces this by stating the call does not contact Vinted, which tells the agent data may be cached/stale rather than live. It does not say what happens when draft_id is unknown, but adds genuinely useful context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence with no filler; the key constraint (no Vinted contact) is front-loaded-ish at the end. 'Exact' is slightly vague but does not bloat the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read there is no output schema, and the description never indicates what fields the 'summary' contains or how a missing/unknown draft is signalled. Adequate to select the tool, but thin on return-shape expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the single parameter 'draft_id' is undocumented in the schema. The description never explains what a draft_id is, where to obtain it, or its format, so it fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Read') and resource ('listing summary and publication status'), which distinguishes it from mutating siblings like prepare_listing and publish_listing. It does not explicitly contrast with get_status, which reads as the closest sibling, so the separation is only implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Without contacting Vinted' implies this is the local/cached lookup path, which gives some context for choosing it over a remote fetch. However, no alternative tool is named and there is no explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read verified category/brand/condition/size/package IDs and labels from local configuration. Mock IDs are only for simulation. Never guess real IDs or unverified item characteristics.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is known. The description adds meaningful non-annotation context: the data comes from local configuration, mock IDs exist and are simulation-only, and agents must not guess real IDs. It does not need to explain return values because an output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the first states the purpose and source, the second adds the critical mock-ID warning. No sentence is wasted and the caveat is front-loaded enough.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only, closed-world tool with an output schema and annotations, the description covers purpose, source, and key caveats. The main gap is that it does not explicitly route the agent away from sibling tools, but that is a usage-guideline issue rather than missing core context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so parameter semantics baseline is 4. The empty schema leaves nothing for the description to compensate for, and the description correctly focuses on data provenance rather than arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: read verified category/brand/condition/size/package IDs and labels from local configuration. It does not name sibling tools or contrast with them, so an agent must infer its place among get_listing, prepare_listing, and publish_listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage by warning never to guess real IDs and noting mock IDs are only for simulation, but it never states when to call this tool instead of get_listing or prepare_listing. The guidance is present but not comparative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return mode and session file presence, never credentials.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral guarantee beyond that — credentials are never included in the response — but says nothing about what a 'session file' is or what happens when it is absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler. It is efficient, though its terseness shades into under-specification rather than optimal density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values needn't be explained, and the security caveat is a helpful addition. However, with an undefined 'mode' and no usage context, the description leaves the agent guessing about the purpose of the call, which is thin even for a zero-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4; there are no argument semantics the description needs to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'return' and the resources ('mode', 'session file presence') are stated, but 'mode' is never defined, so an agent learns only loosely that this is a status/environment probe. It is clearly distinct from the listing-oriented siblings, but the resource it reports on is fuzzy rather than specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to call this tool, no prerequisites, and no reference to any sibling. The agent must infer that it is a health/status check used before other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download 1–20 user-provided ChatGPT photo attachments and save locally without EXIF/GPS. Requires actual file objects from ChatGPT, never sandbox paths or invented URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| photos | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=false, and the description is consistent with that (it writes files locally). The description adds real behavioral context the annotations do not carry: it strips EXIF/GPS metadata on save and enforces a hard 1–20 attachment ceiling. It stops short of saying where files land on disk.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler. The core action and its critical input constraint are both front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, and the safety profile is covered by annotations. The remaining shortfall is minor: it does not state the local save destination or what happens when an item in a batch fails to download.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, and it does: it establishes that the photos array must contain genuine ChatGPT file objects with real download URLs, not paths or fabricated links, and caps the array at 20 items (a limit absent from the schema). It leaves the individual PhotoFile fields (file_id, file_name, mime_type) unexplained, so it does not fully close the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (download/save) plus resource (ChatGPT photo attachments), along with two distinguishing traits: the 1–20 batch bound and EXIF/GPS stripping. Nothing here resembles the sibling tools (get_status, prepare_listing, publish_listing), so the agent can separate it immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Requires actual file objects from ChatGPT, never sandbox paths or invented URLs" is an explicit precondition that rules out the most likely misuse mode. It gives clear context but names no alternative tool and no when-not-to-use case beyond that constraint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save an immutable listing for 30 minutes and show summary and confirmation button. Does not contact Vinted. Any edits require a new draft and renewed confirmation.
| Name | Required | Description | Default |
|---|---|---|---|
| listing | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds real behavior beyond the annotations: a 30-minute TTL, immutability of the saved listing, no external side effects (annotations already flag openWorldHint=false, and the description reinforces it), and that edits invalidate the confirmation. Missing is what happens on expiry or whether a stale draft must be cleaned up, so it is not complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler. The most decision-relevant fact (no Vinted contact, immutable, 30-minute window) is front-loaded and the edit/confirmation rule follows immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The lifecycle behavior is well covered for a mutation tool, and there is no output schema to explain. But with a large, undocumented nested parameter object and no annotation-level detail about failure modes, the definition leaves an agent guessing about how to construct valid input.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for a nested Listing object with 16 properties, many of them required IDs (catalog_id, brand_id, status_id, package_size_id) whose meaning and valid source is entirely unexplained. The description adds nothing about any field, so the agent gets no help on the hardest part of invoking this tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (save an immutable listing) plus the concrete user-facing effect (show summary and confirmation button). The line 'Does not contact Vinted' cleanly separates it from the sibling publish_listing. It falls short of 5 only because 'save' doesn't say where the listing is stored, though the 30-minute lifetime implies a server-side draft.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Strong implicit routing: 'Does not contact Vinted' plus 'Any edits require a new draft and renewed confirmation' tells the agent this is the pre-publish staging step and that publish_listing is the follow-up. It never names publish_listing explicitly or states the condition for choosing it, which keeps this below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publish the exact reviewed draft ONLY after the user's confirmation button click. External write; never call proactively. Repeated successful calls return the saved result.
| Name | Required | Description | Default |
|---|---|---|---|
| draft_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, openWorldHint=true, and idempotentHint=true; the description adds genuinely new context by tying idempotency to concrete behavior ('repeated successful calls return the saved result') and flagging the external-write nature. It doesn't say what publishing destroys or whether it can be undone, which keeps it below 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, no filler, with the safety-critical constraint up front. Every clause carries operational weight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations covering the safety profile and an output schema covering return values, the description is nearly complete for a one-parameter tool. The remaining gap is the unexplained draft_id.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single parameter draft_id, and the description never defines what a draft_id is, where it comes from, or what format it takes. 'The exact reviewed draft' gives only a loose semantic anchor, so the description largely fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (publish) and a specific resource (the exact reviewed draft), and the confirmation gate implicitly separates it from prepare_listing. It doesn't explicitly name the sibling it supersedes, so it falls short of the 5 bar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger condition ('ONLY after the user's confirmation button click') and an explicit prohibition ('never call proactively'), which is exactly the when/when-not guidance an agent needs before an external write.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_listingget_listing_profilesget_statusimport_photosprepare_listingpublish_listingScored across 6 tools
The lifecycle actions (import_photos, prepare_listing, publish_listing, get_listing) are clearly distinct in purpose and readable. The only mild overlap is between get_status and get_listing_profiles, which both read local state/config, though their descriptions differentiate them well enough.
All six tools follow a consistent snake_case verb_noun pattern (get_status, get_listing_profiles, import_photos, get_listing, prepare_listing, publish_listing), with no mixed conventions or vague verbs.
Six tools map cleanly onto a focused create-and-publish workflow, each earning its place with a distinct step. The surface is well-scoped for the narrow purpose.
The core lifecycle (read config, import photos, prepare immutable draft, publish, inspect listing/status) is covered with sensible safety gates. Minor gaps exist — no cancel/withdraw of a prepared draft and no way to list existing listings — but these are workable around the immutable-draft design.
Hosted MCP server for 3Dsellers, the multichannel selling platform. Connect Claude, ChatGPT, Cursor, VS Code or any MCP client and manage your eBay, Amazon, Walmart, Etsy, Shopify, WooCommerce and TikTok Shop stores in plain language: search and update products, publish listings, sync inventory, tag and track orders, run bulk actions and CSV imports, and reply to customer messages. 120+ tools. Sign in with OAuth or a personal token. No eBay developer account and nothing to install. Setup guides and config examples for every client: https://github.com/3dsellers/ebay-mcp-server
Hosted Amazon Seller and Vendor MCP server for Claude, ChatGPT, Cursor, Codex, Gemini, Copilot.
Hosted Amazon Seller Central and Amazon Ads MCP server for Claude, ChatGPT, Cursor, and agents.
Hosted Shopify MCP server for Claude, ChatGPT and Cursor, with each action switched per account.
