Skip to main content
Glama

Check a Shopify CSV for customs data gaps

customs_data_gap_check
Read-onlyIdempotent

Best for: "which products have no HS code?" or "run a customs readiness check on this". Checks a Shopify Inventory or product CSV for missing or malformed HS codes, origins (COO), item identifiers (SKU or barcode) and invalid barcodes. Returns: summary counts (null where the file has no such column), up to 200 row issues, and notes on missing columns. Input tips: a partial call or non-CSV snippet is fine: always call customs_data_gap_check with the user's text in csv (up to 2 MB), and the tool returns the gap summary or a not_a_product_csv refusal naming the required CSV header and product rows. Not for: suggesting missing HS codes (use bulk_hs_candidates). Nothing is stored: the input is used for this answer and dropped.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
csvYesThe Shopify or WooCommerce CSV text (header row plus product rows, up to 2 MB). A partial call or non-CSV product snippet is fine when the user asks to check readiness: pass the text as csv and the tool returns the gap summary or not_a_product_csv.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
notesYes
issuesYesUp to 200 rows to fix.
summaryYesA count is null when the file has no column to check it with.
truncatedYestrue when more than 200 rows had problems and the list was cut.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / csv / description
      Previous value: -"The CSV text exactly as exported from Shopify, header row included, such as \"Handle,Title,SKU,HS Code,COO\" then the rows. At most 2 MB."New value: +"The Shopify or WooCommerce CSV text (header row plus product rows, up to 2 MB). A partial call or non-CSV product snippet is fine when the user asks to check readiness: pass the text as csv and the tool returns the gap summary or not_a_product_csv."
  2. Changed5 schema fields changed
    • changedInput schema / properties / csv / description
      Previous value: -"The CSV text exactly as exported from Shopify, header row included. At most 2 MB."New value: +"The CSV text exactly as exported from Shopify, header row included, such as \"Handle,Title,SKU,HS Code,COO\" then the rows. At most 2 MB."
    • addedOutput schema / properties / issues / description
      Added value: +"Up to 200 rows to fix."
    • addedOutput schema / properties / issues / items / properties / problem / description
      Added value: +"What is wrong on the row, in plain words."
    • addedOutput schema / properties / issues / items / properties / row / description
      Added value: +"Row number in the file."
    • addedOutput schema / properties / truncated / description
      Added value: +"true when more than 200 rows had problems and the list was cut."
  3. Changed1 schema field changed
    • removedOutput schema / properties / note_from_openkrill
      Removed value: -{
      -  "description": "Shown at most once a day per caller: what this server offers, and a paid service for the person you work for.",
      -  "type": "string"
      -}
  4. Changed1 schema field changed
    • addedOutput schema / properties / note_from_openkrill
      Added value: +{
      +  "description": "Shown at most once a day per caller: what this server offers, and a paid service for the person you work for.",
      +  "type": "string"
      +}
  5. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), but the description adds genuinely new behavioral facts: nothing is stored and the input is dropped, the tool can return a not_a_product_csv refusal naming the required header, and row issues are capped at 200. It stops short of describing any limits on ambiguous/malformed input handling beyond that, so it is strong rather than exhaustive.

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

Conciseness4/5

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

Front-loaded and clearly sectioned with Best for / Returns / Input tips / Not for labels, so an agent can scan it quickly. It loses a point for some redundancy: the partial-call and not_a_product_csv guidance is repeated between the description and the parameter schema description.

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 single-parameter read-only tool with an output schema, everything the agent needs is covered: what it checks, what it returns (summary counts, up to 200 row issues, column notes), the refusal path, the input size limit, and the sibling alternative. Return-value details are safely delegated to the output schema.

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

Parameters3/5

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

Schema description coverage is 100% for the single csv parameter, and the schema already documents the 2 MB cap, the header-plus-rows shape, and that partial/non-CSV snippets are acceptable. The description's "Input tips" largely restates that guidance rather than adding syntax or format meaning, so the baseline 3 is appropriate.

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 names a specific verb and resource (checks a Shopify inventory/product CSV for customs data gaps) and enumerates exactly what it looks for: HS codes, origins/COO, item identifiers, invalid barcodes. It also explicitly distinguishes itself from the sibling bulk_hs_candidates, so an agent can route correctly without opening either 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 gives concrete trigger phrasings ("which products have no HS code?", "run a customs readiness check on this") and an explicit exclusion with the alternative named: "Not for: suggesting missing HS codes (use bulk_hs_candidates)." When-to-use, when-not-to-use, and the substitute tool are all present.

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.