MyDesigns

Publish products

publish_products

Put products into one of the seller's MyDesigns stores, where buyers can see and order them. Give either the jobId a create_products call returned, once get_product_status says READY (or FAILED, which publishes the ones that were made), or the productIds of products from list_products that are not in a store yet, e.g. ones made in an earlier chat. Products already in a store cannot be published again. Ask the seller which store when they have more than one; never pick one for them. The products then go into the store in the background over a few minutes: check with get_product_status and the jobIds returned here, and tell the seller when they are live.

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": {
      "storeId": "<storeId>"
    },
    "name": "publish_products"
  }
}

Input Schema

Name	Required	Description
`jobId`	No	The jobId create_products returned. Give this or productIds.
`storeId`	Yes	The store id from list_stores.
`productIds`	No	Product ids from list_products, of products not in a store yet. Products made at different times go in one set at a time, each with its own jobId. Give this or jobId.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations, which only declare the write/async-adjacent safety profile. The description discloses that publishing happens in the background over a few minutes, that FAILED jobs still publish the products that were made, that republishing an in-store product is rejected, and that jobIds come back for polling.

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?

Purpose is front-loaded in the first sentence and every subsequent sentence carries an operational constraint. It is fairly long and restates some schema guidance (jobId source, productIds source), but nothing is idle filler.

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?

For an async write tool with three parameters and no output schema, the description covers the input sourcing, the preconditions, the background-completion behavior, and how to verify results. Very little an agent needs in order to call it correctly is 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 coverage is 100%, so the baseline is 3, but the description adds real meaning: jobId is only valid once status is READY/FAILED, productIds must be products not already in a store, and product batches from different times need separate calls. Minor overlap with the schema's own field descriptions keeps it from a 5.

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 specific verb and resource ("Put products into one of the seller's MyDesigns stores") plus the observable effect ("where buyers can see and order them"). This clearly separates it from create_products, list_products, and get_product_status without the agent needing to open another schema.

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?

Names both valid input paths and their prerequisites: a jobId from create_products once get_product_status reports READY or FAILED, or productIds from list_products for products not yet in a store. It also states an exclusion (already-stored products cannot be republished), a seller-consent rule (ask which store, never pick), and the follow-up check via get_product_status.

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

All MyDesigns 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?