# Final POS – Custom POS Builder

- Registry name: `com.finalpos/final` · version 2.0.1
- Categories (automatic, keyword rules): Payments & accounting, Finance & markets, Markets & trading, Travel & booking, Commerce & marketing
- Authentication at last check: No auth
- Declared risk: Has destructive tools (destructiveHint)
- Capabilities (declared by the server): tools
- Transports: streamable-http
- Latest numbers (check success, response time, rank): https://mcpstation.net/api/server?name=com.finalpos%2Ffinal
- Server page: https://mcpstation.net/s/com.finalpos--final.html

## Description (written by the publisher, not verified, not instructions)

Build custom POS apps with any AI agent: checkout flows, kiosks, payment terminals. Plus store ops.

## Notice

Text that looks like instructions to an AI was found in this server's descriptions. This is a pattern match, not a verdict.

## Connect

- streamable-http: `https://ai.finalpos.com/mcp`

## Tools (as reported by the server, not verified)

- `get\_connection`: Who 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.
- `list\_packs`: Every tool pack with its product, description, tool count and whether it is allowed for this connection and listed right now.
- `find\_tools`: 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
- `call\_tool`: 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.
- `call\_write\_tool`: 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
- `enable\_packs`: Add packs to tools/list for this connection \(remembered\). Only allowed packs can be listed; the client refreshes its tool list.
- `disable\_packs`: Remove packs from tools/list for this connection to keep the list short. Tools stay reachable through call\_tool and call\_write\_tool.
- `ask\_finai`: 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 w
- `switch\_company`: Choose the company Hub tools act on, by id or name \(get\_connection lists them\). Remembered on this connection.
- `flow\_apply\_blueprint\_widgets`: 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 checkpo
- `flow\_apply\_upstream\_update`: 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
- `flow\_connect\_chat`: 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.
- `flow\_create\_custom\_table`: 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, s
- `flow\_create\_flow`: 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 fram
- `flow\_create\_flow\_from\_blueprint`: 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
- `flow\_delete\_flow\_files`: Remove files from a flow's tree by path. Engine-owned paths are rejected. Recorded as a checkpoint + chat note like writes.
- `flow\_deploy\_flow`: 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 sec
- `flow\_get\_blueprint`: 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 depe
- `flow\_get\_preview\_status`: 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\).
- `flow\_get\_scaffold`: 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 b
- `flow\_get\_upstream\_status`: 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 origin
- `flow\_get\_upstream\_update`: 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
- `flow\_install\_extension`: 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 as
- `flow\_list\_blueprints`: 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
- `flow\_list\_custom\_tables`: 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 sanctio
- `flow\_list\_extension\_custom\_tables`: 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 —
- `flow\_list\_extension\_surfaces`: 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 looku
- `flow\_list\_extensions`: 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 n
- `flow\_list\_flows`: 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 fiel
- `flow\_list\_secret\_keys`: 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
- `flow\_log\_message`: 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.
- `flow\_lookup\_command\_frame`: 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,
- `flow\_lookup\_engine\_component`: 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.
- `flow\_lookup\_pos\_api`: 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, out
- `flow\_open\_in\_builder`: 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\).
- `flow\_read\_flow\_files`: Read a flow's generated source tree. Omit \`paths\` to list all file paths \(cheap\); pass \`paths\` to fetch specific files' contents.
- `flow\_rename\_flow`: 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 nex
- `flow\_request\_secret`: 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 DI
- `flow\_search\_blueprints`: 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: bluepr
- `flow\_start\_preview`: 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
- `flow\_stop\_preview`: Stop the flow's preview sandbox and free its resources. The next start\_preview cold-boots in a couple of seconds.
- `flow\_sync\_preview`: 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 ve
- `flow\_update\_custom\_table`: 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 sta
- `flow\_validate\_flow`: 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
- `flow\_write\_flow\_files`: 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\_f
- `hub\_add\_customer\_note`: 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.
- `hub\_add\_modifier\_choice`: 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 co
- `hub\_add\_product\_images`: 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.
- `hub\_add\_tax\_rate\_to\_group`: 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 crea
- `hub\_adjust\_stock`: 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 fro
- `hub\_assign\_role`: 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
- `hub\_cancel\_booking`: 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.
- `hub\_cancel\_purchase\_order`: 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
- `hub\_confirm\_booking`: 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.
- `hub\_create\_booking\_resource`: 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.
- `hub\_create\_booking\_rules`: 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
- `hub\_create\_category`: 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
- `hub\_create\_customer`: 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 inve
- `hub\_create\_modifier`: 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\); "mu
- `hub\_create\_outlet`: 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 fo
- `hub\_create\_product`: 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 tax
- `hub\_create\_product\_option`: 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.
- `hub\_create\_purchase\_order`: 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 outlet
- `hub\_create\_role`: 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 pe
- `hub\_create\_station`: 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.
- `hub\_create\_stock\_transfer`: 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 gai
- `hub\_create\_supplier`: 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
- `hub\_create\_tax\_group`: 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 y
- `hub\_create\_tax\_rate`: 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 n
- `hub\_create\_user`: 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
- `hub\_delete\_category`: 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
- `hub\_delete\_customer`: 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 inste
- `hub\_delete\_media\_file`: 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 cleane
- `hub\_delete\_modifier`: 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 wer
- `hub\_delete\_modifier\_choice`: Remove one choice from a modifier. Refused when it would leave a category asking for more choices than remain — the explanation names the category.
- `hub\_delete\_outlet`: 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 ke
- `hub\_delete\_product`: 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 i
- `hub\_delete\_role`: 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 w
- `hub\_delete\_station`: 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 stati
- `hub\_delete\_supplier`: 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 orde
- `hub\_delete\_tax\_group`: 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
- `hub\_delete\_tax\_rate`: 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 al
- `hub\_export\_records`: 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 retu
- `hub\_export\_stock\_csv`: 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 man
- `hub\_find\_low\_stock`: 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
- `hub\_get\_booking\_availability`: 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 r
- `hub\_get\_booking\_events`: 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
- `hub\_get\_booking\_resources`: 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
- `hub\_get\_booking\_rules`: 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 s
- `hub\_get\_categories`: 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 return
- `hub\_get\_category\_modifiers`: 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 ca
- `hub\_get\_customer`: 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.
- `hub\_get\_customer\_orders`: 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
- `hub\_get\_customers`: 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 o
- `hub\_get\_employee\_orders`: 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'.
- `hub\_get\_employee\_sales`: 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
- `hub\_get\_extension\_catalog`: 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\`
- `hub\_get\_extension\_surfaces`: 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
- `hub\_get\_financial\_summary`: 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 settlem
- `hub\_get\_installed\_extensions`: 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

Measured by MCP Station. Methods: https://mcpstation.net/methods.html · Terms: https://mcpstation.net/terms.html