Skip to main content
Glama

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). validate_only:true = dry-run (Amazon valida senza applicare).

Input Schema

TableJSON 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_typeNo
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 / 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"
      +}
  2. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds real behavioral detail beyond them: shipping_template names are resolved to IDs, unknown names are rejected with the list of valid templates, and the mapping only applies to FBM offers. The dry-run and confirm_id semantics are noted, though error/reversibility behavior for the generic patch path is not described.

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

Conciseness4/5

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

Front-loaded with the purpose, then dense but well-ordered detail on shortcuts, patches, and dry-run. Every clause carries information; only the parenthetical asides make it slightly heavy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter destructive mutation with no output schema, the description covers the confirmation flow, dry-run, and the recommended editing path. Gaps remain around unsupported attributes, product_type's role, and error behavior, but an agent has enough to call it correctly.

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?

With 78% schema coverage the baseline is 3, and the description goes further by documenting the shortcut-to-attribute mapping (bullets→bullet_point with ~100 char and max-5 limits, title→item_name, shipping_template→merchant_shipping_group) and the dry-run flag. It does not explain product_type or the patch payload format, so it is not exhaustive.

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?

States a specific verb+resource ('Modifica una listing esistente') and then explains the two editing modes it supports (friendly shortcuts vs raw SP-API JSON Patch), which lets an agent distinguish it from create_listing and bulk_update_listings. It does not explicitly name a sibling, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives in-tool guidance (shortcuts 'consigliati', patches as the alternative, validate_only:true for a dry run), which helps an agent choose a parameter style. However it offers no guidance on when to use this tool versus bulk_update_listings, bulk_set_shipping_template, 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources