Skip to main content
Glama
trhonpavel
by trhonpavel

Create product

create_product

Creates a Medusa product with variants, prices, stock, and catalog details. Use it to add simple products or multi-option variants via the Medusa Admin API.

Instructions

Creates a product with its variants and prices. For a simple product without options pass just 'prices' (and optionally 'sku', 'stock'). For variants define 'options' (e.g. Size: S, M, L) and one variant per combination. Defaults: status draft, the store's default sales channel, the default shipping profile. Category and collection IDs come from list_catalog.

Input Schema

NameRequiredDescriptionDefault
skuNoSimple product: SKU of its single variant
tagsNoTag values; missing tags are created
stockNoSimple product: initial stock
titleYes
handleNoURL slug; derived from the title when omitted
imagesNoImage URLs
pricesNoSimple product: prices of its single variant
statusNodraft
weightNoGrams
optionsNoE.g. [{ title: 'Size', values: ['S','M','L'] }]
metadataNo
subtitleNo
variantsNo
thumbnailNoImage URL
descriptionNo
location_idNoStock location for initial stock; defaults to the only one
category_idsNo
discountableNo
collection_idNo
sales_channel_idsNo
shipping_profile_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.0

TDQS

A4.1/5.0
Behavior3/5

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

Annotations already declare readOnly=false, destructive=false, idempotent=false, and openWorld=true. The description adds useful default behavior (draft status, default sales channel, default shipping profile) but does not discuss permissions, duplicate-creation risk, or return behavior beyond what annotations cover.

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

Conciseness5/5

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

Four efficient sentences, front-loaded with the purpose, then mode guidance, defaults, and ID sourcing. Nothing is repetitive or wasted.

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

Completeness3/5

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

For a 21-parameter tool with nested objects and no output schema, the description covers the main creation modes and defaults but omits return values, permission needs, and many optional parameter details. It is adequate for common cases but leaves clear gaps.

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 only 48% schema description coverage, the description compensates by explaining core relationships: prices for a simple product, options plus one variant per combination, and the default status/sales channel/shipping profile. It still leaves many optional parameters unexplained, but it adds real meaning for the main creation paths.

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 ('Creates') and resource ('a product with its variants and prices'). It also distinguishes two creation modes (simple vs variant), which sets it apart from sibling tools like create_variant and update_product.

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

Usage Guidelines4/5

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

Clearly explains how to use the tool for a simple product versus a variant product, and points to list_catalog for category/collection IDs. It does not name alternatives or when not to use it, but the in-tool guidance is strong.

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