AI / Agent access (MCP)

AI / Agent access lets you connect your own AI assistant — Claude (desktop, web, or CLI), ChatGPT, or a custom agent — to your Assemblified data over MCP (the Model Context Protocol). Once connected, you can ask your assistant about your bills of materialsBill of materialsA bill of materials tells Assemblified how to build one unit of a finished good. When a customer orders the finished-good variant, Assemblified deducts the right component quantities from inventory automatically. Read more → , assembly BOMsAssembly BOMThe BOM for an intermediate component you build and then use inside other bills — a lid, a wick assembly, a pre-wired harness. It keeps its own pre-assembled stock and can be a work order item in its own right. Read more → (the app’s newer name for subassemblies), materialsMaterialThe atomic component of a bill of materials or an assembly BOM. Two flavours: a Shopify-linked variant, whose inventory Shopify tracks, or a virtual material, which Assemblified tracks on its own and Shopify never sees. Both sit in the same component picker and are consumed the same way. Read more → , work ordersWork orderA planned production run: pick materials, build the items, do QC, and complete — all tracked together. Use work orders when you're building stock ahead of demand or running a multi-day project. Read more → and reports in plain language — and, if you allow it, have the assistant do the work for you.

In the Assemblified admin this is Settings → Connections → API & agent access. (The page itself is still headed “LLM / API access” — same page, older name.)

Open beta

API & agent access is currently in open beta. It requires an active Assemblified subscription, and access may move to the Enhanced plan in the future. Open Settings → API & agent access to create API keys or connect a web chat.

On this page

• What you can do with it
• How it works (code mode)
• Large results and failed runs
• What the API covers
• Built-in workflow recipes
• Read-only by default
• Where to next

What you can do with it

Connect an AI assistant and ask things like:

• “Which of my finished goods can I build right now, and what’s the limiting component?”
• “List every material that isn’t used in any bill yet.”
• “Register these Shopify variants as materials and build a bill for the Gift Box Deluxe.”
• “Set the pre-assembled count for this assembly BOM to 12 at my main location — I just counted them.”
• “Plan a work order for 40 Oak Tables and tell me what I’m short of.”
• “Run the top-selling finished goods report for last month.”

The assistant reads live data from your store — and, with write access, makes the changes for you — so there’s no copy-pasting product IDs or exporting spreadsheets.

How it works (code mode)

Assemblified exposes a single, powerful tool to your assistant called run. Instead of the assistant chaining dozens of small requests, it writes a short program against a typed app API and Assemblified runs it once, safely, in an isolated sandbox:

run("return await app.rawMaterials.list({});")

This “code mode” approach lets the assistant search, filter, join, and summarise your data in one step — for example, finding the right Shopify variants, registering them as materials, and composing a bill from them — without you writing any code yourself. You just ask in plain language; the assistant writes the program.

Five more tools sit beside run:

• search: finds the right methods for a question. The API is organised as a catalogue of topics, each topic lists its methods, and each method has its input and result types. An assistant searches that catalogue first, so it only loads what it needs.
• describe_api: the live, typed definition of the topics or methods the assistant picked ({ namespaces: ['billOfMaterials'] } or a list of methods). Called with no arguments, it returns short guidance followed by the whole definition, which is very large. If your chat client struggles, telling it which area you mean is the single most useful hint you can give it.
• list_docs and get_doc: this very documentation site, so the assistant can ground its answers in how Assemblified actually works instead of guessing.
• whoami: which store the connection belongs to, whether it is read only or read and write, the kind of connection (an API key, or a connector you approved with a connection code), its label, and the API version. Ask “Which store am I connected to?” to check a new connection.

Connecting is light: when your assistant connects, Assemblified sends a short introduction (about 10,000 characters) rather than the full definition of every method, and the assistant looks up the rest when a question needs it. The current API version is 2.3.

Large results and failed runs

• Large answers are shortened. When a successful result is longer than about 24,000 characters, Assemblified shortens it and marks clearly what was left out and how much, so the assistant knows the answer is incomplete. IDs and paging details are always kept, so the assistant can fetch the rest page by page. It can also ask for the whole result on a single call.
• Results that changed something are never shortened. If a run wrote anything, its result comes back in full, because it is the record of what was saved.
• A failed run says what happened. The error lists which app calls ran and how each one ended, and states whether repeating the whole run is safe. A run that may already have saved changes is reported as not safe to repeat, so a careful assistant checks what was saved before it tries again.

What the API covers

The app API is organised into 25 topics, each with a one-line summary the assistant can search. These are the ones a connection can reach:

