Skip to main content
Glama
Sign In

Vendooly

by com.vendooly
OverviewDiscussionsAdmin

update_listing

Destructive

Modifica una listing esistente. SHORTCUT amichevoli (consigliati — costruiscono la struttura attributo corretta, niente schema SP-API a mano): bullets:[...] → bullet_point ("Funzionalità principali", la leva dei punti-elenco su amazon.it/EU, fino a 5 ~100 char l'uno), title → item_name, shipping_template → merchant_shipping_group (modello di spedizione: ID o nome esatto come in Seller Central; il tool risolve il nome nell'ID e rifiuta i nomi sconosciuti elencando i modelli veri; vale per le offerte FBM). In alternativa patches:[...] grezzi (JSON Patch SP-API, path /attributes/; la struttura dell'attributo si legge con get_product_types attributes=[""]). Il productType del PATCH viene preso dalla listing (GET productTypes) quando product_type non è passato: 'PRODUCT' resta solo come ultima spiaggia e con il suo schema generico ogni attributo specifico (care_instructions, style, …) dà issue 90000900. L'esito riporta product_type_used e product_type_source (arg | listing | fallback_*). validate_only:true = dry-run (Amazon valida senza applicare). ESITO: ok true/false + message già leggibile + verify_with (= get_listing sullo SKU dopo ~15 min; propagazione tipica <30 min, fino a 24 h). Il submissionId NON è un feed: non passarlo a check_feed_status. ok:false con issues[] severity ERROR = rifiutata da Amazon, correggi e riprova (prima con validate_only).

Input Schema

NameRequiredDescriptionDefault
skuYes
titleNoNuovo titolo (item_name)
bulletsNoPunti elenco (bullet_point), fino a 5
patchesNoJSON Patch SP-API grezzi (alternativa agli shortcut)
account_idNoID dell'outpost Amazon (= un seller su uno specifico marketplace; vedi list_clients). Opzionale se il token è legato a un solo outpost.
confirm_idNoToken di conferma ritornato dall'anteprima. Ripassa lo STESSO payload + confirm_id per eseguire davvero la scrittura.
product_typeNoProduct type Amazon (es. WINDOW_SHADE). Opzionale: se manca si legge dalla listing; passalo solo per forzarlo
validate_onlyNotrue = dry-run, valida senza scrivere
shipping_templateNoModello di spedizione da assegnare (ID o nome come in Seller Central). Elenco: get_product_types product_type="PRODUCT" → shipping_templates

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / product_type / description
      Added value: +"Product type Amazon (es. WINDOW_SHADE). Opzionale: se manca si legge dalla listing; passalo solo per forzarlo"
  2. Changed1 schema field changed
    • addedInput schema / properties / shipping_template
      Added value: +{
+  "description": "Modello di spedizione da assegnare (ID o nome come in Seller Central). Elenco: get_product_types product_type=\"PRODUCT\" → shipping_templates",
+  "type": "string"
+}
  3. First observed

TDQS

A4.2/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and openWorldHint=true, establishing this as a state-changing operation. The description goes far beyond by detailing propagation time (typical <30 min, up to 24h), the confirm_id two-step preview/execute flow, the behavior when product_type is missing (reads from listing, fallback PRODUCT causes 90000900 errors), and how to interpret ok:false with issues[]. This is rich behavioral context that annotations alone do not provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense and information-rich but not front-loaded; it reads as a continuous block without paragraph breaks or bullet points for the shortcuts. Some sentences are long and nested (e.g., the shipping_template explanation), which may slow comprehension. It could benefit from clearer structuring, though most content is relevant.

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 complexity (9 parameters, shortcut vs patches modes, confirm_id flow, product type resolution, propagation delays) and no output schema, the description covers what an agent needs to invoke correctly: it explains return shape (ok, message, verify_with), warns about submissionId, and provides the full workflow including validate_only. Nothing critical appears missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 89%, so the schema already documents most parameters. The description adds meaning beyond the schema for several parameters: it explains shipping_template resolution (tool resolves name to ID, rejects unknown names), clarify that bullets map to bullet_point and title to item_name, and that product_type is taken from the listing when not passed. This goes beyond mere repetition of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it modifies an existing listing ('Modifica una listing esistente'), and enumerates the specific attributes that can be changed (bullets, title, shipping_template) via shortcut paths or raw JSON Patch. It distinguishes itself from create_listing and bulk_update_listings by being a single-listing update with shortcut vs patches modes.

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?

Provides explicit guidance on when to use shortcuts (recommended, build correct attribute structure) vs raw patches, and explains that validate_only:true is a dry-run. It also instructs to use get_product_types for attribute structure and warns not to confuse submissionId with a feed (don't pass to check_feed_status). However, it does not explicitly say when to prefer this tool over bulk_update_listings or update_item_highlights.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Vendooly toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources