Obriym CRM

Publish Amazon listings

publish_amazon_listings

Destructive

Create Amazon listings for up to 25 products — a REAL publication on the seller's Amazon account. Each product runs the full check again (Amazon's dry run included) and is refused with Amazon's own sentences if anything changed; a product whose barcode Amazon already knows becomes an offer on that existing item. Run check_amazon_readiness first and pass only ready products. Refused until the owner switches on AI publishing, and while listing creation is not armed on the Amazon connection. Returns created (with the ASIN or SKU and, in submitted, the price, currency, quantity and fulfilment the listing was sent with — quantityOmitted says why no quantity went out: stockNotTracked or stockUnknown; an FBA offer's quantity is Amazon's own), failed (reason, details) and notAttemptedIds. created means Amazon ACCEPTED the submission for processing, not that the listing is live or buyable: Amazon finishes it asynchronously, so check the outcome later with inspect_amazon_listings and never tell the user a listing is live from this result alone. Not idempotent: a product already listed fails with alreadyListed. The result echoes the workspace.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "productIds": "<productIds>"
    },
    "name": "publish_amazon_listings"
  }
}

Input Schema

Name	Required	Description	Default
`productIds`	Yes	The products to publish, at most 25 ready ids from check_amazon_readiness.
`marketplaceId`	No	One Amazon store by its id (APJ6JRA9NG5V4 is amazon.it, A1PA6795UKMFR9 is amazon.de). Required when more than one store is open for this write; the store must have passed its own dry run on the Amazon connection.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 8, 2026

addedInput schema / properties / marketplaceId

Added value: +{
+  "description": "One Amazon store by its id (APJ6JRA9NG5V4 is amazon.it, A1PA6795UKMFR9 is amazon.de). Required when more than one store is open for this write; the store must have passed its own dry run on the Amazon connection.",
+  "maxLength": 32,
+  "minLength": 1,
+  "type": "string"
+}

AddedNov 7, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond annotations, it discloses that each product runs the full check again, that Amazon dry-run refusals are returned in Amazon's own words, that known barcodes become offers on existing items, that the operation is not idempotent, and that created means accepted for processing rather than live. These are substantial behavioral details for a destructive, open-world write.

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?

The description is front-loaded with the core action and the most important warning about real publication, and nearly every sentence earns its place. It is dense and somewhat run-on, but the length is mostly justified by the destructive and asynchronous behavior being disclosed.

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 destructive, open-world nature of the tool and the absence of an output schema, the description is unusually complete: it covers prerequisites, refusal conditions, return fields, ASIN/SKU handling, quantity omission reasons, asynchronous completion, and non-idempotency.

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

Parameters3/5

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

Schema description coverage is 100%, so productIds and marketplaceId are already documented in the schema. The description reinforces the 25-product limit and the ready-product constraint but adds little parameter meaning beyond what the schema already provides.

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?

The description states a precise verb and resource: creating Amazon listings for up to 25 products, with the crucial clarification that this is a real publication to the seller's account. It clearly distinguishes the action from readiness checking and inspection siblings.

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?

It explicitly says to run check_amazon_readiness first and pass only ready products, and it names the conditions under which publication is refused. It also routes the agent to inspect_amazon_listings for the asynchronous outcome, so both prerequisites and follow-up are clear.

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

All Obriym CRM tools Inspect

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

Need Help?