• Bills and BOMs — billOfMaterials and assemblyBills (your finished goods and your reusable assembly BOMs, with their composition, per-location rules, pre-assembled stockPre-assembled stockStock of finished goods and subassemblies already built and on the shelf, counted per location. For Shopify-linked finished goods, these units are part of the applicable on-hand balance, not extra stock to add to it. A work order draws subassemblies from the shelf first, building fresh only if it runs short; an order consumes a finished good's shelf before its components. Read more → and a buildable calculator that matches the app’s Buildable column), billVersions (a bill’s saved history and the way back to it) and bulkBomRules (the saved rules the bulk bill builder replays).
• Materials and stock — rawMaterials (Shopify-linked and virtualVirtual materialA material tracked entirely inside Assemblified — not a Shopify variant. Useful for shop-floor consumables (glue, packaging, labour units) where you need quantity tracking but don't want a Shopify product on your storefront. Read more → ), metafields (stored values on a material), inventory (real per-location levels, pre-assembled and residual figures, what is committed, what is allocated, and restocking) and inventoryGuard (the check that finds lines Shopify would reject before a stock push).
• Manufacturing — workOrders (the whole work-order surface: plan, edit, transition, build runs, QC, documents, purchase orders, the work-order catalogues and order production for one reserved order) and assembleTasks (the lighter task list).
• Your Shopify store — shopify (search products and variants, list locations) and orders (the per-order bill breakdown a warehouse packs from).
• Catalogues — costFactors (additional costs), units and unitConversions, materialTags, metafieldDefinitions, importTemplates, assignees (the people a work order can be assigned to) and entityGroups.
• Insight and admin — reporting (the report catalogue, running a report, and the order-history sync), dashboard (the home summary), search (the app’s own cross-entity search over your records, not to be confused with the search tool that finds methods), executionLogs (what the app did and whether it worked) and settings (read, explain, preflight and change your store settings).

A read-only connection only sees the read methods of each topic.

Built-in workflow recipes

Assemblified also offers five step-by-step recipes for common jobs. An assistant that supports MCP skills can load one and follow it, so it takes the same careful route every time:

• BOM inspection: read one bill end to end, with its materials, nested assembly BOMs, location rules, cost and buildable units.
• Shortage investigation: explain why a bill or a planned build is short, naming the limiting component, where, and by how much.
• Approved work-order production: run production on a work order you have approved, from preview through start and completion, and recover from a refused or uncertain step.
• Bulk material creation: create many virtual materials with a dry run first, then create after your approval and report the outcome row by row.
• Inventory preflight and recovery: find and resolve the lines Shopify would reject before, or after, a stock push.

Every connection can read the recipes, but a recipe never widens what a connection may do: a read-only connection can read the production recipe and still cannot change anything.

Read-only by default

By default, AI / Agent access is read-only: your assistant can look at your data but cannot change anything. Actions it isn’t allowed to take aren’t even visible to it.

If you explicitly grant write access (a write-scope API key, or a web-chat connection granted write when it’s linked), the connection unlocks a large surface. In outline, a write key can:

• build and maintain bills, assembly BOMs, materials and their per-location rules;
• adjust pre-assembled stock, set virtual stock levels and restock any material at any location — including pushing stock to Shopify;
• run work orders end to end, including starting a build run, which moves real Shopify inventory (Enhanced plan);
• save and restore a bill’s versions (Enhanced plan), and push a computed cost to Shopify;
• maintain your catalogues — units, tags, metafield definitions, import templates, assignees, groups and the bulk-builder rules;
• change your store settings, and refresh or restart the reporting sync.

Write access is broader than it used to be

A write-scope key is not limited to editing BOMs. It can move real stock and change how your store behaves. Grant it deliberately, prefer a read key for anything exploratory, and read Managing access & security before you hand one out. The operating pages below describe each write surface in detail.

Note

A read-only connection is safe to experiment with: the worst it can do is read data it’s allowed to read, scoped to your single store. Write access is opt-in per key or connection and can be revoked at any time.

Where to next

Create an API key Issue a key for a desktop or command-line client.

Connect a desktop / CLI client Claude Desktop, Claude Code, Codex, custom agents.

Connect claude.ai or ChatGPT The web-chat connector flow with a one-time code.

What the assistant can read The full read-only data surface.

Managing access & security Revoke keys and connections; the security model.

The operating pages

Each one describes a write surface in detail: what it can do, what it refuses, and what needs a plan.

BOMs & assembly BOMs Build, compose, stock and configure finished goods and assembly BOMs.

Materials & stock Register materials, set virtual levels, restock and reconcile.

Work orders Plan a build, run it, review it, and order what is missing.

Bill versions Snapshot a BOM, compare two versions, and restore one.

Reports The report catalogue and running a report over a period.

The reporting sync Check, refresh and restart the order-history copy reports are built on.

Settings Read, explain and change your store settings safely.

Groups & saved views Group bills, assembly BOMs and materials; what the assistant sees of saved views.

Bulk bill-builder rules The saved rules the bulk builder replays over a grid.

Units & conversions The unit catalogue and the conversions between units.

Material tags Maintain and apply your material tag list.

Metafield definitions The custom fields your materials carry.

Import templates The saved column mappings your imports use.