@Final Commerce
基本信息
Build custom POS apps with your AI agent. Final's MCP server lets developers scaffold checkout flows, adapt vetted screen blueprints for counter POS, self-checkout kiosks, restaurant ordering and payment terminals, preview them live and deploy to real hardware with integrated card payments. The same server also manages the store behind it: products, stock, orders, customers and sales reports.
https://ai.finalpos.com/mcpclaude mcp add final --transport http https://ai.finalpos.com/mcpWho this connection acts as: organisation, user, the company Hub tools act on and the companies you may switch to, the allowed and listed packs, and how to reach tools that are not listed.
Every tool pack with its product, description, tool count and whether it is allowed for this connection and listed right now.
Search every allowed pack for tools by what you want to do ("low stock", "create a product", "deploy the app"). Returns matching tool names with their pack, whether they are listed and whether they change data. Run a read-only match with call_tool and a write with call_write_tool, or enable_packs to list its pack.
Run a read-only tool from any allowed pack by its full name (for example hub_find_low_stock) without it being listed. Only tools that read are accepted; tools that change data run through call_write_tool. Arguments follow that tool's own input schema, which find_tools returns.
Run a tool that creates, changes, deletes, sends or deploys from any allowed pack by its full name (for example hub_update_product) without it being listed. Only tools find_tools marks as writes are accepted; read-only tools run through call_tool. Arguments follow that tool's own input schema, which find_tools returns.
Add packs to tools/list for this connection (remembered). Only allowed packs can be listed; the client refreshes its tool list.
Remove packs from tools/list for this connection to keep the list short. Tools stay reachable through call_tool and call_write_tool.
Hand a task in words to Finai, Final's own AI agent, and get its finished answer. It runs as this connection's user on its company, within the allowed packs, and uses Final's tools itself (looking records up, creating products, building or deploying an app). Use it for multi-step merchant jobs you would rather describe than orchestrate; call tools directly when you need the raw data. Pass conversationId to continue an earlier thread.
Choose the company Hub tools act on, by id or name (get_connection lists them). Remembered on this connection.
COPY vetted blueprint widgets into a flow as real files — byte-exact, no transcription. Pass picks of { blueprintId, widgetId } (from list_blueprints / search_blueprints); the widget files land under src/widgets/<blueprint>/ with their command-frame plumbing intact, persisted as a restorable checkpoint + builder-chat note like write_flow_files. Returns a manifest (paths, export names, props, a ready-to-paste import block) — never the code. Compose your screens by importing the manifest paths; adapt an applied widget with a small write_flow_files edit, never a wholesale rewrite, and never re-type code from get_blueprint. A selfPersisting blueprint's copied code reads/writes its OWN custom tables by exact name: this tool PROVISIONS those tables into your organization automatically, possibly under org-scoped names (see `tables` in the result — the copied code already uses the final names) — never create them yourself and never create a lookalike. Tables owned by a platform extension are reported under `extensionTables` (with extensionIds when pinned): only installing that extension provides them (install_extension, with user consent). Secrets the code reads are reported under `secrets` — each missing key gets a fill-in request in the builder automatically; values never travel over MCP. Re-applying a pick restores the widget's vetted contents.
Apply the update reviewed with get_upstream_update. Pass resolutions: exactly one entry per conflict — { path, contents } with the COMPLETE merged file, or { path, delete: true } when the file should not exist. Missing, unknown or ambiguous entries fail the whole call with nothing written (the plan is recomputed here, so re-review if the flow changed since). What it does, in order: saves the current files as a restorable "Before update" checkpoint, lands the merged tree (an open builder tab picks it up safely), records an "Update from upstream vX" checkpoint narrated in the builder chat, re-stamps the clone's update pointer so the next check compares against this release, provisions custom tables the update introduced (org-scoped names — the merged code already uses them), and raises a fill-in request for each missing secret (values never travel over MCP). If the review said adoptMode: true, call with adopt: true and NO resolutions to replace the files with the original's latest release wholesale — undoable via the safety checkpoint; confirm with your user first.
Attach this agent session to an EXISTING flow as a chat in the builder's rail (so the flow's owner sees your work alongside their own chats). Also use log_message to narrate what you're doing.
Create a new custom data table (schema: name + typed columns) in your Final organization. USE THIS for any data the app must keep — loyalty stamps, waitlists, bookings, inventory logs, settings: the platform syncs the table to every station running the flow and keeps it working offline at the POS, so it replaces ANY browser-storage or hand-rolled persistence (localStorage/IndexedDB are forbidden and fail validate_flow). NEVER store credentials in a table — that's what the secrets vault (request_secret) is for. This creates the table IMMEDIATELY and ORG-WIDE (visible to every station and every flow, not just this one), so unless the user actually asked for stored data, confirm before creating; creation can also be plan-gated — surface a plan/permission error to the user rather than retrying. Check list_custom_tables first to reuse an existing table, and search_blueprints before building functionality around a new one: a selfPersisting blueprint brings its OWN tables by exact name and apply_blueprint_widgets provisions them for you, so a lookalike would sit dead while the feature keeps reading the real one. Create tables only for net-new data no applied blueprint persists. The name is normalized to kebab-case; generated code reads/writes rows via renderClient.getCustomTableData / upsertCustomTableData.
Create a new, empty flow (app build) in your Final organization for YOU to write the app into. It appears in the Miami builder immediately, with this agent session attached as a chat. Optional theme knobs seed the live palette. Optional `device` ("mobile", "kiosk", "iphone", …) sets the preview frame it opens in; see set_flow_device. Returns the flow id and a builder deep link. Call get_scaffold before writing files. For an app the user merely DESCRIBED, use start_build.
Create a NEW flow that starts as a complete, vetted application rather than an empty file tree — the fastest path to a working build when an FBB (a Final Business Blueprint: a whole app) matches what the user wants. For an app the user merely DESCRIBED, use start_build (the website's own start picks the FBB); this verb is for when the user asked YOU to copy one. Find one with search_blueprints({ kind: "fbb" }). The app's screens, navigation and command-frame wiring are copied byte-exact from the build the FBB points at, its custom tables are re-created under THIS organization's names (the copied code already uses those names — keep them), and a fill-in request is raised for each secret it reads. This ALWAYS creates a new flow: an FBB cannot be merged into an existing build (there are no screen-graph merge semantics). To add parts to a build you already have, use apply_blueprint_widgets instead. THE COPY ENDS YOUR TURN. It is the finished deliverable, not step one — the app is vetted and already runs. When it returns, say its `report` line and stop: do NOT preview, validate, edit or extend it, and do not start on anything else the user described. The result names the tools not to call.
Remove files from a flow's tree by path. Engine-owned paths are rejected. Recorded as a checkpoint + chat note like writes.
Direct deploy for CI/agent workflows: builds the app in a server sandbox (npm install + vite build) and publishes the dist to Final web-hosting as a new live version. Two things stop a deploy: a failing build, and a hardcoded credential (a build is distributable to other companies, so a baked-in secret would ship to all of them — use request_secret). Guardrail and type findings do NOT block; run validate_flow first if you want them. Omit `changelog` and the release notes are drafted for you from what changed since your last deploy — call log_message (or pass `note` on write_flow_files) as you work so those notes describe intent rather than just file names. Uses your organization's provisioned hub credential automatically (the same long-term org JWT the extension tools use) — no token argument needed once you've connected. Pass `hostingToken` only as an escape hatch to override it; if no credential is available, reconnect via the Connect dialog or use open_in_builder and deploy from the Launch tool instead.
INSPECTION ONLY — read a blueprint's overlay code by id (from list_blueprints) to understand how it works. To USE a blueprint, apply it: apply_blueprint_widgets for a widget-set (materializes its widgets byte-exact with the command-frame plumbing intact AND provisions the custom tables its code depends on), create_flow_from_blueprint for an FBB. Do NOT re-type code from this tool into write_flow_files — that silently drops the vetted plumbing and leaves its tables unprovisioned. `tables` (when present) lists the custom tables the code binds to by exact name. For a WHOLE-FLOW blueprint this returns the screen manifest WITHOUT file bytes by default — an entire app is far too large to read this way, and you never need to: instantiation copies it server-side. Pass includeFiles: true only to audit the source.
Authoritative server-side health probe of the flow's preview sandbox, plus a short snapshot of recent dev-server logs (useful to diagnose a red screen or crash).
The contract every Final flow app is built against: which files the ENGINE owns (never write them — they are re-asserted verbatim), the baseline package.json (Vite + React 19 + TS + Tailwind + command-frame), the rules your files must follow, and the runtime contracts that compile and preview fine but fail on a real device (money in minor units, the first-load handshake, getX response unwrapping, tender success semantics). Call this once before writing any files; pass `device` for layout guidance.
Has the build this flow was copied from released a newer version? Covers both a "Make it yours" clone of a listing and a build started from an FBB. Returns update.status: "available" (a newer deployed release exists — review it with get_upstream_update), "current" (up to date), "unknown" (the original has no comparable release), or "gone" (the original was DELETED — for a share clone, also if it was un-shared; an FBB's parent stays reachable while it exists, because the catalog vouches for it rather than the owner's share toggle), with the release notes published since the copy. Flows that are not snapshot-sourced copies return update: null. Cheap — safe to call whenever the user asks about updates.
Review what an update from the original build would change — the same review the builder shows its maker, shaped for an agent. Returns the releases since the clone, the clean changes (added/changed/removed paths, with full incoming contents for added+changed), and CONFLICTS: files where this flow's own edits and the update collide, each with complete base/ours/theirs contents. RESOLUTION CONTRACT (match the builder's behavior): when both sides' changes serve different purposes, merge them yourself — one file keeping BOTH sides' improvements; never wholesale-pick a side out of convenience. ONLY when the two sides genuinely contradict on the same visible thing (a color, a layout, a label, a behavior) ask YOUR user which they want, in plain product language — describe the visible difference, never file names or code. Then call apply_upstream_update with exactly one resolution per conflict. The trees you see are already in THIS organization's table namespace — never rename tableName literals yourself. adoptMode: true means the merge base is unrecoverable, so no merge is possible: offer the user adopting the latest release wholesale (apply_upstream_update with adopt: true) or staying put. upToDate: true means there is nothing to do.
Install an extension ORG-WIDE: creates the install link on EVERY company in your Final organization (demo companies included), skipping companies that already have it, so it is safe to retry. Installing is deliberate and org-visible — confirm with your user and call this ONLY when they explicitly asked for the extension. Find the id with list_extensions (organization and public extensions both install); after a successful install the extension's surfaces become embeddable — inspect them with list_extension_surfaces and build the ones carrying requirementsMd natively instead of embedding. Per-company failures are collected in the result rather than thrown, and `installState` reports the org-wide outcome (installed / partial / none).
List EVERY vetted, type-checked blueprint available to reuse — working functionality (gift cards, loyalty, payment surfaces, product grids, carts, customer views, order tickets, receipts), not just screen layouts. Check the catalog BEFORE creating custom tables or hand-rolling a capability. Returns id, kind, slot, title, summary, surfaces, tags, and selfPersisting per blueprint — selfPersisting: true means it reads/writes its OWN custom tables by exact name inside its code, which applying then provisions in your organization automatically (some are extension-owned and come from installing that extension); never create a table for a feature it covers. TWO KINDS, used differently: kind "widget-set" (the default this returns) is a set of parts you copy into an existing build with apply_blueprint_widgets; kind "fbb" is a Final Business Blueprint — a COMPLETE APP. It has no widgets to copy and is used with create_flow_from_blueprint to start a NEW flow. Pass kind: "fbb" to browse complete apps, or kind: "any" for both. To find the best match for a specific capability instead of scanning the whole catalog, use search_blueprints. get_blueprint is read-only inspection.
List your organization's custom data tables with their column schemas. Custom tables are Final's built-in, station-syncing database — data written on one station is automatically synced to every other station running the flow, and keeps working OFFLINE at the point of sale. They are the ONLY sanctioned persistence for generated apps (browser storage is per-device, never syncs, and is wiped on real Render terminals — validate_flow rejects it). Call this before create_custom_table to reuse an existing table instead of duplicating one. For NEW functionality, check search_blueprints before designing tables — a vetted blueprint may already provide the feature, and a selfPersisting blueprint's tables may NOT appear in this list (often extension-owned, resolved by name at runtime): their absence is never a reason to create lookalikes. Generated code reads/writes rows at runtime via renderClient.getCustomTableData / upsertCustomTableData (ground with lookup_command_frame).
List the CUSTOM TABLES an extension registers (table name + typed columns), so generated code can read/write its data at runtime via renderClient.getCustomTableData / upsertCustomTableData by table name (ground the calls with lookup_command_frame). Only the org's OWN extensions expose their tables — a public / other-org extension returns an empty list with a note. Pass the extension's id from list_extensions; the org's non-extension tables come from list_custom_tables. Read-only. Does not write files.
List the SURFACES an extension exposes — embeddable iframe injection points, each with a surfaceId, a platform (builder/hub/render), a type, and a url. Render an installed surface inside a generated screen with the engine component `<ExtensionSurface surfaceId="<surfaceId>" />` (ground it with lookup_engine_component). A surface may carry `requirementsMd` — full markdown build instructions for re-implementing it NATIVELY in the app: when present, prefer building that surface as first-class native screens in the app's own styling with real command-frame wiring, and embed `<ExtensionSurface>` only for surfaces without it. Works for the org's own extensions (hub credential) and public ones (resolved via the public marketplace, no credential needed). Pass the extension's id from list_extensions. Read-only. Does not write files.
List the platform EXTENSIONS available to your organization — the org's own plus the public marketplace — so you can suggest, inspect, or install one. Each entry carries an id, label, category, short description, and its source (organization or public); public results need no hub credential, and a note tells you when the org-owned side was unavailable. Pass query with the capability the user asked for — results are relevance-ranked against it (label, category, and the vocabulary of the blueprints each extension enables) and capped to the genuine matches, so an empty list means NO extension provides that capability. Omit query to browse the whole catalog with skip/limit paging — publicTotal reports how many marketplace rows exist. Inspect a result with list_extension_surfaces / list_extension_custom_tables; install it org-wide with install_extension ONLY when your user explicitly asked for it. Read-only. Does not write files.
List the flows (app builds) in your organization, newest first: id, title, timestamps, and live theme knobs. Final staff sessions also see Final's own flows, marked owner: "Final". Use a flow id with the other tools, or create_flow to start fresh. Clones of listed builds carry an upstreamUpdate field when the build they were copied from has released a newer version — review and apply it with get_upstream_update / apply_upstream_update.
List the key NAMES already stored in your organization's encrypted secrets vault — never the values (no tool returns a secret value). Use this to (a) reuse an existing key instead of requesting a new one, and (b) poll whether a request_secret ask has been fulfilled by the human. Generated code reads a secret at RUNTIME with renderClient.getSecretVal({ key }) — the build ships key names only.
Record a message in this agent's chat inside the builder — the user's request (role 'user') or your own progress/summary (role 'assistant'). Keeps the builder timeline faithful to what happened in this session.
Look up the EXACT, version-locked command-frame API a generated Final POS app runs on: renderClient method signatures + params, CF* entity field lists, pub/sub topic event vocabularies, and worked examples. Pass one of method/entity/topic for a precise lookup, entity+field to confirm a field exists, query for fuzzy search, or the plural batch forms. Ground every renderClient call in this before writing it — fabricated fields/methods fail on real Render devices. Typed signatures and entity fields are authoritative; the worked examples come from upstream docs and are NOT typechecked, so where they disagree, trust the types. Results carry `traps` for known field-level gotchas.
Look up the exact props/signature of an engine-owned `./final/*` helper: the `@/final/ui` primitives (Button, IconButton, Card, Tile, Input, Field, Chip, ListRow, Dialog, Sheet, Toolbar, Heading, EmptyState, cn) plus usePrint, StationHomeButton, SwitchUserButton, useStationHome, Barcode, BootSplash. These are re-asserted into every generated app — compose screens from the primitives (see get_scaffold contracts.designLadder) and import the rest instead of hand-rolling buttons/cards/dialogs, printing, station-home/switch-user, barcodes, or the loading splash. Pass name for a precise lookup, query for fuzzy search, or neither to list all.
Look up the Final POS REST API (https://api.finalpos.com) — endpoint method/path, request fields, response shape, and a worked fetch example. This is the ONLINE-ONLY fallback for admin/management operations command-frame cannot express (creating products/variants/categories, customer management, outlets/stations/tax tables, webhooks). Command-frame is ALWAYS first choice for live POS data — it works offline and the host owns money/totals. A call to this API is network egress from the station: it fails whenever connectivity does, so never put one in the sale path — use it for setup/admin work and degrade gracefully. Pass resource to list a domain, operation for one endpoint, or query for fuzzy search.
The recommended way to finish: a deep link that opens this flow in the Miami builder, where the owner can review the work, restore checkpoints, and deploy through the Launch tool (validation gates, listing media, changelog, version history).
Read a flow's generated source tree. Omit `paths` to list all file paths (cheap); pass `paths` to fetch specific files' contents.
Rename a build (flow) authoritatively across the platform in one call: the builder header, list_flows / open_in_builder, and the Deerlake catalog all reflect the new title, and updatedAt is bumped. A deployed build keeps its hosted web app: the hostname and version history are unchanged, and the next deploy_flow publishes the next version. Does NOT edit the app source: rename a hardcoded old name yourself with write_flow_files.
Ask the flow's owner to enter a third-party credential (API key, auth token, webhook secret) into Final's encrypted vault. THIS TOOL TAKES NO VALUE and no tool ever returns one — the human types it into a masked input in the Miami builder, and it goes straight into the vault. Why: flow builds are DISTRIBUTABLE to other companies, so a credential must never be baked into the code (validate_flow and deploy_flow scan for and block hardcoded secrets). Your generated code reads it at RUNTIME with renderClient.getSecretVal({ key }) and must degrade gracefully while the key isn't stored yet (disable the integration + tell the user to configure it — never crash). After calling this: tell YOUR user to open the builder link and enter the value, and poll list_secret_keys to detect when it lands.
SEMANTIC search over the vetted blueprint catalog — matches are ranked by what you MEAN, not by shared words, so describe the capability in plain language ('rewards for repeat customers' finds the loyalty blueprint). RUN THIS FIRST — before creating custom tables or hand-rolling a capability: blueprints ship working FUNCTIONALITY (gift cards, loyalty, payment surfaces, carts), not just screen layouts. Search once per FEATURE you're adding (smart grid, gift cards, loyalty points, receipts) and REPEAT it for each distinct capability rather than issuing one broad query — a build usually combines several. Returns { results, note? }: blueprint summaries (id, slot, title, summary, surfaces, tags, selfPersisting, match score in [0,1]) best match first. selfPersisting: true means the blueprint reads/writes its OWN custom tables by exact name inside its code, and apply_blueprint_widgets provisions them in your organization automatically (extension-owned ones come from installing that extension) — NEVER create a table for a feature it covers. Prefer this over list_blueprints when you know what you need. Pick the widgets you need and copy them with apply_blueprint_widgets({ flowId, picks }) — applied ON TOP of the current build, never replacing it. Low match scores across the board mean no vetted blueprint fits — only then build that piece from scratch grounded in the command-frame docs. Optional `slot`/`surface` narrow the results; `limit` caps how many are returned (default 10).
Boot the flow's server-side preview sandbox (Vite dev server) — or reconcile a running one to the flow's current files — and return its public HTTPS URL already pinned to this flow's mock dataset: the maker's pick, else its vertical's (sushi, not restaurant). Open the URL in a browser to see the app; call again after write_flow_files to sync. Previews idle-stop on their own; call stop_preview when done to free resources sooner.
Stop the flow's preview sandbox and free its resources. The next start_preview cold-boots in a couple of seconds.
Reconcile a (running or cold) preview sandbox to the flow's current files and run the green-build gate (tsc + vite build). Returns the gate result — the fastest way to know your code actually compiles. The engine forces parts of package.json on every sync: the dev/build/typecheck scripts, and the vendored command-frame + mock packages to their bundled tarballs. Baseline and build dependencies are re-added only when you declared them nowhere, so your own additions and pins survive. Shares one rate bucket with start_preview — sync once per change-set, not per file.
Evolve an EXISTING custom data table's schema: add columns, change existing ones (rename/retype — destructive for stored rows, use sparingly), or drop columns. The table is identified by its kebab-case name from list_custom_tables. Tables are ORG-WIDE, so a schema change lands for every flow and station already using this one — check who reads it before reshaping. NEVER rename or reshape a table a selfPersisting blueprint reads/writes — its copied code references the exact current names. Per-operation failures are collected rather than aborting the whole change. Row data itself stays a runtime concern of the generated app (renderClient).
Deterministic STATIC checks against the platform contract: (1) guardrails — fabricated renderClient methods, forbidden browser APIs/imports, engine-file writes; (2) a REAL TypeScript check of command-frame usage against the PINNED .d.ts the app installs (the version is stamped in the result) — this proves TYPES, never runtime behaviour and never device parity; (3) a hardcoded-credentials scan; (4) `flowTypeErrors` — a whole-tree `tsc` against REAL react types, which catches what (2) cannot see (e.g. a `useEffect` cleanup that returns a value, a hard TS2345 the builder's in-chat gate will report to whoever opens this flow); plus advisory `warnings` (client money math, hardcoded catalog data, missing station-home/data-test, tip-as-cart-fee) that don't affect `clean` but each predict a real on-device failure. secretFindings BLOCK deploy_flow; everything else is advisory. Run it after each write batch, before start_preview.
Create or overwrite files in a flow's tree (full contents, not diffs). Engine-owned paths are rejected — see get_scaffold. Every write lands as a restorable checkpoint and is narrated in the builder chat. If a live preview is running, follow up with start_preview to sync it. Validate with validate_flow before deploying. If a call returns an error the files may STILL have landed (and a very large payload can truncate mid-file) — re-read with read_flow_files before retrying, never blind-retry. Because writes replace whole files, keep files small and single-purpose so an edit can't clobber unrelated working code.
Add a note to a customer — an allergy, a preference, what happened with an order. Existing notes are KEPT; this appends. Takes the customer ID from get_customers. Staff read these in the cabinet, so write what the merchant said, not your own summary.
Add one choice to an existing modifier, leaving the rest alone. This is the safe way to extend a modifier — unlike update_modifier, it cannot drop anything. Appends to the end unless sortOrder says otherwise. price is the extra charge per unit as a human amount ("0.70"); omit it for a choice that costs nothing, which still prints on the receipt.
Add photos to an existing product — from public URLs, or as base64 bytes when the merchant attached the file itself and there is no URL. URL images are downloaded and stored on the platform, so the product never depends on someone else's site staying up. Existing photos are KEPT — this adds to them. JPEG/PNG/WebP/GIF/HEIC, up to 20MB each. Takes the product ID from get_products, never a name.
Add an EXISTING rate to a tax group, or change that rate’s compounding flag within the group. Both ids come from get_taxes. This shares the rate — it does not copy it. The group starts charging the rate’s existing per-outlet percentages, and a later edit to that rate changes this group too. Use create_tax_rate instead when the rate does not exist yet. The rate is appended last in the charging order; use update_tax_group with rateIdsInOrder to move it. CONFIRM WITH THE MERCHANT — this immediately adds tax to every product in the group. Sales already rung up are NOT recalculated — this only affects sales from now on.
Change the count of ONE variant at ONE outlet — the cabinet's "Adjust Inventory" action. CONFIRM WITH THE MERCHANT FIRST, repeating the product, the outlet, the reason and the number: this writes immediately, is permanently recorded against the employee in the stock history, and there is no undo from here. Reasons: STOCK_RECEIVED (a delivery arrived) and RESTOCK_RETURN (a return put back on the shelf) ADD the quantity; DAMAGE, THEFT and LOSS SUBTRACT it; INVENTORY_RECOUNT SETS the count to exactly the quantity you pass (a physical stocktake). Always pass quantity as a positive number — the reason decides the direction. Pick the reason the merchant actually gave; these end up in reports, so recording theft as damage misstates their loss. If stock is not tracked for that variant at that outlet, NOTHING is written and the result says applied: false — do not report success, and do not read it as "the stock is 0". Tracking has to be turned on for the product first. To move units between outlets use create_stock_transfer instead.
Move a team member onto a different role — this is how someone gains or loses access. Answers 'give Maria access to the reports', 'make him a cashier again', 'take away her permissions'. PERMISSIONS ARE POWER. Confirm with the merchant first, naming the person and the role out loud ("give Maria the Manager role — yes?"), and never act on a role change you inferred rather than were asked for. The change is live on the next request: rights are re-read from the role every time, so no one logs out and no agent key stops working — including yours, if the change reaches your own account. It swaps their WHOLE permission set for that role’s, so read get_roles first and check the new role really carries what the merchant asked for and nothing dangerous besides — if no existing role fits, say so rather than picking the closest one. You may also point the merchant’s own account at another role, including the account this agent key belongs to, which would change your own permissions from the next call onward: never do that unless the merchant asked for it in those words. To change what a role itself allows, without moving anyone, use update_role.
Release a booked window. The order stays as it is — cancelling a booking is not a refund, and money is never moved here; if the customer is owed money, do that on the order. Confirm with the merchant before cancelling a booking somebody already paid for.
Cancel an order the merchant no longer wants. CONFIRM FIRST, naming the supplier and the PO number — there is no undo, and the order disappears from the list rather than showing as cancelled. REFUSED once any stock has been received against it: that stock is real and the record has to stay. Receive the rest instead, or leave it partially received. Cancelling does NOT tell the supplier anything. If the order was already sent, the merchant still has to contact them — say so.
Turn a hold into a real booking once the order behind it is paid, so it stops expiring. Needs the order the booking was sold on — confirming without one is refused, because a confirmed booking nobody can find on a receipt is worse than an expired hold.
Add one bookable thing to the company directory. Call get_booking_resources first — a resource is reused across every service, so a second "Marco" would split one barber into two calendars and let him be booked twice at once. The name is what staff will see in the calendar.
Create a booking policy. Call get_booking_rules FIRST and reuse a matching set instead — these are shared company-wide, not per product. `weeklyHours` are LOCAL wall-clock times at the outlet; if neither the outlet nor the company has a timezone the engine refuses availability with a 400, so fix the outlet rather than guessing an offset. `bufferMinutes` consumes grid time for slot bookings (cleaning between appointments); for overnight stays use checkInTime/checkOutTime instead and leave the buffer at 0 — the cleaning window lives in the gap and does not consume a night.
Create a product category. Call get_categories FIRST — a second "Drinks" is easy to make and there is no merge. Pass parentId to make it a subcategory; leave it out for a top-level one. The cabinet's own form asks for a description, so ask the merchant for one rather than inventing it. This does NOT move any product into the category — do that with update_product and its categoryIds.
Create a customer. Call get_customers with the email or name FIRST — a duplicate splits one person’s order history in two and there is no merge from here. Email is required, exactly as in the cabinet's own customer form. Ask the merchant for anything you do not know instead of inventing it — an invented phone number or address is worse than a missing one.
Create a new question the till can ask, with its choices. THIS ALONE DOES NOTHING AT THE TILL — follow it with link_modifier_to_category, or the modifier sits unused. Choose selectionType carefully, because it CANNOT be changed afterwards: "single" = pick exactly one (milk, cooking temperature); "multiple" = tick any number of different choices (toppings); "multiple" with allowQuantity true = tick choices AND say how many of each; "quantity" = every choice is a stepper (extra shots). The last two count UNITS, not distinct choices. allowQuantity is only accepted on "multiple" and is refused on the others. Names must be unique for the merchant, ignoring case.
Open a new point of sale — the cabinet’s Add Outlet form. Name and the full street address (address, city, state, postCode) are all REQUIRED, exactly as on that form. Do NOT try to set a country: every outlet inherits the company’s country, and it can never be changed per outlet. Ask the merchant for any part of the address you do not know — an invented address ends up on receipts. This is BILLABLE: a new outlet counts against the company plan’s outlet allowance and the call is refused once that allowance is used up. Confirm with the merchant before calling. Afterwards the platform seeds a stock row of 0 for every product at the new outlet in the background, so its stock reads as empty until someone receives or transfers stock in. Linking a Stripe account to the outlet is NOT possible from here — the merchant does that in Settings → Outlets.
Create a product in the merchant's catalogue. Call get_products first to make sure it does not already exist. Prices are HUMAN strings like "19.99" — this tool converts them into the company's currency itself, so never send cents. Tax: the company's standard tax table is applied by default; pass taxable:false for an untaxed product. Ask the merchant for anything you do not know instead of inventing it.
Create a new variation axis with its possible values. Use it only when get_product_options shows nothing suitable. The axis is shared across the whole catalogue, not one product — so confirm the name and values with the merchant first and reuse an existing axis when one fits.
Write a new order to a supplier. It is created as a DRAFT — nothing reaches the supplier and no stock moves until send_purchase_order. PREREQUISITES, in this order: get_suppliers for the supplierId, get_outlets for the outlet the goods will be delivered INTO, then get_supplier_items WITH that outletId for the lines — variantId and unitCost come from there, and an item that is not linked to this supplier is refused. unitCost is what the merchant pays per unit as a human amount ("12.50"), prefilled from the supplier link but editable if this order was negotiated differently. quantity is in the item’s selling unit and may be fractional for goods sold by weight or length. Read the lines back to the merchant with the total before sending — a wrong quantity here becomes wrong stock later.
Create a new role with a chosen set of permissions — for when no existing role fits what the merchant wants someone to do. Check get_roles first; a near-match plus update_role is usually better than a fourth almost-identical role. PERMISSIONS ARE POWER. Confirm with the merchant first, naming the person and the role out loud ("give Maria the Manager role — yes?"), and never act on a role change you inferred rather than were asked for. The change is live on the next request: rights are re-read from the role every time, so no one logs out and no agent key stops working — including yours, if the change reaches your own account. Permission ids come from get_permissions. List back in plain words what the role will be able to do and get an explicit yes before calling. Creating a role gives nobody anything until assign_role puts a person on it. If you are signed in as an employee you can only grant permissions you hold yourself — the cabinet works the same way — and the call is refused otherwise.
Add a VIRTUAL till — a browser-based station, the cabinet’s "Add Virtual Station". It is created at one outlet and starts AVAILABLE. You CANNOT create a native (device) station from here and must not try: a physical till enrols itself when someone opens the POS app on the device and names it there. THIS IS BILLABLE — a new station counts against the company plan’s station allowance and the call is refused once that allowance is used up. Confirm with the merchant before calling. flowSrcId is the POS layout the till runs. The cabinet’s wizard makes picking one mandatory and there is no tool here that lists flows, so unless the merchant gave you an id, create the station and then tell them plainly to open Run → Stations and choose the flow — until they do, the station exists but cannot be launched.
Move stock from one outlet to another — 'send 10 of these from the warehouse to the King Street shop'. CONFIRM WITH THE MERCHANT FIRST, naming both outlets and every quantity: this writes immediately and there is no undo from here. The stock LEAVES the source outlet at once; the destination only gains it when someone confirms arrival with receive_stock_transfer, so until then those units are in transit and count in neither shop. Tell the merchant that. Variant ids come from get_products, outlet ids from get_outlets. Check availability with get_stock first: sending more than the source holds is rejected, and so is sending a variant whose stock is not tracked at the source — there is no count there to move. To correct a count in place (damage, theft, a recount) use adjust_stock instead; to book in a supplier delivery use adjust_stock with STOCK_RECEIVED.
Add a business the merchant buys from. Only the name is required, and it must be unique among this company’s suppliers. Set contactEmail if the merchant will ever email purchase orders to this supplier — send_purchase_order has nowhere to send without it. A brand-new supplier carries NO items, so it cannot be ordered from yet: link its items with link_supplier_items before creating a purchase order. Ask the merchant for details you do not have rather than inventing them — this ends up on the orders their supplier reads.
Create an empty tax group (a tax profile that products get assigned to, e.g. "Standard", "Food", "Zero-rated"). Call get_taxes FIRST — a second group with the same meaning splits the catalogue and is a common way to end up charging two different taxes for one thing. The group charges nothing until you add rates with create_tax_rate or add_tax_rate_to_group, and no product uses it until someone assigns it. isStandard marks the company default — set it only if the merchant explicitly says so. CONFIRM the name with the merchant before calling.
Create a named tax rate ("State Sales Tax", "GST") with its percentage, and optionally put it straight into a tax group. Check get_taxes first: if a rate with this meaning already exists, add_tax_rate_to_group reuses it, which is almost always what the merchant wants — duplicating a rate means the next change has to be made twice and one of them gets forgotten. Give either percentage (the same at every outlet) or perOutlet (different per store) — never both, and never neither, since a rate with no percentage charges nothing. Without taxGroupId the rate exists but is charged nowhere. CONFIRM THE EXACT PERCENTAGE WITH THE MERCHANT before calling — do not infer it from suggest_tax_rate or from what is usual in that region. Sales already rung up are NOT recalculated — this only affects sales from now on.
Add a POS user — someone who signs in at the till with a PIN. Mirrors the cabinet’s "New POS user" form: first and last name, a 4-6 digit PIN, a role, optionally a phone. They get access to every outlet of the company, which update_user can narrow afterwards. BACK-OFFICE (Hub) users are NOT created here: those are invited by email from the cabinet, and that invitation flow is not available through this tool. If the merchant wants someone who can log in to the back office, say that and point them at Manage → Team → Users → Add User. The role decides what the new person may do, so PERMISSIONS ARE POWER. Confirm with the merchant first, naming the person and the role out loud ("give Maria the Manager role — yes?"), and never act on a role change you inferred rather than were asked for. The change is live on the next request: rights are re-read from the role every time, so no one logs out and no agent key stops working — including yours, if the change reaches your own account. A new user also counts against the company plan’s user allowance and the call is refused once it is used up.
Delete a category. Takes the category id ONLY — look it up with get_categories and never guess. CONFIRM WITH THE MERCHANT BEFORE CALLING, naming the category: there is no undo from here. Products in the category are NOT deleted — they are kept and simply lose this category, so a product that had no other category ends up uncategorised. A category that still has subcategories is refused: move or delete those first. So is a category synced from an integration.
Remove a customer from the merchant's list. Takes the customer ID ONLY — look it up with get_customers and never guess. CONFIRM WITH THE MERCHANT BEFORE CALLING, naming the customer: there is no undo from here. Their past orders are kept. If several customers match, list them and ask which one instead of picking.
Permanently delete one file from the media library. Takes the file ID from get_media_library ONLY — never guess it. CONFIRM WITH THE MERCHANT BEFORE CALLING, naming the file: the image is destroyed and there is NO UNDO. Tell them this too, because the platform does not check it and nothing is cleaned up afterwards: if any product or category uses this image, it KEEPS the dead URL and its picture turns into a broken image — the file is not detached, it is only made unreachable. There is no reverse lookup here from a file to the products using it, so if they are unsure, say so and let them check on the Media screen in the cabinet rather than deleting on a guess. The file may also stay listed on that screen afterwards, because that screen is fed by a separate service. Removing a photo from ONE product without destroying the file is not this tool — that is a product edit.
Remove a modifier from the catalogue AND detach it from every category at once — the till stops asking it everywhere. Check get_modifier first and tell the merchant which categories lose it. To stop asking it in ONE place only, use unlink_modifier_from_category. Past orders keep the options that were already rung up.
Remove one choice from a modifier. Refused when it would leave a category asking for more choices than remain — the explanation names the category.
Close a point of sale permanently. Takes the outlet id from get_outlets. CONFIRM WITH THE MERCHANT FIRST, naming the outlet — there is NO undo from here. Tell them what goes with it: the stock recorded AT that outlet is removed and is NOT moved anywhere else (transfer it out first if they want to keep it), and so are the outlet’s tax rate values and its per-outlet product visibility. Past orders, sessions and reports still name the outlet and are not touched, and the stations that belonged to it are NOT deleted — they have to be dealt with separately. An outlet that WooCommerce uses as its default is refused: the merchant must change that default or uninstall the WooCommerce extension first.
Remove a product from the merchant's catalogue. Takes the product ID ONLY — look it up with get_products and never guess. CONFIRM WITH THE MERCHANT BEFORE CALLING, naming the product: this also removes all of its variants and there is no undo. If several products match, list them and ask which one instead of picking.
Delete a role the merchant no longer uses. Takes the roleId from get_roles. CONFIRM FIRST, naming the role — there is no undo. A role that anyone still holds cannot be deleted: the server refuses and tells you how many people are on it. Move them with assign_role first, and check with the merchant which role they should land on — that move changes what those people can do. You cannot delete the role you are signed in under.
Remove a till from Run → Stations. Takes the station id from get_stations. CONFIRM WITH THE MERCHANT FIRST, naming the station — there is NO undo from here, and it takes a working register out of service: the device that used it has to be set up again in the POS app, and it comes back as a NEW station with a new id. A station reporting IN_USE is REFUSED, exactly as the cabinet greys the button out — the shift has to be closed on the device first. If the merchant insists that till is idle, the flag is stale (it was closed while the device was offline); it clears once the device reconnects, so try again then instead of forcing anything. Past orders, sessions and End of Session reports keep naming this station and are not touched.
Remove a supplier the merchant no longer buys from. CONFIRM WITH THE MERCHANT FIRST, naming the supplier — there is no undo from here. Its item links go with it, so any auto-reorder rule pointing at this supplier stops producing suggestions. REFUSED while the supplier still has an open purchase order (anything not fully received): receive or cancel those first — get_purchase_orders filtered by this supplier shows them. Purchase orders already placed are kept and still name the supplier.
Delete a tax group. Takes the tax group id from get_taxes. THIS MOVES PRODUCTS: every product assigned to this group is re-pointed at replacementTaxGroupId, or — if you omit it — left with NO tax group at all, meaning those products are sold UNTAXED from that moment. Always ask the merchant which of the two they want and pass a replacement unless they say otherwise. The rates inside it are NOT deleted; they stay available to the other groups (use delete_tax_rate if the merchant really wants a rate gone). CONFIRM WITH THE MERCHANT BEFORE CALLING, naming the group and how many products it affects. There is no undo. Sales already rung up are NOT recalculated — this only affects sales from now on.
Permanently delete a tax rate FROM THE WHOLE COMPANY. Takes the tax rate id from get_taxes. THIS CASCADES: the rate is stripped out of every tax group that lists it and all of its per-outlet percentages are deleted with it. Products in those groups immediately stop being charged this tax. This is almost never what a merchant means when they say "remove the tax from X" — that is remove_tax_rate_from_group. Use this one only when they say the rate should not exist at all any more. CONFIRM WITH THE MERCHANT BEFORE CALLING, naming the rate and listing every group it will disappear from. There is no undo and no way to recover the percentages. Sales already rung up are NOT recalculated — this only affects sales from now on.
Dump one resource in spreadsheet shape — every record flattened to the same columns the import tools accept, WITH its id. Answers 'export my catalogue / my customers', and it is the required first step before any import that changes existing records: the `updates` arrays all key on the ids this returns. For QUESTIONS about the data ("how many products", "find John") use get_products / get_customers / get_categories / get_outlets / get_options instead — they read better and filter server-side. LIMITATIONS: no filtering and no sorting; records come back in stored order, one window at a time. It also cannot produce a FILE — if the merchant wants a .csv/.xlsx download, send them to Settings → Import / Export → Export in the cabinet and do not page through thousands of rows to imitate it. Money is in minor units (cents), matching what the import tools read back.
The stock export file for ONE outlet, as CSV text: Variation ID, Product Name, Variation name, SKU, Stock Management, Cur Qty, New Qty. Use it when the merchant asks for the stock sheet itself — a stocktake worksheet, a hand-off to a supplier, 'give me my stock as CSV'. For stock QUESTIONS — how many of X are left, what is running out, history of a change — use get_stock, find_low_stock and get_stock_history: they filter on the server and explain when tracking is switched off. This dump includes untracked rows and cannot tell "zero" apart from "not counted here". It is READ-ONLY: to write counts back, edit the New Qty column and send the file to import_stock_csv. Large catalogues are truncated — the reply reports the true row count.
What is running out. Answers 'what is low', 'what do I need to reorder', 'what has run out at the warehouse'. Returns the stock-tracked (variant, outlet) lines at or below a threshold, lowest first. Threshold defaults to 5; pass threshold: 0 for "what has actually hit zero". Lines where stock is NOT tracked are excluded on purpose — they have no count, so they can never be low, and reporting them would invent a shortage that does not exist. This is per outlet: the same variant can be empty in one shop and full in another. For one specific product use get_stock instead.
The bookable windows for a product over a date range, per resource, with what is already taken. Quote times from THIS — never compute a grid yourself: the engine applies the hours, the buffer, notice and advance limits, and the outlet timezone, and a hold whose start is not exactly a slot start is refused. Ask for a few days at a time; a year-wide range is slow and pointless.
The trail of what happened to bookings — held, confirmed, cancelled, expired — newest first, with who did it. Use it to answer "what happened to this booking"; an actor of `system` is the server freeing an expired hold, not a person. Each row is immutable, so this is the record even when the booking itself is gone.
List what can be booked — the staff, rooms, tables or assets in the company directory. A resource is whatever can only be in one place at a time, and it is shared across services: the same barber is one resource whether he cuts hair or trims a beard, which is why booking him for one closes the other. Read this before creating anything and reuse what is there.
List the reusable booking policies the merchant already has — opening hours, slot length, buffer, how far ahead people may book. A rule set is shared by every product pointing at it, exactly like a tax table, so ALWAYS read this before creating one and offer an existing set when it fits. Editing a set changes every product that uses it.
The merchant's product categories, as the tree they see in the cabinet: every category with its subcategories nested inside it, sorted by sortOrder. Answers "what categories do I have", "is there a Drinks category", "where does Beer sit". Use it to get the category id any other tool needs. It returns categories ONLY — never products, and never a product count. There is no way to list the products of a category from this server today: get_products searches by name or SKU and cannot filter by category, so say that plainly instead of guessing. To put a product INTO a category, go to the product side: create_product / update_product take categoryIds. The whole tree comes back at once — there is no paging and no search argument, so filter by name yourself.
Where modifiers are actually asked: one row per category↔modifier link, with that category’s own rules (required, min, max, order). This is what makes a modifier reach the till, so use it to answer "what options does this category ask" or "where is this modifier used". Narrow to one category with categoryId. Remember products also inherit their ancestors’ links, so a subcategory asks more than its own rows show. The id on each row is the LINK id — that is what update_category_modifier and unlink_modifier_from_category take.
Everything known about ONE customer: addresses, notes, how many orders they placed, what they spent and what was refunded. Takes the customer ID from get_customers, never a name. Use it before answering a question about a specific person — the list leaves notes and refunds out.
ONE customer's history as a single timeline, newest first: their orders AND the refunds taken against them, each row marked type "order" or "refund" — the same list the customer screen shows. Answers 'what has this person bought', 'did we refund them', 'when were they last in'. Takes the customer ID from get_customers, never a name. get_orders with customerIds returns the orders alone and a total count; use this tool when the refunds belong in the answer. No total count comes back here — keep paging until a page returns fewer rows than asked for.
List the merchant's customers. Answers 'who are my customers', 'find John's email', 'has this person bought from us'. Search matches email, first name, last name and full name — NOT phone numbers, addresses or notes. LIMITATION — there is no sorting: results come back in stored order and cannot be ordered by spend, name or last visit. So 'my best customers' or 'who spent the most' CANNOT be answered from this tool, and you must NOT page through everyone trying. Say plainly that sorting is not supported yet, then offer what does work: search by a name or email, or ask the merchant to narrow it down.
The orders ONE staff member rang up in a date range. Takes the employee id from get_employee_sales, never a name. Use it to back up a claim about a person — 'show me the sales behind Maria's number', 'which orders did he refund'.
Sales per staff member for a date range — Reports → Employee Sales. Answers 'who is my best seller', 'how much did Maria sell', 'who took the most refunds', 'average ticket per employee'. One row per employee with orders, gross sales, refunds, tips and average transaction. Staff lists are short, so ranking is safe: pull the rows and sort them yourself rather than asking the merchant to narrow down. Pass employeeId to get a single person. For the actual orders one person rang up, use get_employee_orders.
The extension STORE: every built-in extension the platform offers, the same list for every merchant. Answers 'what can I add', 'do you have a WooCommerce integration', 'can I get X'. For 'what do I already have', use get_installed_extensions instead — this tool only flags each entry with `installed`. `availableOnYourPlan: false` means the subscription plan excludes it: the store hides it in the cabinet and install_extension will refuse — say so instead of trying. LIMITATIONS, do not paper over them: the platform stores only a name, a category, a price and an id per built-in extension — there is NO stored description, so do not invent what an extension does; say what the name and category say and offer to open its page in the cabinet. `price` is a bare stored string with no currency attached — quote it verbatim, never as a formatted amount. Custom extensions built by an organisation are NOT in this list (they need an organisation scope this agent key does not carry); they do show up in get_installed_extensions once installed.
What the installed extensions ADD to the apps — the answer to "where did this new menu item come from", "what is this extra block on the product page", "what did installing X actually change". Every entry belongs to an installed extension; nothing here is part of the base product. Read `platform` to know where it shows up: `hub` = this admin cabinet, `builder` = the POS flow builder, `render` = the station screen. Within `hub`, type `merchant-hub-page` is a navigation entry of its own and `merchant-hub-widget` is a block embedded in a detail page — `attachedTo` says which one (products / orders / customers / users). LIMITATION: this tells you which extension-provided screens EXIST, not what they contain — each one is an embedded page owned by its extension, and this agent cannot open or read it. It also cannot say which extension contributed a given entry. To go the other way — what is installed at all — use get_installed_extensions.
THE headline money report for a date range — the same numbers as Reports → Financial Summary. Answers 'how much did we make last week', 'what were sales this month', 'how much tax do I owe', 'what lands in my bank'. Returns gross sales, discounts, refunds, fees, tax, tips, net sales, and the settlement split (card / cash / custom) down to what the merchant actually receives. Start here for any "how did the business do" question, and only reach for get_sales_breakdown when the merchant wants the individual orders behind these totals.
What THIS company actually has installed — built-in and organisation-built (custom) extensions alike. This is the answer to 'which extensions do I have', 'is WooCommerce turned on for me', 'what am I paying for'. Not to be confused with get_extension_catalog, which lists what exists on the platform whether or not this merchant has it. Each row carries `extensionId` (pass this to install_extension / uninstall_extension) and `companyExtensionId` (the install record itself — you never need to pass that one). `description` is filled in only for custom extensions; built-in ones store no prose, so do not guess what they do. LIMITATION: the install date is not stored — you cannot say when an extension was added or who added it. To answer what an installed extension CHANGED in the cabinet — a new menu entry, a block on a detail page — use get_extension_surfaces.
Catalogue items this supplier does NOT carry yet but could — the picker behind "add items to supplier". Feed what you choose to link_supplier_items. Only stock-managed items appear: something the merchant does not track stock for cannot be purchase-ordered at all, so if an expected item is missing here and missing from get_supplier_items too, the reason is almost always that stock tracking is off for it — say that instead of guessing. Omit supplierId to search the whole linkable catalogue, e.g. while deciding which supplier to create. Returns everything matching, unpaged, so pass a search.
List the image files stored on the merchant's account. Answers 'what images do I have', 'do I already have a photo of X', 'what did I upload recently', and it is where you get a file id before deleting one, or a URL to reuse on a product or category. Newest first; search is a case-insensitive match on the FILE NAME only. LIMITATIONS, state them rather than working around them: there is no other sorting, and no title, alt text, description, folder, file size or image dimensions here — the Media screen in the cabinet shows those, but they are stored by a different service that this tool cannot read, so it may list files this tool does not and vice versa. There is also NO WAY TO RENAME a file from here: if the merchant asks to rename one, or to change its alt text, title or folder, say that has to be done on the Media screen in the cabinet. Do not delete and re-upload to fake a rename.
One modifier in full: its choices with prices and defaults, and every category it is linked to with that category’s own rules. Read this before editing — update_modifier REPLACES the whole choice list, so you need the current one to send back. Each choice carries price (formatted, for reading out) and priceAmount (plain, what the write tools accept back). Pass priceAmount, never price.
Every modifier the merchant has — the questions the till can ask about an item, with their choices and prices. Start here for anything about options, add-ons, extras, toppings, sizes, milk, cooking temperature or "how do I let them choose X". Each row says how it is answered: "Pick one" (radio), "Pick many" (checkboxes), "Pick many · qty" or "stepper per choice" (the last two count UNITS, so one choice taken three times counts as 3). usedIn is how many categories it is linked to — a modifier with usedIn 0 is invisible at the till no matter how well it is set up.
Everything inside ONE order: line items with quantity, unit price and per-line tax, custom sales, gift-card and other non-revenue lines, the totals block, every payment taken (method, processor, card type and last 4, tip, change), every refund already made against it, plus the customer, outlet, station, employee and order notes. Answers 'what was in order 1042', 'how did they pay', 'was this one refunded', 'why is this total different'. Takes the order ID from get_orders — a receipt number will NOT work, search for it with get_orders first. READ-ONLY, and there is no sibling tool that writes: an order's status cannot be changed, an order cannot be cancelled or completed, and a refund cannot be created from this API — refunds are taken on the POS terminal against the original payment. Say that plainly instead of hunting for another tool.
How many orders the company has, in total or at given outlets — 'how many orders do we have', 'how busy is the King Street shop'. Cheap: it counts, it loads no order data. It counts EVERY order ever recorded and takes no date, status or source filter. For anything time-boxed or filtered, call get_orders and read its `matching` count, or use get_financial_summary for a period.
Find orders — the same rows as Manage → Orders. Answers 'show me order 1042', 'what did we sell on Saturday', 'are there parked orders', 'orders rung up by Maria', 'orders over $500 at the King Street shop'. Filter by receipt number, status, source, employee, customer, product, date window, order total, outlet or station. Results are ALWAYS newest first — there is no other sorting, so a "biggest order" question needs the amount filter, not paging. Search matches the receipt number and the order id ONLY, never customer names or product names: for those, pass customerIds from get_customers or productIds from get_products. One row per order with its total; for what is INSIDE an order — line items, payments, refunds, notes — call get_order with the id from here. For how much the business took over a period use get_financial_summary or get_sales_breakdown instead of adding these rows up.
Every point of sale (store, location, branch) the merchant has — the same list as Settings → Outlets. Answers 'how many stores do I have', 'what is the address of the King Street shop', 'what is that location’s phone number'. ALSO THE WAY TO TURN A STORE NAME INTO AN ID: the reports, inventory and station tools filter by outlet ID and never by name, so when the merchant says 'sales for King Street' or 'stock at the warehouse', call this FIRST and pass the id you find here. Returns every outlet in one call — the list is short, there is no paging and no server-side search, so match the name yourself. Deleted outlets are not returned. Outlets carry NO opening hours, timezone or currency: store hours are not stored anywhere on this platform and currency is a company-wide setting, so say that plainly instead of guessing. Per-outlet tax percentages are not here either — those belong to the tax tools.
How customers paid over a date range, netted of refunds — 'how much came in on card vs cash', 'what did processing fees cost me', 'how much hits my bank account'. Card and each custom processor also report their processing fees and the resulting deposit; cash has no fees. The same aggregation the Financial Summary settlement section uses, so the two always agree.
The catalogue of permissions a role can be given — every switch on the Roles screen, with the id create_role and update_role need. Call this to turn a request like 'let her see the reports' into the right permission id; match on the label and the permission path, and ask the merchant if two of them could both be meant. Permissions are granted exactly as named — there is no parent-grants-the-children cascade here — so pass every line the merchant actually needs. The list is the same for every merchant; it is not their current setup. For what a role currently grants, use get_roles.
Which resources serve this bookable product. Use it to check a product is actually ready to take bookings before quoting availability — an empty resource list means every hold will be refused, however correct the rule set looks.
List the variation axes the merchant already has — e.g. 'Size' with Small/Medium/Large. Call this BEFORE creating a product with variants and offer the existing axes instead of inventing new ones. Only call create_product_option when the merchant needs an axis that is not in this list.
List products in the merchant's catalogue. Answers 'what products do I have', 'find the Coca-Cola product', 'how much is X'. Pass categoryIds to answer 'what is in the Drinks category' — take the ids from get_categories, which does not return products itself. LIMITATION — there is no sorting: results come back in catalogue order and cannot be ordered by price, name or date. So 'the most expensive products' CANNOT be answered from this tool, and you must NOT page through the whole catalogue trying. Say plainly that sorting is not supported yet, then offer what does work: search by a name or SKU, filter by category, or ask the merchant to narrow it down.
One purchase order in full: supplier, outlet, status, and every line — what was ORDERED and what has actually ARRIVED, per item, across each delivery. Answers 'what is on this order', 'what is still outstanding', 'did the price change from what we agreed'. Money appears twice on every writable field: the formatted one (CA$12.50) is for reading out to the merchant, the *Amount twin (12.50) is what update_purchase_order accepts back. The `ordered` block is the agreed order; each entry in `receipts` is one delivery booked against it, with its invoice number. Compare an item’s ordered quantity against the sum of its received quantities to see what is still owed — receiving more than ordered is allowed, so an overage is real, not an error. ALWAYS CALL THIS AFTER receive_purchase_order instead of retrying the receive: it is the way to confirm what was booked.
Stock the merchant has ordered from suppliers — the same list as Purchasing → Purchase Orders, and THE tool for any purchasing question over a period: 'what did I spend on stock last month', 'what is still on order', 'what have I ordered from this supplier', 'what is arriving this week'. Filter by status, supplier, outlet and a created-date range. READ totalCost CAREFULLY: it is what the order was placed FOR, not what was paid, and it sits on suggested and draft rows too — summing the whole list answers 'what have I proposed', not 'what did I spend'. For spend, filter status to ['sent','partially_received','fully_received']; for what a delivery actually cost, read the receipts block of get_purchase_order. Statuses, in order: suggested (auto-proposed by a reorder rule, not ordered), draft (being written), sent (with the supplier), partially_received (some arrived), fully_received (all in). "Open" means anything not fully_received. Cancelled orders are gone from this list entirely. The date range filters on when the order was CREATED, not when it was sent or received. Costs here are what the merchant pays suppliers — for sales and revenue use the report tools instead.
How far a delivery has got in being applied to stock. A large delivery is applied item by item in the background, so its order keeps its old status until the work finishes — this is the only place that shows the real progress. Call it with the receiptId that receive_purchase_order returned, or the one get_purchase_order reports as still being received. Read `failures` seriously: those items did NOT get their stock and say why (the item was deleted, the outlet no longer exists, the supplier link was removed). Everything else on the delivery still landed, so the fix is per item, not a re-receive of the whole thing.
Refunds recorded against orders, newest first: what was refunded, why, by whom, on which order and for which customer. Answers 'what did we refund lately', 'show the refunds on order 1042', 'who processed that refund'. Filter by order id, or search by the REFUND's own receipt number. LIMITATIONS: no date filter and no total count — for refunds in a date range use get_sales_breakdown (one row per refund) or get_financial_summary (refund totals). Refunds CANNOT be created here: they are taken on the POS terminal against the original payment. This tool only reads.
What the platform thinks should be reordered: rescans stock against the merchant's auto-reorder rules and returns the suggested orders it left behind, grouped by supplier and outlet. Answers 'what am I running low on', 'what should I order this week'. A suggestion is NOT an order — nothing has been sent and no supplier knows about it. Turn one into a real order with update_purchase_order (which accepts it as a draft) and then send_purchase_order. Only items with an auto-reorder rule can appear here, so an empty result usually means no rules are set rather than nothing being low — say that, and offer set_reorder_rule. The rescan is skipped and the stored suggestions returned when one ran moments ago; `rescanned: false` says so.
The roles this merchant has defined and exactly what each one is allowed to do — Settings → Roles. Answers 'what can a cashier do', 'which roles exist', 'who is on the Manager role'. A role is the ONLY place permissions live: people do not carry their own. Read this before changing anything, and take permission ids from the granted list when revoking. Owners and organisation-level accounts hold no role and are never restricted by one — a role change cannot take anything away from them.
Order-by-order breakdown for a date range — the same rows as Reports → Sales Breakdown. One row per order AND per refund. Answers 'show me the orders from Saturday', 'which order had that big discount', 'how many refunds last month', 'sales per day'. The `totals` and `dailyTrend` in the reply cover the WHOLE date range, not just the returned page — quote them directly instead of adding up rows. For headline figures alone use get_financial_summary; this tool is for when the merchant wants to see the actual orders.
The full End of Session report for ONE shift: sales, taxes, settlement, refunds, staff sales, tips and the cash drawer. Answers 'does the drawer balance', 'was the till short last night', 'what did that shift take'. Takes the session id from get_sessions, never a station or a person. The cash drawer section is what tells you over / short — report it plainly, and do not compute it yourself from the other sections.
Register sessions (shifts) opened and closed in a date range — the list behind Reports → End of Session. Answers 'what shifts ran yesterday', 'who closed the register last night', 'is a session still open'. Returns who opened and closed each one, the opening float and the declared closing amounts. A session with no closeTime is still open. For the full money report of one shift, pass its id to get_session_report.
Everything about ONE station, including what its device last reported about itself — app version, OS, network, printer, battery and whatever else that device sends. THIS IS THE TOOL FOR 'the till will not connect', 'it will not print', 'the card reader is not working', 'this register is acting up'. Takes the station id from get_stations, never a name. How to read it when troubleshooting: `kind` tells you whether it is a physical device or a browser till (a browser till has no device to blame — check the share link and the flow instead); an empty `deviceId` on a native station means no device ever enrolled under it; `enrolledBy` and `createdAt` say who set it up and when; an empty `deviceEnvironment` means the device has never reported anything, which is itself the finding. The values carry NO timestamp — they are the last ones received, and there is no way to tell how old they are. `recordUpdatedAt` is the last time the station RECORD changed (mostly a shift opening or closing, or a rename) — it is NOT a heartbeat: the platform stores no online/offline ping for a till, so never report a station as "online" or "last seen". Card readers shown here are read-only: pairing and unpairing a reader happens on the Terminals screen of the cabinet, not through any tool.
Every POS station (till, register, checkout lane, cash desk) the merchant has — the same list as Run → Stations. Answers 'how many tills do I have', 'which register is busy right now', 'which store is this till at', 'which of them are browser tills'. Each station belongs to exactly ONE outlet and the outlet name is resolved here, so you do not need get_outlets to answer where a till stands — call get_outlets only to turn a store NAME the merchant said into the outletId filter of this tool. WHAT status MEANS, EXACTLY: the server does not compute it. The POS app on the till writes it — IN_USE when a cashier opens a register shift on that station, AVAILABLE when the shift is closed. It is best-effort: the update is lost while the device is offline and only flushed when it reconnects, and older app versions never sent it at all, so a station can sit at AVAILABLE with a shift open on it or at IN_USE hours after one was closed. Read it as "what this till last told us", never as proof. NEVER answer a shift or money question from it: for shifts that are actually open, who opened them and what they took, use get_sessions (a session with no closeTime is open) and get_session_report. If those disagree with this flag, they are right and the flag is stale. The whole list comes back in one call — it is short and plan-capped, there is no paging; search matches the station NAME only. Deleted stations are not returned.
How many of ONE product are on hand, broken down by variant and by outlet. Answers 'how many of these do I have', 'how many are left at the King Street shop', 'where is this product in stock'. Takes the product id from get_products — get_products itself returns prices, never quantities. Pass outletId (from get_outlets) to narrow it to a single shop. CRITICAL — "tracked: false" means the merchant switched stock counting OFF for that variant at that outlet, so there is NO count at all. It is NOT "0 in stock". Never say "you have 0" or "it is out of stock" about an untracked line; say stock is not being tracked there. Only lines with tracked: true carry a real quantity. Outlets where the product is hidden do not appear at all. For 'what is running out' across the whole catalogue use find_low_stock instead — do not page through products with this tool.
Every recorded stock movement for ONE product, newest first — the audit trail behind a count. Answers 'why is the number wrong', 'who changed this', 'when did we last receive these'. Each entry says what happened (SALE, STOCK_RECEIVED, DAMAGE, THEFT, LOSS, RESTOCK_RETURN, INVENTORY_RECOUNT, TRANSFER, BULK_RECOUNT), the signed quantity, the resulting on-hand, the outlet and the employee. Use this when the merchant disputes a number: state what the log shows rather than guessing at a cause. Only changes that were actually applied appear — an adjustment on an untracked line writes no history at all, which is itself the explanation when the log looks empty.
ONE transfer in full: both outlets, the employee, the invoice, the notes and the line items with quantities. Takes the transactionId AND the type exactly as get_stock_transfers returned them — the type decides which leg is read, and a wrong one fails. For send-transfer and receive-transfer this also returns the sibling leg, so you can name where the stock came from and where it is going, plus stockTransferId, which is what receive_stock_transfer needs. Line quantities are the amounts MOVED, recorded when the transfer was created — they are not current stock. Use get_stock for that.
The Stock Transfers list. Answers 'what transfers are open', 'what is still in transit', 'did the warehouse send those yet'. Each row is ONE LEG: a move between outlets produces a send-transfer (already completed — the stock has left the source) and a receive-transfer (in-transit until the destination confirms). receive-stock is stock booked in from a supplier; bulk-edit is a recount. To find work that is still open, filter status "in-transit". Search matches the transfer number and the invoice only — not product names. Rows carry no line items: open one with get_stock_transfer to see what was actually moved.
One supplier in full: contact details, address, notes, how many catalogue items it is linked to and how many of its purchase orders are still open. Does NOT list the items themselves or the orders — those are get_supplier_items and get_purchase_orders (filter it by this supplier id).
The catalogue items one supplier carries, with the cost the merchant pays and the supplier’s own part number. Answers 'what do I buy from this supplier', 'what does this supplier charge me for X'. CALL THIS BEFORE create_purchase_order: an order may only contain items the supplier is linked to, and the variantId + unitCost you need for each line come from here. PASS outletId when you are about to build an order: that narrows the list to items whose stock is actually tracked at that outlet — the only ones a receive can add stock to — and adds onHand, the quantity there right now, so you can see what genuinely needs reordering. Search and paging work the same either way. An item the merchant expects but does not see here is simply not linked yet — get_linkable_items then link_supplier_items.
The businesses this merchant BUYS stock from — the same list as Purchasing → Suppliers. Answers 'who do I order from', 'what is my supplier’s email', 'which suppliers have open orders'. ALSO THE WAY TO TURN A SUPPLIER NAME INTO AN ID: every purchase-order and item-linking tool takes a supplier id and never a name. Each row carries openPoCount — purchase orders not yet fully received — and itemCount, how many catalogue items that supplier is linked to. This is the buying side. For what the merchant SELLS and at what price, use get_products.
The other direction: given a product from get_products, which suppliers carry its items and at what cost. Answers 'who can I reorder this from', 'who is cheapest for this', 'am I buying this from more than one place'. Nothing comes back when the product is linked to no supplier — that is a real answer, not an error: it cannot be purchase-ordered until it is linked.
The whole Settings → Taxes screen: every tax group, the rates inside it in charging order, and each rate’s percentage at each outlet. Answers 'what sales tax do I charge', 'what tax applies in the King Street store', 'which tax group is the standard one', 'do I charge GST and PST separately'. ALWAYS call this before any other tax tool — every other tool takes ids from here (tax group ids, tax rate ids, outlet ids) and none of them accept names. It also reports which rates are shared across groups and which belong to no group, both of which change what an edit will do. Read-only.
Everyone who works for this merchant — Manage → Team → Users. Answers 'who works here', 'what role does Maria have', 'who can see reports', 'what is Tom's phone number'. This is about who works here and what they are allowed to do — for how much anyone SOLD, use get_employee_sales instead. Returns the whole team at once: there is no search and no paging, so filter the rows yourself instead of asking the merchant to narrow down. Removed people are not listed at all. Every other tool in this domain takes its userId from here.
Individual payments and refunds — Reports → Transactions. This is the PAYMENT level, not the order level: one order can hold several transactions. Answers 'find the payment for receipt 1042', 'show every Amex refund last week', 'which transactions failed'. Filter by payment method, processor, card provider or status, or search by order number. For sales figures use get_financial_summary — this tool is for locating a specific payment.
Claim a window on one resource. The hold is what makes the window unavailable to everybody else, and it expires by itself if nobody pays — so holding is safe, and a hold nobody confirms costs nothing. `startAt` must be exactly a slot start from get_booking_availability, and `endAt` exactly where the last slot ends; anything else is refused rather than rounded. A refusal with 409 means somebody took it first: re-read availability and offer what is left, do not retry the same window.
Load a category tree in one call — a whole department structure, a migration. For one or two categories use create_category. Parents and children may sit in the SAME batch: `parentRef` takes a parent NAME (matched inside this batch first, then against existing categories) or an existing id, which is what makes a flat spreadsheet importable. Loops and unresolvable parents fail those rows and their descendants, not the batch. 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`. Two rows named the same thing in one batch, or a name that already exists, will produce two categories with that name. On `updates` this is the only import with true merge-patch semantics: omit a field to leave it, pass null to CLEAR it, and pass `parentId: null` to move a category back to the top level (which create_category and update_category cannot do). Products are untouched — importing categories neither assigns nor removes products; that is the products side. 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.
Load a customer list in one call — a mailing list, a migration from another system. For one person use create_customer. This is the ONE import that recognises records it already has: pass `rows` and the server looks each one up BY EMAIL, updating that customer instead of duplicating them. A row with no email is always created new and can never be matched again, so push for emails before importing. Fields you pass overwrite the stored ones; fields you omit are left alone — but an address you pass replaces the stored address whole, and `tags` replaces the whole tag list. ALL-OR-NOTHING: unlike the other imports this one runs in a single transaction, so one bad row rolls the entire batch back and nothing is written. There is no per-row failure list. 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.
Load product attributes and their values in one call — "Size: S,M,L", "Colour: Red,Blue,Green" — the axes variants are built from. For one axis use create_option. Attribute names are unique per company: a `creates` row whose name already exists is REJECTED (that row only), so read get_options first and send existing ones through `updates`. On `updates`, values are APPEND-ONLY: the list you pass is merged into what is there and existing values are never renamed or removed, because variants reference them by name and would be orphaned. Renaming the attribute itself does cascade to its variants. To remove a value, use the cabinet. This creates no products and no variants — it only defines the axes. 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.
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.
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.
Write stock counts for ONE outlet from the CSV that export_stock_csv returns — the cabinet's stock upload. Edit only the New Qty column; each row SETS that variant's quantity at the outlet (it is not a +/- adjustment). Keep the header and the Variation ID column as exported. Rows whose Variation ID is not in this company are skipped. For one or two variants use adjust_stock instead. 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.
Install an extension for the whole company. Takes the `extensionId` from get_extension_catalog, never a name. CONFIRM WITH THE MERCHANT BEFORE CALLING, naming the extension: this is not a personal setting — it changes the cabinet for EVERY user of the company, and several extensions do real work on install (WooCommerce connects the store and starts syncing, TIMEmSYSTEM writes default settings, Custom Payment schedules Stripe billing). MONEY: an extension with a non-zero `price` starts costing the merchant from the moment it is installed — quote the stored price string and let them decide. Installing is not enough to finish a setup: most extensions then need their own settings page in the cabinet (a WooCommerce store URL, a payment gateway key), which this agent cannot fill in — say that plainly after installing. Refused when the plan excludes the extension, when the caller lacks the Extensions permission, or when it is already installed (installing twice is not a no-op — it would run the side effects again).
Start asking a modifier on every product in a category — THIS is what puts it on the till. The rules are per category, so the same modifier can be required here and optional elsewhere. required means the cashier cannot finish the line until they answer. min/max count distinct choices, or UNITS when the modifier uses quantities. Refused when the category already inherits this modifier from a parent category (link it to the parent or the child, not both), when it is already linked, and when the rules could not be satisfied — for example asking for at least 3 when only 2 choices are sold at every outlet. Linking a modifier to a PARENT category detaches it from any subcategories that already had it, since they now inherit it.
Change what a supplier carries and what it charges, in one call: `add` new items, `update` the cost or part number of items already linked, `remove` items it no longer sells. variantId comes from get_linkable_items for `add` and from get_supplier_items for `update` / `remove`. unitCost is what the merchant PAYS per unit, as a human amount like "12.50" in the company currency — never the selling price, and never cents. It is only the DEFAULT that prefills new order lines: changing it does not re-price purchase orders already placed. Adding an item that is already linked is refused, so read the current list first rather than re-adding blindly. REMOVING is the destructive half — confirm it with the merchant, and tell them it also EDITS ORDERS THAT ARE ALREADY WRITTEN: the item’s line is dropped from every suggested and draft order from this supplier, which changes their totals. Orders already sent keep their lines, the item stays in the catalogue, but it can no longer be added to a new order from this supplier, and any auto-reorder rule pointing at this supplier for it stops producing suggestions.
Book a delivery in against an order that was sent: ADDS THE RECEIVED QUANTITIES TO REAL STOCK at the order’s outlet and updates the item cost book. This is not a note — it changes inventory. CONFIRM THE QUANTITIES WITH THE MERCHANT FIRST, item by item, and record what genuinely ARRIVED, not what was ordered — they differ, which is the whole point of receiving. Only `sent` and `partially_received` orders can be received; each item must be one that was ordered; receiving more than ordered is allowed. A short delivery leaves the order `partially_received` — receive again when the rest turns up. A CALL THAT RETURNS IS NOT PROOF EVERY ITEM LANDED — check `partialFailure`, and `stockApplied.complete` on a large delivery. IF IT FAILS, DO NOT RETRY BLINDLY: "still being received" means a previous delivery is being applied right now (get_receive_progress), and a wrong-status error means it was already fully received. Call get_purchase_order to see what actually landed before deciding anything. unitCost is what this delivery actually cost per unit — pass the invoice price if it differs from the order. When it does differ, the supplier’s stored cost is NOT updated unless you list that item in updateSupplierCostVariantIds, so ask the merchant whether the new price is the going rate or a one-off.
Confirm that a transfer arrived: the destination outlet gains the units and the transfer closes. CONFIRM WITH THE MERCHANT FIRST — this adds stock and cannot be undone from here. Only do it when they say the goods are physically there; confirming a transfer that never arrived hides a loss instead of recording one. Takes stockTransferId (from get_stock_transfer), NOT the transactionId. Only applies to a receive-transfer leg still in-transit; a transfer already completed has nothing left to receive.
Stock that arrived with no purchase order behind it — the merchant bought it on the spot, or it was ordered outside the platform. Creates the order already fully received and ADDS THE QUANTITIES TO REAL STOCK at the outlet, in one step. Use this ONLY when no order exists. If the goods match an order that was sent, use receive_purchase_order instead — otherwise the same delivery is counted twice, once here and once when someone receives the real order. Check get_purchase_orders for an open order from this supplier before calling. The items must already be linked to the supplier (get_supplier_items) and stock-managed at the outlet. There is no undo: correcting a mistake means a stock adjustment afterwards.
Stop watching one item: it will no longer be suggested for reordering however low it runs. Its thresholds are forgotten, so turning it back on means setting them again. Suggestions already produced for this item are not withdrawn — cancel those orders separately if the merchant wants them gone.
Stop ONE tax group charging a rate. The rate itself, its percentages and its use by other groups are untouched — this only drops the link. This is what the merchant means by "remove the city tax from Food". Use delete_tax_rate ONLY when they want the rate gone from the whole company. CONFIRM WITH THE MERCHANT: every product in this group immediately stops being charged this tax. Sales already rung up are NOT recalculated — this only affects sales from now on.
Remove someone from the merchant's team — the tool for 'she left', 'take the leaver off'. Takes the userId from get_team ONLY, never a name. CONFIRM WITH THE MERCHANT BEFORE CALLING, naming the person: there is no undo from here. If two people share a name, list them and ask which. They stop being able to sign in immediately; their past orders and sales figures are kept, so reports about them still work. You cannot remove the account this agent key belongs to — the server refuses, so that an administrator cannot lock themselves out.
Rename one station. Takes the station id from get_stations. Renaming is safe and takes effect everywhere — past orders, sessions and reports store the id and look the name up. The name is the ONLY thing the cabinet lets anyone change on an existing station, and the only thing this tool changes. A station cannot be moved to another outlet, and its device, card reader and POS layout are not editable from here — moving a till to another store means creating a new station there and deleting this one, which loses its id.
Set the display order of several categories in one call — "put Drinks first", "sort my categories alphabetically". Lowest sortOrder shows first, and ordering only applies among categories that share the same parent. Send every category whose position should change, with the ids from get_categories; ones you leave out keep their current order, which can leave two categories tied. It changes NOTHING but the order — for a rename or a move use update_category.
Set the order the till asks a category’s modifiers in. Pass EVERY link id for that category exactly once, in the order wanted — a partial list is refused. Read them from get_category_modifiers with that categoryId.
Set the order the choices appear in at the till. Pass EVERY current choice id exactly once, in the order wanted — a partial list is refused. Read them from get_modifier first.
Place the order: moves a `draft` or `suggested` order to `sent` and, when asked, EMAILS IT TO THE SUPPLIER. ASK THE MERCHANT WHETHER TO EMAIL, EVERY TIME, and only then pass sendEmail: true — that message leaves the platform and cannot be recalled. Default is false, which records the order as placed without mailing anything: the right choice when they ordered by phone, in person, or through the supplier’s own portal. Emailing needs a contactEmail on the supplier; without one, send with sendEmail: false and tell them why. The email carries the order in its body — this tool cannot attach the PO PDF the cabinet produces. After sending, the order can no longer be edited; only receiving or cancelling remain.
Point a booking product at its rule set AND the resources that serve it — both in one call, because a product with only one of them takes no bookings at all. `resourceIds` REPLACES the current list rather than adding to it, so pass every resource that should serve the product. The product must already exist and be of the booking type (create_product with productType "booking").
Tell the platform to watch one item and suggest reordering it when stock runs low: below lowStockPoint, suggest ordering reorderQuantity from this supplier. Calling it again on the same item replaces the rule rather than adding a second one. The supplier MUST already carry this item (get_supplier_items) — otherwise the rule would draft orders to a supplier that cannot fulfil them, and it is refused. The thresholds apply company-wide unless you pass outletOverrides, which set a different point or quantity per outlet — a busy store may need a higher one than a quiet one. This only produces SUGGESTIONS. Nothing is ever ordered or emailed automatically.
Look up the statutory headline rate for a country (and US state / Canadian province). Answers 'what should I charge in Ontario', 'what is the VAT in Germany'. This is a reference lookup — it changes NOTHING and creates nothing; use create_tax_rate to actually charge it. Report the `confidence` and any `note` back to the merchant verbatim: local / city taxes are not included and the merchant, not you, decides the real rate.
Push one order to the company's connected online store (WooCommerce): creates it there the first time, updates it afterwards, and syncs its notes. Use ONLY when the merchant says an order is missing from or stale in their online store — 'this sale never showed up in WooCommerce'. CONFIRM WITH THE MERCHANT BEFORE CALLING, naming the order: it writes into their live store and nothing here can undo it. It changes NOTHING in Final POS — it is not a way to change status, cancel an order or refund anything. Companies with no supported platform connected get a no-op.
Push a refund that ALREADY exists in Final POS to the connected WooCommerce store, so the online order shows as refunded there. Takes the REFUND id from get_refunds — the order id will not work. CONFIRM WITH THE MERCHANT BEFORE CALLING: it creates a refund on their live store, there is no undo from here, and calling it twice creates a second refund there. It does NOT move money back to the customer and it does NOT create a refund in Final POS — that happens on the POS terminal.
Uninstall an extension from the company. Takes the `extensionId` from get_installed_extensions, never a name. CONFIRM WITH THE MERCHANT BEFORE CALLING, naming the extension: the install record is deleted for good — there is NO undo from here, and re-installing does not bring the extension’s own settings back. It also removes what the extension added to the cabinet (its menu entries and detail-page blocks disappear for every user) and runs the extension’s own teardown: WooCommerce stops syncing the store, Vendara and Zapier are disabled, TIMEmSYSTEM’s settings are deleted, Custom Payment queues a final invoice for the transactions already processed. Orders, products and customers that came in through the extension are NOT deleted. If the merchant only wants to stop using it for a while, tell them there is no pause — uninstall is the only option.
Stop asking a modifier in one category. The modifier itself survives and keeps working everywhere else — use delete_modifier to remove it entirely. Takes the LINK id from get_category_modifiers, not the modifier id. If the category inherits the same modifier from a parent, the till keeps asking it; unlink it from the parent instead.
Rename a category, change its description or image, move it under a different parent, or set its sortOrder. Takes the category id from get_categories, never a name. Only the fields you pass are changed. parentId can only MOVE the category under another one; making an existing subcategory top-level again is not supported here, and neither is it in the cabinet. A category synced from an integration (WooCommerce and the like) is read-only and will be refused — it has to be changed in that platform. This never touches which products are in the category; that lives on the product (update_product, categoryIds).
Change how a modifier is asked in ONE category — required, min, max, order — leaving every other category alone. Omit a field to leave it as it is; pass null to min or max to CLEAR that limit. The two are different, so be deliberate. The platform tidies the combination and reports what it actually stored: turning required on sets a minimum of 1, any minimum of 1 or more turns required on, and a "Pick one" modifier keeps no min or max at all. Read the result rather than assuming your input was kept. required: false together with a minimum of 1 or more is a contradiction and is refused.
Change contact details on an existing customer. Takes the customer ID from get_customers, never a name. Only the fields you pass are changed, but an address you pass REPLACES the stored one whole — read it back with get_customer first and resend the parts that should stay. Notes are not editable here: use add_customer_note.
Rename a modifier and/or REPLACE its whole choice list. Passing choices is a full replacement: whatever you send becomes the list and anything you leave out is DELETED. Read get_modifier first and send the complete set back, keeping each choice’s id so prices and till history stay attached. To change one choice, use update_modifier_choice instead — it is safer and cannot drop the others. selectionType and allowQuantity cannot be changed; a modifier that needs a different kind of answer has to be created fresh. Renaming alone never breaks a rule; replacing choices can, and is refused with an explanation if it would.
Change one choice — its name, price, whether it is pre-selected, or where it is sold. Everything you leave out stays as it is. unavailableOutletIds is the exception list and REPLACES the stored one: pass [] to make the choice available everywhere again. Marking a choice unsold somewhere can be refused if a category requires more choices than would remain available at every outlet.
Change the details of one outlet. Takes the outlet id from get_outlets, never a name. Only the fields you pass are changed; the rest are left alone. Renaming is safe and takes effect everywhere, including past orders and reports — they store the outlet id and look the name up. Country cannot be changed here: it belongs to the company. An alias that is already set cannot be changed either and the attempt is refused. Stripe account linking is not editable from here.
Change fields on an existing product. Takes the product ID — get it from get_products, never guess. Only the fields you pass are changed. Prices are HUMAN strings like "24.99". Variant fields (price, sku, barcode): for a product with several variants use `variants` with the ids from get_products; plain `price`/`sku`/`barcode` work only when there is exactly one variant.
Rewrite an order that has not been sent yet. ONLY works while it is `suggested` or `draft` — a sent or received order is refused, because the supplier already has it. This REPLACES the whole order: the lines and charges you pass become the order, and anything you leave out is dropped. Read it with get_purchase_order first and send the full set back. This is also how a suggestion is ACCEPTED: editing a `suggested` order turns it into a `draft` and gives it its PO number. To accept one unchanged, pass its existing lines back verbatim.
Change what a role allows, or rename it. This is the tool for "let cashiers give discounts" or "stop them seeing the reports" — it changes things for EVERY person on that role at once, so name them from get_roles when you confirm. PERMISSIONS ARE POWER. Confirm with the merchant first, naming the person and the role out loud ("give Maria the Manager role — yes?"), and never act on a role change you inferred rather than were asked for. The change is live on the next request: rights are re-read from the role every time, so no one logs out and no agent key stops working — including yours, if the change reaches your own account. Grant and revoke by permission id: grant ids from get_permissions, revoke ids from the role’s granted list in get_roles. Permissions you do not mention are left exactly as they are. You cannot edit the role you are signed in under — the cabinet locks it too, because it decides your own powers. Ask someone on another role. To move one person instead of changing the role, use assign_role.
Change one supplier’s details. Only the fields you pass change; the rest are left alone, and a blank string is ignored rather than blanking the stored value. Renaming is safe — past purchase orders store the id and look the name up. A name already used by another supplier of this company is refused. This does NOT change item costs: those live on the supplier–item link, so use link_supplier_items to re-price.
Rename a tax group, make it the standard one, or change the ORDER its rates are charged in. Takes the tax group id from get_taxes, never a name. Order matters for money: a compounding rate is charged on the running total including everything above it, so reordering changes what customers pay. rateIdsInOrder must list exactly the rate ids already in the group, once each — it reorders, it never adds or removes. Use add_tax_rate_to_group / remove_tax_rate_from_group for that. CONFIRM WITH THE MERCHANT before reordering or changing the standard group. Sales already rung up are NOT recalculated — this only affects sales from now on.
Change a tax rate’s name or its percentage. Takes the tax rate id from get_taxes, never a name. THE RATE IS SHARED: this changes EVERY tax group that lists it, not just the one the merchant was talking about. Call get_taxes first, tell them exactly which groups are affected, and get an explicit yes. If they only meant one group, the answer is a separate rate via create_tax_rate, not this tool. percentage sets the same value at every outlet. perOutlet REPLACES the stored per-outlet list whole — an outlet you leave out STOPS charging this rate, so read the current values back with get_taxes and resend every outlet that should keep charging. Sales already rung up are NOT recalculated — this only affects sales from now on. Reports and receipts for past sales keep the old rate.
Change a team member's own details: name, phone, till PIN, and which outlets they work at. Takes the userId from get_team, never a name. Only the fields you pass change, but outletIds REPLACES their whole outlet list — read it back from get_team first and resend the ones that should stay, or you will quietly cut someone off from a location. Email cannot be changed here at all (the sign-in identity is not rotated, so the old address would keep working) — the merchant has to remove and re-invite the person. This tool does NOT change permissions: for that use assign_role.
Store image files from public URLs in the media library so the merchant can use them later. Returns the stored URL of each file. JPEG/PNG/WebP/GIF, up to 20MB each. This ONLY stores the files — it attaches them to nothing. If the merchant wants a photo ON A PRODUCT, use add_product_images instead: it uploads AND attaches in one step, and doing it here first would upload the same picture twice. Use this one when they just want the file kept — a logo, a banner, a picture for later. A file uploaded here may not appear on the cabinet's Media screen, which is fed by a separate service; the file is stored and its URL works regardless.
Final is the commerce platform for custom point of sale. Its MCP server lets developers and AI agents build custom POS apps – counter checkouts, self-checkout kiosks, restaurant ordering screens, kitchen displays and in-person payment-terminal apps – and deploy them to real hardware with integrated card payments.
One remote endpoint, https://ai.finalpos.com/mcp, gives your agent both halves of Final:
You sign in with your Final account (OAuth 2.1), pick the company and choose which tool packs the agent may use. Nothing to install or run locally.
Describe the checkout you want and the agent builds it end to end:
flow_get_scaffold, flow_list_blueprints, flow_get_blueprint).flow_lookup_pos_api, flow_lookup_command_frame, flow_lookup_engine_component).flow_create_flow, flow_write_flow_files).flow_validate_flow).flow_start_preview).flow_deploy_flow).Claude (claude.ai, Desktop): Settings → Connectors → Add custom connector → https://ai.finalpos.com/mcp
Claude Code:
claude mcp add --transport http final https://ai.finalpos.com/mcp
Then run /mcp and choose Authenticate.
Cursor (~/.cursor/mcp.json):
{ "mcpServers": { "final": { "url": "https://ai.finalpos.com/mcp" } } }
ChatGPT: Settings → Apps & Connectors → Advanced → Developer mode → Create, with the URL above.
Gemini CLI: gemini extensions install https://github.com/Final-Commerce/final-pos-mcp
Codex, scripts and clients without OAuth: create a fai_ connection key at https://ai.finalpos.com/connections and send it as Authorization: Bearer fai_....
175 tools in 10 packs. A connection lists a few packs at a time to keep the model's context small; find_tools and call_tool reach the rest.
| Pack | Product | What it covers |
|---|---|---|
| build | Flow | Build and deploy custom POS apps: API grounding, blueprints, flow files, previews, validation, deploy |
| build_data | Flow | Custom tables (the app database), secrets vault, Flow extensions |
| catalog | Hub | Products, variants, categories, options, modifiers, photos |
| inventory | Hub | Stock, transfers, suppliers, purchase orders, reorder rules |
| orders | Hub | Orders and e-commerce order sync (read-only) |
| customers | Hub | Customer records, notes, history |
| reports | Hub | Financial summary, sales and payment breakdowns, sessions |
| team | Hub | Team members, roles, permissions |
| store | Hub | Outlets, stations, taxes, Hub extensions |
| bookings | Hub | Bookable services, availability, holds |
Full reference: https://github.com/Final-Commerce/final-pos-mcp/blob/main/TOOLS.md
readOnlyHint; deploys and deletes carry destructiveHint.Yes. With the Final MCP server, an agent like Claude, ChatGPT, Cursor or Gemini scaffolds a POS flow, adapts vetted screen blueprints, writes the app into the Final builder, validates it and returns a live preview link. You deploy it to your terminals from Final.
Counter checkouts, self-checkout kiosks, restaurant and quick-service ordering, kitchen displays, line busters, menu boards and in-person payment-terminal apps, with integrated card payments.
Desktops, tablets, mobile devices, kiosks and payment terminals. The same flow runs across devices.
No, if your client supports OAuth (Claude, ChatGPT, Claude Code, Cursor, Gemini CLI, VS Code): sign in with Final. Codex and scripts use a `fai_` connection key from https://ai.finalpos.com/connections.
Connecting is free. What the agent does is billed like the same work done in Final, under your Final plan.
No. Payments, refunds and voids happen on the till. Orders are read-only over MCP.
Start at https://finalpos.com/mcp.
Final POS – Custom POS Builder 的远程 MCP 服务器是一个托管的 Model Context Protocol 端点,地址是 https://ai.finalpos.com/mcp,AI 助手无需在本地安装或运行任何东西即可连接。
把端点 https://ai.finalpos.com/mcp 添加到任意支持 MCP 的客户端,比如 Claude Code、Cursor 或 VS Code。本页的接入代码块可以一步配置好每个客户端。
需要。Final POS – Custom POS Builder 使用 OAuth——第一次连接时,你的 MCP 客户端会打开浏览器窗口登录并授权,之后会复用这个凭证。
Final POS – Custom POS Builder 暴露的是 Streamable HTTP 端点,这是远程 MCP 服务器普遍使用、主流客户端都支持的传输方式。
Hosted 3GPP MCP server: cited search across Rel-15 through Rel-20 TS/TR specs, recent TDocs, company proposals and meeting decisions. OAuth 2.1; no local index required.
The 9apes MCP server lets an AI assistant read the GitHub Actions data 9apes already collects for your organization: runs, jobs, steps, and their durations. Ask it why a build got slower, which jobs take the longest, or
Email for long-term client relationships: ARVX reads each person first and remembers every pair.
Search and read public data from X/Twitter, Reddit, YouTube, Instagram, TikTok, Facebook, Threads, Bluesky, Trustpilot, Amazon, Google Maps, news, forums and the web. 90+ read-only tools plus ready-made research playbook
Pharmaceutical drug & clinical trial intelligence
评论