Skip to main content
Glama

Final POS – Custom POS Builder

Import outlets

hub_import_outlets
Destructive

Load a list of store locations in one call — opening a chain, migrating from another system. For one shop use create_outlet. Name, street address, city, state and postal code are ALL required on new rows, exactly as in the cabinet form; ask the merchant rather than inventing an address. Country is not settable: every outlet takes the company country, and the import fails outright if the company has none. 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. Bulk-created outlets differ from ones added in the cabinet in two ways worth telling the merchant: no Stripe location is wired up (payments must be linked per outlet afterwards) and stock rows are seeded in the background, so a fresh outlet can look empty for a while. This path also does NOT check the plan allowance, so it can push the company past the number of outlets it pays for — say so before importing more than a couple. Updates only set what you pass; alias and country cannot be changed here. Rows are independent and per-row failures come back in the reply. 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
createsNo
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?

Annotations already mark this as a non-read-only, destructive write operation, and the description substantially adds beyond them: it explains that creates rows are never matched or deduplicated, updates only set passed fields, alias and country are immutable, plan allowance is not checked, Stripe locations are not wired, stock rows seed in background, max is 500 rows, per-row failures return in the reply, and imports do not appear in the cabinet's Recent Imports list.

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?

The description is long but front-loaded with purpose and scope before caveats. Every sentence addresses a distinct operational risk of bulk destructive import, and the imperative 'BEFORE CALLING' guidance is easy to locate.

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?

Given a destructive bulk import with no output schema, the description covers preconditions, row requirements, update semantics, failure behavior, limits, side effects, and post-import communication needs. An agent has everything required to call it correctly and warn the merchant.

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?

Schema description coverage is 0%, so the description carries the parameter burden. It clearly differentiates the two top-level arrays: every row in `creates` becomes a new record, while `updates` requires ids from export_records or get_outlets and only sets fields that are passed. It also identifies the required create fields and the fields that cannot be changed here (alias and country).

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 and resource: 'Load a list of store locations in one call', with bulk scope made explicit by 'in one call'. It distinguishes itself from the sibling single-record tool by name: 'For one shop use create_outlet'. The creates/updates arrays are also clearly identified as the two modes.

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?

Gives explicit when-to-use scenarios ('opening a chain, migrating from another system') and the alternative tool ('For one shop use create_outlet'). It also states prerequisites (required fields, company country), prohibitions (no undo, no dry-run), and a pre-call protocol (preview rows, state row count, get explicit yes).

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.