Skip to main content
Glama

Add catalog variants

add_catalog_variants

Add new variants to one existing catalog product on a catalog sheet. If get_import_guide or plan_import is missing, reconnect MCP. Do not invent barcodes, size steps, or currency. This is the follow-up after a confirmed plan. It does not take plan_token. Always call it with dry_run true first, then the same arguments without dry_run. Do not use it to import a whole file. Pass product_id (an existing variant row id on that sheet) or name (the exact style name). Does not create a product, does not change existing rows, and does not turn Catalog or the barcode generator on. option_1 and option_2 are the variant options (Colour and Size, or the mapped option columns). SKU is optional. A saved colour and size is skipped and listed under existing. A repeated option pair in this request, or a different SKU for a saved pair, is listed under conflicts and is not written. At most 100 variants. dry_run true returns added, existing, and conflicts and writes nothing. A dry run does not store idempotency_key. Pass idempotency_key on the write. The server assigns barcodes only when the barcode generator is already on. Do not send a barcode. Brand and type are copied from the existing product when omitted, and apply only to the new rows. Selling price and unit cost are written only when sent, and only on the new rows. Price changes on existing rows use bulk_update_items with the column header, not the sellingPrice role. The plan item limit still applies. Without a key, overlapping calls for the same organization, sheet, and product name are serialized in this process only. With a key, the in-process guard returns the first success for 10 minutes in this server process even when the arguments differ, and it is not shared across servers. Optional idempotency_key. Omit this field when it is not used. Null, an empty string, or only spaces are also treated as omitted. Use a unique value such as a UUID. The same key and the same arguments return the stored result for 24 hours and set idempotent_replay to true. A key still in progress is rejected until the lease expires (15 minutes by default). The same key can also stay reserved until the lease expires (15 minutes by default) after a call failed after writing rows, so check whether those rows were saved before trying again. The same key with different arguments is rejected. A stored result over 200 KB is replaced by a short summary of ids and counts.

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": {
      "sheet_number": "<sheet_number>",
      "variants": "<variants>"
    },
    "name": "add_catalog_variants"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNo
typeNo
brandNo
notesNo
dry_runNo
variantsYes
unit_costNo
product_idNo
descriptionNo
sheet_numberYes
selling_priceNo
idempotency_keyNoOptional. Omit this field when it is not used. An empty string is also treated as omitted. Use a unique value such as a UUID when you send one. Same key and same arguments return the stored result for 24 hours in this organization, with idempotent_replay true. A different payload is rejected.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations only give the generic readOnly=false, destructive=false, idempotent=false profile; the description adds real substance beyond that, including skip and conflict handling, the 100-variant cap, plan item limits, barcode-generator behavior, and the 15-minute lease/reservation semantics. The idempotency discussion is consistent with idempotentHint=false because it makes clear the key is what provides replay protection; however the very dense lease and 200 KB truncation details are hard to act on without re-reading.

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

Conciseness3/5

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

It is front-loaded with the core purpose and the dry_run-first workflow, which is good, but it is bloated: the idempotency_key paragraph restates the schema description nearly verbatim, and the lease/200 KB summary details are repeated and dense. Much of the length is justified by genuine semantics, yet it could be tightened by a third without losing meaning.

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 12-parameter mutation tool with no output schema, the description covers the important behavior: dry-run output keys (added, existing, conflicts), conflict rules, limits, and idempotent_replay. What is missing is what the successful write returns and what notes/description on the top-level payload do.

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 description coverage is only 8% (idempotency_key alone), so the description carries the burden and does so for most fields: product_id is an existing variant row id, name is the exact style name, option_1/option_2 are the mapped option columns, SKU is optional, and brand/type/prices apply only to new rows when sent. It leaves sheet_number, notes, and description unexplained, which is a visible gap at this coverage level.

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 first sentence states a specific verb and resource with scope: "Add new variants to one existing catalog product on a catalog sheet." It also explicitly distinguishes itself from siblings by ruling out product creation (create_catalog_product), whole-file import (plan_import), and existing-row edits (bulk_update_items).

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?

The description gives explicit when-to-use and when-not-to-use guidance: it is the follow-up after a confirmed plan, must be called with dry_run true first then without, must not be used for whole-file import, and price changes on existing rows must go to bulk_update_items instead. It even names the prerequisite tools (get_import_guide, plan_import) and says to reconnect if they are missing.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources