Skip to main content
Glama

Create item

create_item

Create an item. Ask which sheet first. Pass Name/SKU/Price by display name. Pass Barcode/EAN/GTIN only when the source already has a real GTIN. If you omit it, the server reserves the next code when sequential assignment already works (typically Code 128). On a GS1 sheet, or a text column that already holds EAN-13 values, do not guess: Show choices together. Clickable form if the client supports it. Otherwise one number, only when it cannot show choices. Wait. Do not choose for the user. Do not continue until the user has answered. Do you want barcodes? No, no barcodes now (barcode_mode="none"). Cloudlabels generates EAN-13 (codes starting with 2 are internal store codes, not registered GS1 codes), barcode_mode="cloudlabels_ean13". This call only. Does not change sheet settings. I have my own codes (own GTIN). No option is recommended. A needs_input error lists those options. Cloudlabels can generate EAN-13 only; there is no UPC-A, EAN-8, or Code 128 generator mode. If the organization has opted in to its GS1 company prefix for this column and the sheet standard is EAN-13, UPC-A, or EAN-8, the server reserves the next prefix number before saving and returns barcodeSource gs1_prefix. The cell stores the digit body without the check digit. A full prefix is an error and does not fall back to a random code. The row is not saved if a barcode cannot be reserved. An existing barcode is never replaced. Do not invent a barcode. Do not pass organizationId. 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": {
      "fields": "<fields>"
    },
    "name": "create_item"
  }
}

Input Schema

NameRequiredDescriptionDefault
fieldsYes
barcode_modeNo
sheet_numberNo
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. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Beyond the annotations, the description discloses important behavior: barcode reservation fallback, GS1 prefix reservation, failure to save when a barcode cannot be reserved, never replacing existing barcodes, and idempotency replay/lease/truncation semantics. The disclosure is rich but repetitive and partly written as instructions to converse with the user rather than as tool behavior.

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

Conciseness2/5

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

The description is bloated and repetitive, notably repeating the 15-minute lease explanation, and it includes conversational instructions and sentence fragments like 'This call only.' Key parameter semantics are buried after long barcode guidance instead of being front-loaded.

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 four-parameter mutation tool with 25% schema coverage and no output schema, the description covers the complex barcode, GS1, and idempotency behavior thoroughly. It still omits return-value expectations and sibling routing, but the main behavioral risks are documented.

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 only 25%, so the description carries most parameter semantics. It explains that fields are passed by display name, distinguishes the allowed barcode_mode values and their effects, and gives extensive meaning for idempotency_key; sheet_number's 1-10 range is left to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening 'Create an item' gives a clear verb and resource, and the description scopes creation to a specific sheet with barcode handling. It does not name sibling tools such as bulk_create_items or update_item, so an agent gets a clear single-item purpose but no explicit differentiation.

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

Usage Guidelines3/5

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

It gives procedural guidance such as 'Ask which sheet first' and detailed advice for choosing barcode behavior, including that no option is recommended. However, it never states when to use this tool versus bulk_create_items or update_item, and much of the text is user-dialogue scripting rather than usage policy.

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