Skip to main content
Glama
ApparelHub-AI

apparelhub-mcp

Official

set_listing_attributes

Set channel-defined listing attributes like Material or Style on one product. Partial writes succeed; rejected values are reported for correction, and sync pushes changes immediately.

Instructions

Set channel-defined listing attributes on ONE product (Material, Style, Washing Instructions and similar). Call describe_listing_attributes first to learn the field keys and their allowed values.

A PARTIAL WRITE SUCCEEDS. Send four values with one bad and the three good ones are stored while the bad one is reported — you do not have to get them all right at once. A value the channel refuses comes back in rejected with a machine-readable reason and the allowed values echoed, so you can correct it in one more turn rather than guessing. Rejections are never dropped silently.

ā›” NEVER INVENT A VALUE. Relay what the merchant told you. If you cannot get a value from them, leave it UNSET and say so — an unset field is honest, an invented one is not. Do not infer it from the product type, do not copy it from another shop, and do not pick the nearest allowed value because it looks close.

šŸ“ SIZE CHART. US apparel is graded down without one. A chart is normally rendered automatically from the fulfillment provider's real measurements, so most listings need nothing. When one IS flagged, prefer size_chart_measurements (an object — call import_size_measurements to fill it from the provider) over size_chart_template_id: the template id can only come from a human in the channel's own admin, because the channel publishes no way to list, verify or correct one.

ā›” NEVER INVENT MEASUREMENTS. They are what a buyer reads before choosing a size. Do not derive a table from the garment type, do not copy one from a similar product, and do not fill a gap with a plausible number. A malformed table is refused whole, with a reason — nothing is half-applied. A missing cell is fine and renders blank; an invented one means somebody receives a garment that does not fit.

Setting a value does NOT change the live listing on its own — the channel is updated on the next sync. Pass sync: true to push it immediately, or run sync_to_channel afterwards.

[#ef218b]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
syncNoPush the listing to the channel immediately after storing.
removeNoField keys to clear.
valuesYesfield key -> value. Use an array for a field whose `cardinality` is "multi", and an object for one whose `value_type` is "object" (build it from that field's `channel_ref.object_schema`). Values are relayed exactly as given.
workspaceNo
store_uuidYes
product_uuidYes
integration_uuidNoOnly needed when the store has more than one connected channel.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.15.2

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only carry openWorldHint, so the description does the heavy lifting and does it well: partial-write semantics, rejected values returned with machine-readable reason and allowed values, no silent drops, deferred sync behavior, and whole-table rejection for malformed size charts. These are exactly the behavioral traits an agent needs and cannot get from the schema.

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?

Long, but front-loaded with purpose and the partial-write rule, then proceeds in headed blocks. The two anti-invention warnings are emphatic and slightly repetitive in tone, but each carries distinct content (attribute values vs measurements) and the slack is small.

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 a mutation tool with no output schema, the description supplies the return contract (rejected with reason and allowed values), the sync lifecycle, and the prerequisites. An agent has everything needed to call and recover from failure without opening another tool.

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 57% with 7 params, so the description compensates: it clarifies how values are keyed, that arrays are for 'multi' cardinality and objects for 'object' value_type, and it explains sync and the size-chart fields beyond their one-line schema descriptions. It does not cover remove, workspace, or integration_uuid, hence not 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 ('Set channel-defined listing attributes on ONE product') and names the field families. The 'ONE product' scoping and the pointer to describe_listing_attributes distinguish it cleanly from update_product and describe_listing_attributes in the sibling list.

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 sequencing ('Call describe_listing_attributes first'), an alternative path for syncing ('Pass sync: true ... or run sync_to_channel afterwards'), and a preference rule between size_chart_measurements and size_chart_template_id with the reason the latter is limited. This is genuine when/when-not guidance.

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

Deploy Server

Other Tools