stub

Save product

save_product

Create or update a product. Pass an id to update that product; omit id to create a new one. Returns the new product id on create. To create/update many at once, send an items array — one all-or-nothing transaction with a single ledger recompute; each item with an id updates, each without creates.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	No	Product id. Present → update that product; omit → create a new one.
`sku`	No	Stock-keeping unit / product stock code. Canonical product-level SKU (mirrors a variant's sku).
`cost`	No	Cost price per unit.
`name`	No	Display name / description of the product.
`unit`	No	Legacy unit-of-measure label; prefer `units`.
`image`	No	Product image URL; pass "$delete" to remove the existing image.
`items`	No	Vector of product objects to create/update in one all-or-nothing batch. Preferred over repeated calls. Each item with an id updates; each without creates.
`notes`	No	Free-text notes.
`price`	No	Selling price per unit, in the record's currency.
`units`	No	Unit of measure label (e.g. "each", "hour", "kg").
`amount`	No	Unit amount before quantity/tax, in the record's currency.
`starred`	No	Whether the product is starred/favourited.
`currency`	No	ISO 4217 currency code (e.g. "ZAR", "USD"). Defaults to the business currency.
`quantity`	No	Number of units.
`trackstock`	No	Whether stock levels are tracked for this product.
`description`	No	Product description.
`paymentlink`	No	Whether an online payment link is enabled for this product.
`salestaxids`	No	Sales tax ids to link to this product.
`unlinktaxes`	No	Sales tax ids to unlink from this product.
`costcurrency`	No	ISO 4217 currency code for the cost price.
`allowoversell`	No	Whether the product can be sold beyond available stock.
`enablequantity`	No	Whether the buyer can choose a quantity for this product.
`requireaddress`	No	Whether a delivery/billing address is required when this product is purchased.
`salestaxexclusive`	No	Whether the price excludes sales tax.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 11, 2026

addedInput schema / properties / items / items / properties / sku

Added value: +{
+  "description": "Stock-keeping unit / product stock code. Canonical product-level SKU (mirrors a variant's sku).",
+  "type": "string"
+}

addedInput schema / properties / sku

Added value: +{
+  "description": "Stock-keeping unit / product stock code. Canonical product-level SKU (mirrors a variant's sku).",
+  "type": "string"
+}

First observedSep 7, 2026

TDQS

A4.4/5.0

Behavior4/5

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

With readOnlyHint=false and destructiveHint=false already declaring the safety profile, the description still adds real behavior: the items batch is an all-or-nothing transaction with a single ledger recompute, and the create path returns the new product id. It omits permission requirements and partial-update semantics for omitted fields, so not a 5.

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?

Three tight sentences: the upsert contract first, the return value second, the batch escape hatch third. No restatement of the title and no filler.

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

Completeness4/5

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

For a 24-parameter upsert with no output schema, the description covers the mode switch, the return value on create, and batch atomicity. It does not note that items entries accept fields the top-level object lacks, or what happens to existing values when a field is omitted, which is the main residual gap.

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. The description earns above baseline by explaining the id create-vs-update semantics and the transaction semantics of items, which the schema describes only as a vector of objects. The field-level descriptions (e.g. "$delete" for image, legacy unit vs units) remain the schema's job.

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+resource ('Create or update a product') and immediately disambiguates the two modes via the id parameter. An agent can distinguish this from save_variant, save_supplier, and save_client without opening any schema.

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?

Gives explicit mode selection (pass id → update, omit → create) and steers batch work to the items array ('Preferred over repeated calls' is echoed in the schema). It stops short of naming sibling alternatives or stating when not to use this tool, but the create-vs-update routing is unambiguous.

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

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