Skip to main content
Glama

Final POS – Custom POS Builder

Import products

hub_import_products
Destructive

Load a spreadsheet of products in one call — "here are my 200 items", a catalogue from another POS, a price list. For one or two products use create_product instead: it can build variants from options, this cannot (every created row is a SIMPLE product with a single variant). This tool does NOT match rows against what already exists — the cabinet does that in the browser, not on the server. Every row in creates becomes a NEW record even if an identical one is already there. To change existing records, read them with export_records and pass their ids in updates. An update row is found by productId OR by sku (the SKU of its variant — what a spreadsheet has); a SKU that matches no product or several fails that row. price, costPrice, barcode and sku in an update go to the product's single variant; a product with several variants fails that row — use update_product for it. An update cannot clear categories; omit the field to leave them as they are. Prices are written as the merchant says them ("19.99"), in the company currency. Category entries may be names or ids: an unknown NAME is created as a new top-level category, so check the spelling against get_categories first or the import will litter the catalogue. Rows are independent — the reply lists per-row failures alongside what landed, so a bad row does not stop the rest. Max 500 rows per call. BEFORE CALLING: show the merchant a preview of the first few rows, state the EXACT number of rows and which resource they hit, and get an explicit yes. There is NO undo and no dry-run — nothing here validates without writing. If you are unsure a row is right, ask; a wrong bulk import is far more expensive to repair than a question. Afterwards, tell the merchant what landed: an import done here does NOT appear in the cabinet's Recent Imports list, which only records uploads made through the wizard.

Input Schema

NameRequiredDescriptionDefault
createsNoNew products, one per spreadsheet row
updatesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A5/5.0
Behavior5/5

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

The annotations declare destructiveHint=true, and the description richly adds behavior beyond that: no matching against existing rows, no undo, no dry-run, no server-side validation, per-row independence, ambiguous SKU failures, variant constraints, and no appearance in Recent Imports. This is unusually complete for a destructive bulk operation.

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?

Though long, the description is front-loaded and every sentence carries operational weight: purpose, alternatives, matching behavior, update constraints, pre-call confirmation, and post-call reporting. There is no filler, and the warning structure suits a destructive bulk tool.

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 complex, destructive, two-array import tool with no output schema, the description covers row limits, partial failures, update lookup, field routing, category side effects, and required merchant confirmation. It supplies what the schema and annotations do not.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With only 50% schema description coverage, the description compensates with crucial semantics: update rows are matched by productId or variant SKU, ambiguous SKUs fail, price fields target the single variant, multi-variant products fail, and categories cannot be cleared. It adds meaning well beyond the structured schema.

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 description states a specific verb and resource: loading a spreadsheet of products in bulk. It explicitly distinguishes itself from siblings like create_product and update_product, including variant limitations and update behavior. An agent can identify when this bulk-import tool applies without opening the 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?

It names clear alternatives and conditions: use create_product for one or two products, export_records plus updates for existing records, and update_product for multi-variant products. It also gives explicit pre-call procedure and size limits, leaving little to inference.

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.