Skip to main content
Glama

Vendooly

by com.vendooly
OverviewDiscussionsAdmin

check_listing_restrictions

Read-only

READ-ONLY. Gated products: BEFORE listing or buying stock, tells whether THIS seller account can sell each ASIN on the outpost's marketplace (or other marketplaces of the same region) in a given condition, using Amazon's Listings Restrictions API (getListingsRestrictions). Per ASIN: libero (no restriction) / serve_approvazione (APPROVAL_REQUIRED, with Amazon's approval_links to Seller Central) / non_idoneo (NOT_ELIGIBLE, no path to unlock) / asin_non_trovato (ASIN_NOT_FOUND on that marketplace). Results are GROUPED BY BRAND (brand read from the Amazon catalog, cached) with a verdict per brand (da_sbloccare / non_vendibile / libero) and a summary for the user; when a brand needs approval the response includes unlock_guide (what Amazon usually asks: invoices from the manufacturer or an authorized distributor, last 180 days, addressed to the seller account's legal name/address; or the brand's LOA / Reseller role in Brand Registry). Accepts asins[] OR identifiers[] (EAN/UPC/GTIN from a supplier file: converted to ASIN via the catalog, unmatched codes listed in unresolved_identifiers). Max 100 codes per call; ~4 calls/s, so 100 ASIN take ~25 s: if status is 'partial', call again with next_call.arguments (pending_asins). The approval request itself CANNOT be sent via API: give the user the approval_links. Use this for 'can I sell these products?', 'which brands do I need to get ungated?', 'is brand X gated for me?'. BRAND MODE: when the supplier gives only brand names (no ASIN/EAN, common in EU/UK), pass brands[] (optional category / classification_id): the tool samples the brand's best-selling ASINs from the catalog and returns by_brand_query with verdict, asins_evaluated and confidence (alta/media/bassa); say it is an estimate on a sample. For listings already uploaded and blocked use list_inactive_listings / get_listing_issues (QUALIFICATION_REQUIRED). Not available for Vendor outposts.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
asinsNoASIN da controllare (max 100). Accetta anche una stringa separata da virgole/a capo.
brandsNoMODALITÀ PER MARCHIO (senza asins/identifiers): nomi di marchio da controllare (max 10), quando il fornitore non dà ASIN né EAN. Per ogni marchio lo strumento prende dal catalogo i suoi ASIN più venduti (campione) e dà un verdetto per marchio (libero / da_sbloccare / non_vendibile / marchio_non_trovato) con il numero di ASIN valutati e la confidenza. È una STIMA: per decidere un acquisto controlla poi gli ASIN/EAN esatti.
categoryNoSolo con brands: categoria in parole (es. "giocattoli", "integratori") per limitare il campione a quella categoria del marchio. Il campione è dichiarato come campione di categoria.
conditionNoCondizione di vendita (default new_new = Nuovo).
account_idNoID dell'outpost Amazon (= un seller su uno specifico marketplace; vedi list_clients). Opzionale se il token è legato a un solo outpost.
identifiersNoIn alternativa/aggiunta: codici EAN/UPC/GTIN (es. dal listino fornitore), convertiti in ASIN con il catalogo Amazon del marketplace dell'outpost (max 100 in totale con asins).
sample_sizeNoSolo con brands: ASIN per marchio nel campione (default 5).
include_brandNoDefault true: legge il brand dal catalogo per raggruppare. false = più veloce, tutto sotto "brand sconosciuto".
reason_localeNoLingua dei messaggi Amazon (es. it_IT); default = lingua del primo marketplace.
identifier_typeNoTipo dei codici in identifiers (default EAN).
marketplace_idsNoMarketplace da controllare (max 5, stessa region dell'outpost, es. APJ6JRA9NG5V4 = amazon.it, A1PA6795UKMFR9 = amazon.de). Default: il marketplace dell'outpost.
classification_idNoSolo con brands: id numerico del nodo di categoria Amazon (browse node) per limitare il campione. Alternativo o insieme a category.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / brands
      Added value: +{
+  "description": "MODALITÀ PER MARCHIO (senza asins/identifiers): nomi di marchio da controllare (max 10), quando il fornitore non dà ASIN né EAN. Per ogni marchio lo strumento prende dal catalogo i suoi ASIN più venduti (campione) e dà un verdetto per marchio (libero / da_sbloccare / non_vendibile / marchio_non_trovato) con il numero di ASIN valutati e la confidenza. È una STIMA: per decidere un acquisto controlla poi gli ASIN/EAN esatti.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / category
      Added value: +{
+  "description": "Solo con brands: categoria in parole (es. \"giocattoli\", \"integratori\") per limitare il campione a quella categoria del marchio. Il campione è dichiarato come campione di categoria.",
+  "type": "string"
+}
    • addedInput schema / properties / classification_id
      Added value: +{
+  "description": "Solo con brands: id numerico del nodo di categoria Amazon (browse node) per limitare il campione. Alternativo o insieme a category.",
+  "type": "string"
+}
    • addedInput schema / properties / sample_size
      Added value: +{
+  "description": "Solo con brands: ASIN per marchio nel campione (default 5).",
+  "maximum": 10,
+  "minimum": 3,
+  "type": "integer"
+}
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnly/destructive/openWorld annotations, it discloses rate limits (~4 calls/s, ~25 s for 100 ASINs), the 'partial' status and next_call.arguments(pending_asins) retry protocol, catalog caching, the 100-code / 5-marketplace caps, and the constraint that marketplaces must be in the same region as the outpost. These are operational behaviors an agent cannot infer from 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.

Conciseness4/5

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

Front-loads 'READ-ONLY' and the core purpose, and most sentences carry distinct operational content. It is dense and long (~350 words) with some mixed-language clutter, but for a 12-parameter tool with two modes this is close to justified.

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?

No output schema exists, and the description compensates by naming the return structure: per-ASIN verdicts, brand grouping with per-brand verdicts, unlock_guide contents, by_brand_query with asins_evaluated/confidence, and unresolved_identifiers. An agent has enough to invoke the tool and interpret the response.

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 coverage is already 100%, so the baseline is 3, but the description adds genuine cross-parameter semantics the schema does not: asins[] OR identifiers[] (mutually share the 100-code budget), brands[] used only when no ASIN/EAN is available, and the sample_size/confidence estimate caveat. It stops short of documenting every parameter (e.g. reason_locale, include_brand are left to the schema).

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

Purpose5/5

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

States a precise verb+resource+scope: it checks whether 'THIS seller account can sell each ASIN' on the outpost's marketplace, via Amazon's getListingsRestrictions API, and enumerates the four possible verdicts. It explicitly distinguishes itself from the sibling tools list_inactive_listings / get_listing_issues for already-uploaded blocked listings.

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

Usage Guidelines5/5

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

Gives explicit trigger conditions ('BEFORE listing or buying stock', 'can I sell these products?', 'which brands do I need to get ungated?') and routes to alternatives for the blocked-listing case. It also states a hard exclusion: 'Not available for Vendor outposts', and notes that the approval request itself cannot be sent via API.

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