create_artifact
ChatGPTPublish an HTML page and return a link to open it — a review, a shortlist, a dashboard someone can sort and hover. Take `get_skill('create-artifact')` and `get_skill('artifact-design')` before writing any of it, get_skill('artifact-charts') if the page carries a chart, and get_skill('artifact-diagramming') if it carries a diagram — a flow, a timeline, two options side by side. The first says when a page beats a plain answer and what may be loaded; the second is the visual system, without which the page is default-styled HTML and worse than a plain answer.
create_promotion
ChatGPTCreate forecast event and product links with optional customer scope. Two ways to define the forecast impact: - Uniform: exactly one of forecast_impact_rate / forecast_impact_qty, applied to every product selected via product_ids, tag_ids, or search. - Per-product: product_impacts, a list of entries like {"product_id": 123, "impact_qty": 500} or {"product_id": 456, "impact_rate": 0.2} — each product under the same event gets its own impact. Cannot be combined with the uniform impact or the selection parameters. Customer scope: omitting customer_ids applies the event to ALL the site's customers. When the user targets specific customers (e.g. a promo for one retailer), resolve their internal ids with list_customers (search by name or external id) and pass them in customer_ids — never guess ids and never omit the parameter in that case. promotion_type classifies the promotion: one of catalog, featured_placement, other. Only used when is_promotion is true; keep the default other unless the user names the promotion kind. discount is not accepted: this tool cannot set prices, and a discount promotion without price data would be a broken row — discount promotions are created in the Flowlity app.
create_view
ChatGPTCreate a saved view (assigned to you only), ready to open with no render errors. module (required): one of demand, planning, supply_order, supply_order_line, supply_agreement, sales_order, sales_order_line, pricing, dashboard. Note the Orders module key is supply_order, not order. (assortment views can be opened with open_view but not created here; tactical has no views UI in the app anymore — use planning instead.) columns (optional): list of column keys. Omit to inherit the module's curated default columns; pass [] for an explicitly empty view. Discover keys with list_view_columns(module). filters (optional): a high-level spec translated server-side into the internal shapes — NOT a raw Prisma where. Supported keys: - tag_ids: [int] — products/orders carrying any of these tags (demand/planning/tactical and supply_order/supply_order_line). Resolve ids with list_tags. - statuses: [int] — order status ids (order modules only). Unknown keys are rejected here with the accepted set. group_by (optional, product modules): a tag-category name or id. Prepends a per-category tag column (tag_category_id:{id}) so the list reads grouped by that category (e.g. by Clinic). sorting (optional): passed through; for product modules top-level keys are validated (e.g. {"kpi": {...}}, {"name": {...}}). upsert (optional): when true, an existing view you own with the same site+module+name is updated instead of creating a duplicate — makes re-running a view suite idempotent.
delete_demo_rows
ChatGPTDelete rows of a demo table matching equality filters. where maps columns to the values identifying the rows to delete (a null value matches IS NULL). Defaults to a dry-run preview of the matched row count; re-run with dry_run=False to apply.
delete_view
ChatGPTDelete a view you created, along with its user assignments.
describe_demo_table
ChatGPTDescribe the columns of a demo table (types, primary key).
describe_uploaded_file
ChatGPTDescribe an uploaded file: its sheets, columns, types and row count. Call this before querying one, so the column names and their types are known. It returns the shape of the file, never its data — use query_uploaded_file for anything counted, summed or filtered.
explain_forecast
ChatGPTExplain why Flowlity's forecast of ONE product is what it is: where the number comes from and what the model learned. Answers "why 15?", "why does the forecast go up?", "why doesn't it follow the trend?", "why is August high?" and "why was March low?" from what the last forecast run recorded for the product. Two layers: the sources blended into the final forecast (the foundation model and each expert model, with its weight, the average it gives and its effect on the figure: "30 % comes from the average of the last 12 weeks, which lowers the forecast by 6 %"), then what the foundation model learned as approximate shares — seasonality, trend, related products, demand regularity, external signals — anchored on the product's recent demand. Then the forecast period by period, and the events corrected in the history before training (outliers, shortages, smoothed promotions). period reads one period the way the planner sees it: YYYY-MM for a month (its total over the calendar month on a weekly run, with the weekly average), YYYY-MM-DD for one week, month or day of the run. A future period gives the figure the app shows for it and the run it comes from, every family with its share and the fact behind it, the sources with their effect on the period, and the same period a year and two years earlier; a past one is read off the observed demand and the events recorded on it. A month named without a year is its next occurrence in the horizon. Resolve product_site_id with list_products first. For the forecast values alone use get_forecast_history; for the projected stock, get_product_planning; to change the expert models, the Product Strategy page of the product. Set chart=True to also get the product's seasonal profile (its index by month) as a chart image. The forecast itself is not charted: the product's page shows it. Leave it off unless the picture is wanted: an image costs input tokens on this turn and on every later one.
explain_order
ChatGPTExplain why a recommended (planned) delivery of the supply plan has its quantity and date, for ONE product. Answers "why 50?", "why on that date?" and "why does the recommendation change over the months?" with the net requirement calculation the optimizer's objective implies: stock the day before, final forecast until the next delivery, minimum on the tightest day of that window, MOQ and lot rounding. The deliveries explained are the plan's (public.planning, what the planner sees); the order table only adds supply ids and validation dates, and the tool says so when the two differ. Each planned delivery gets a verdict — the pushed quantity matches the requirement exactly, or is above or below it — and a gap names the constraints that can cause it rather than guessing. Two readings. With supply_id (from list_orders or get_order_review) or delivery_date (YYYY-MM-DD), ONE delivery is explained: what it covers (up to the next delivery of the plan), the quantity step by step, the date. With neither, THE PLAN is explained: every delivery to come, planned ones with their requirement, firm ones as the planner's. Firm orders are not explained: the plan takes them as given. Resolve product_site_id with list_products first. For the constraints themselves use get_product_supplier_constraints; for the projected stock curve, get_product_planning.
get_capacity_alerts
ChatGPTReturn capacity alert summary and dated rows.
get_data_quality_audit
ChatGPTRun every master-data check over every item on a site, and return only the defects. The whole data-quality audit in one call: missing supplier link, placeholder lead time, stale lead time, wrong ABC category, item not deactivated, missing valuation price, no primary supplier. Each one is evaluated against 100% of the item base in the database, and only the flagged items come back — ranked by the value they expose, each with the field to correct and a link to the item. Use this instead of paging list_products, get_product_supplier_constraints and get_product_constraints and comparing them: a 4,000-item site is over 1 MB of tables that way, and an audit assembled from a few pages of it covers a few percent of the base while reading as complete. get_demand_summary and get_monthly_demand_forecast are not needed either — the demand figures behind every impact here are the ones they read. tag_ids narrows the audited population to a family, class or buyer, with every check still running fully inside it. abc_tag_ids names the site's ABC class tags (from list_tags) for the ABC check; without it they are guessed from tag names, which misses a site whose classes are named in another language. checks runs a subset; valid keys are missing_price, missing_supplier, placeholder_lead_time, stale_lead_time, no_primary_supplier, wrong_abc, not_deactivated.
get_demand_summary
ChatGPTReturn demand history and forecast summary for a product.
get_forecast_accuracy
ChatGPTReturn MAPE/MAE/FVA forecast accuracy windows for one product.
get_forecast_audit
ChatGPTRun every forecast check over every product on a site, and return the ranked review list. The whole forecast audit in one call: shortage-distorted history, outliers, forecast-degrading overrides (planner or imported), demand level shifts, new products with nothing to anchor on, persistent bias, and unexplained low accuracy, each evaluated on 100% of the products in the database, in the procedure's attribution order, so a miss explained by a shortage, a promotion or an end-of-life is never flagged as a forecast defect. Returns the forecast error value and how concentrated it is, the share that is not a forecasting problem, override value added (each override scored against the Flowlity run from before its edit, fair months only), error value by root cause, per-check coverage, and the flagged products ranked by impact, each with the forecast input to fix and its Demand and Planning links. Products whose demand a planner reviewed inside review_window_weeks are left off the list unless one of their anomalies started inside that window. Use this instead of looping get_monthly_demand_forecast, get_forecast_accuracy, get_forecast_history and get_my_forecast_history per product: that covers a few percent of a site while reading as complete. For the site's accuracy KPI and its trend, add get_site_kpis and get_kpi_trends. tag_ids narrows the population (a family, a class), every check still running fully inside it. checks lists a subset; valid keys are shortage_history, outlier, override, level_shift, new_product, bias, unexplained.
get_forecast_history
ChatGPTReturn Flowlity forecast versions for one product, by target month. Shows how the monthly forecast for a given target month evolved across forecast runs (e.g. May-26 run forecasted Aug-26 = 30; Jun-26 run forecasted Aug-26 = 45). Rows are sorted by target month then by forecast run date (updated_date) ascending, so the latest run is at the bottom of each target-month block. Forecasts are sourced from the Flowlity ML output at the site's configured granularity — ml.demand_forecast_flowlity_day_aggregated, _week_aggregated, or _month_aggregated depending on config.site_global.forecast_granularity (daily / weekly / monthly, default weekly). Day and week buckets are aggregated into calendar months via date_trunc('month', target_date); a bucket whose start date straddles a month boundary is attributed to the month containing its start. Forecast runs that happen within the same calendar month as the target are excluded so partial-month sums don't appear as a sudden revision (matches the dbt accuracy convention). Dates must be in YYYY-MM-DD format. target_month_start and target_month_end are inclusive and bound the target months covered.
get_future_demand
ChatGPTReturn the future demand a site has received, bucketed by period. Reads public.demand_future: one row per product, customer and day, split by status: firm is a confirmed sales order, planned is expected demand not yet confirmed. Covers the whole site by default; pass product_site_id for one product, or customer_id (resolve it with list_customers) for one customer. granularity is month (default), week or day. The Origin line splits the total between the site's own customers, a child site (intercompany) and MRP explosion of a BOM. Only the first is a customer order: read the split before quoting Total as demand from customers, since a site whose demand is mostly intercompany transfers or exploded components would otherwise read as one with a full order book. start_date and end_date are inclusive, in YYYY-MM-DD format; past dates are allowed. A range that starts or ends inside a bucket makes that bucket partial, so ask from the 1st of a month to the last day of one before comparing monthly totals. limit caps how many buckets come back (default 50, max 1000), taking the earliest ones: a range that needs more is cut off at its far end, and the header says so when that happens. Set chart=True to also get firm and planned demand as a chart image, drawn from the same rows. Leave it off unless a picture is wanted: an image costs input tokens on this turn and on every later one.
get_import_status
ChatGPTReturn latest import status rows by site, dataset, or specific import id.
get_kpi_trends
ChatGPTReturn monthly KPI trend points, with optional tag-level filtering. Valid kpi values: demand_plan, inventory_level, supply_plan, stock_coverage, zero_stock_days. Units: demand_plan / inventory_level / supply_plan trends carry a quantity (default unit) and a value (EUR). stock_coverage is expressed in days of coverage (site average) — it has no value/currency dimension. zero_stock_days is a 0-1 rate shown as a percentage.
get_monthly_demand_forecast
ChatGPTReturn demand and forecast bucketed by calendar month for a product. Use this tool for cross-year same-month comparisons (e.g. compare the forecast for Jul-26 against the actual demand for Jul-25 and Jul-24). Each row aggregates one calendar month between start_date and end_date (inclusive, YYYY-MM-DD). Actual Demand is summed from public.demand (typically populated for past months); Final Forecast and Flowlity Forecast are summed from public.final_forecast (typically populated for current/future months). Use a date range that spans the years you want to compare.
get_my_forecast_history
ChatGPTReturn My Forecast (planner override) values for a product, past dates included. Reads public.my_forecast, which keeps planner-entered forecast values for past buckets as well as future ones. Each row is one forecast bucket date (site forecast granularity, typically the week start) with the quantity summed across customers, the date of the last edit, and the source (user = edited in the app, data = imported). Buckets whose override was cleared (no value) are omitted. Combine past values with actual demand (get_monthly_demand_forecast) and Flowlity forecast versions (get_forecast_history) to judge whether planner overrides improved or degraded forecast accuracy. Dates must be in YYYY-MM-DD format; past dates are allowed.
get_order_alerts
ChatGPTGet order alert summaries and recent alert rows.
get_order_review
ChatGPTOne-call order review for a site: what to validate, what is late, and qty vs stock. Composite tool for the order-analysis use case. Returns a summary of open orders and validation deadlines (overdue / next 7d / 14d / 30d), the list of planned orders to validate (soonest deadline first, with order qty next to current stock), and the top suppliers with late firm deliveries. Use this instead of paging list_orders and cross-checking statuses and dates by hand. A planned order (status_id = 1) must be validated by its latest_order_date; a firm order (status_id = 3) whose delivery date has passed counts as a late delivery.
get_product_constraints
ChatGPTReturn product-level planning constraints (coverage, min/max stock, shelf life). This is the product level (public.product_site): the inventory policy that constrains a product on its own, independent of supplier — minimum stock policy, target coverage days, maximum stock, shelf life and stock valuation price. Filter with `product_ids and/or tag_ids. For supplier-specific MOQ/lead time/price/lot size use get_product_supplier_constraints`.
get_product_detail
ChatGPTReturn full product details including tags, suppliers, alerts, and BOM.
get_product_planning
ChatGPTReturn planning time series for one product and date range.
get_product_supplier_constraints
ChatGPTReturn per-supplier sourcing constraints for products (MOQ, lead time, price, lot size). This is the product x supplier level (public.product_supplier_link): the MOQ, lead time, unit price, lot size and order frequency negotiated with each supplier for each product. Defaults to the primary supplier per product (highest active quota share, resolved from public.quota); set `primary_supplier_only=False to list every supplier grouped by product x supplier. Filter with product_ids and/or tag_ids. For supplier-wide constraints (basket MOQ, full truck) use get_supplier_constraints; for product planning policy (coverage, min/max stock, shelf life) use get_product_constraints; for tag-based supply agreements use get_tag_constraints. When a row has a non-null Tag Family / Family MOQ, the line MOQ is enforced at the **tag-family scope** (sum over every product in the family >= Family MOQ) at sites where config.site_or.tag_family_moq is on. Audits like "MOQ vs forecast" should aggregate demand at the family level in that case, not per product. Use list_products(tag_ids=[<family_id>])` to enumerate the family.
get_promotion_detail
ChatGPTGet detailed promotion info and per-product impact rows.
get_promotion_kpis
ChatGPTAggregate promotion volume, revenue and cost over one dimension. This is the reporting tool: it answers "net cost per retailer this quarter", "which mechanic costs most", "how much of each budget is consumed" in one query. Do not page list_promotions and add the rows up — 300 promotions is 300 rows of client-side arithmetic and the totals will not match the app's. group_by is one of: customer, type, mechanic, status, month (the promotion's start month), budget, owner (the envelope's key account manager). Set chart=True to also get net cost and revenue by month as a chart image, drawn from the same rows as the table. Only group_by=month records a series — the other dimensions are rankings, not a time axis. Filters: period_start / period_end (YYYY-MM-DD, inclusive) select promotions overlapping the window; status (planned, in_progress, confirmed; comma-separated), customer_id and promotion_type narrow further. Allocated is the total of the distinct budget envelopes the group's promotions charge, and % Consumed is the group's net cost against it — so with group_by=budget it is the envelope's own consumption, and with any other dimension it is that slice's share of the envelopes it touches. Realised / Forecast compares realised sell-out against the forecast for the days already past, never the whole period.
get_site_config
ChatGPTFetch detailed site configuration and feature flags.
get_site_kpis
ChatGPTReturn aggregated dashboard KPIs for a site.
get_skill
ChatGPTFetch one of Flowlity's written procedures for a recurring planning job. Call this before starting the work it describes, not after: it gives the order to do things in, which tools to use, and the mistakes that make an answer wrong. If the user names a skill below — with or without a leading slash — fetch that one, even when a different skill looks like a better match for what they are asking about. A name they typed is an instruction, not a hint, and overriding it silently leaves them with no way to get the procedure they asked for. The identifier, the title, or a unique part of either all resolve, so pass whatever they wrote. When you have followed one, end with a single short line naming it — "Followed Flowlity's <title> procedure; ask for it by name next time." Most users never learn these exist, and the moment they have just been useful is the only moment worth spending a sentence on it. The set is not listed here. It is authored outside this deployment and changes without one, so call this with no name first to get the current list, then fetch the one you need by name. Do that for "what procedures do you have" asked in general, and equally when the user names or describes one job — "is there a guide for a replenishment review?" — because the list is where the exact name comes from. Call it again every time you are asked, even when you already have a list. The set changes while a conversation is open — someone adding, pausing or removing one between two questions is ordinary — so an earlier reply of yours is not evidence of what exists now. Answer from a fresh call, never from the transcript.
get_stock_coverage
ChatGPTReturn stock-coverage metrics and optional low-coverage filter.
get_stock_history
ChatGPTReturn past stock on hand for ONE product over a date range, by period. This is inventory history — what the product actually held on a past date. get_stock_levels gives stock as of today, and get_product_planning only starts at yesterday and runs forward, so this is the tool for "how much stock did we hold in March", for stock seasonality, and for any month-over-month inventory comparison. Reads dbt_flowlity.past_stock, the daily series the app's own inventory KPIs are built from, so the figures agree with the UI. It is public.stocks made continuous: that table holds a row only where an import wrote one, and a gap between two rows is the stock staying put rather than the stock being unknown — so each reading is carried forward until the next one, storage sites are summed, and shortend storage counts as zero. Querying public.stocks by date directly returns nothing on most dates for that reason. granularity is day (default), week or month. Ask for `week` or `month` on a range longer than a month or so: a year of daily buckets is past the ceiling this tool will return, and aggregating in SQL is the cheaper answer than a bigger limit. Stock is a level, not a flow, so it is never summed — an aggregated bucket reports its closing stock plus the average, lowest and highest stock inside it. The average is the inventory figure an S&OP or IBP review quotes for a period; the low is what says whether the period ran dry. start_date and end_date are inclusive, in YYYY-MM-DD format. A range starting or ending mid-bucket makes that bucket partial and its average an average of fewer days, so ask from the 1st of a month to the last day of one before comparing monthly figures. The series ends at the last completed day; for stock as of today call get_stock_levels, which also breaks it down by storage site. For a whole site or a tag rather than one product, use get_kpi_trends with kpi='inventory_level': it is monthly, and it carries the value in EUR as well as the quantity. Set chart=True to also get the series as a chart image, drawn from the same rows. Leave it off unless a picture is wanted: an image costs input tokens on this turn and on every later one.
get_stock_levels
ChatGPTReturn stock levels either by product or storage-site breakdown.
get_stockout_kpis
ChatGPTPer-item stock-out KPIs for a whole site: past and projected days out of stock, and the units each costs. One call covers every item on the site (or in tag_ids), so use it for any portfolio question about stock-outs ("which items ran out last quarter and how many sales did we lose", "which will run out and how much forecast is not covered") instead of looping get_stock_history or get_product_planning per product. For each item: - Past days out: days in the last lookback_days (ending yesterday) the actual stock closed at zero. - Est. lost units: past days out × average daily sales on the days the item was in stock. - Projected days out: days in the next horizon_days (from today) the projected stock is at zero, weekends included. - Units short: forecast the projected stock cannot serve over the horizon, with the first projected stock-out date. Only items with demand count: sold in the last 12 months for the past figures, forecast left uncovered for the projected ones. The summary lines total the whole list, not just the page. For what to act on now (criticality, last date to act) use list_product_alerts; for shortages detected from demand drops use list_shortage_periods. lookback_days and horizon_days are 1 to 365. sort_by is units (lost + short, default), past_days or projected_days.
get_supplier_constraints
ChatGPTReturn supplier-wide constraints (basket MOQ, full truck, order frequency). This is the supplier level (public.partner_site): constraints that apply to a whole order to a supplier rather than to one product line — the basket minimum order quantity, full-truck quantity, order frequency, max supplies per order and transportation lead time. Lists the suppliers used at the site. Filter with `supplier_ids (partner_site IDs). For per-product MOQ/lead time/price/lot size use get_product_supplier_constraints`.
get_tag_constraints
ChatGPTReturn tag-based supply-agreement constraints applied to products. This is the tag level (public.tag via public.product_tag_link): lot size and supply-agreement / supply-price rules defined once on a tag and shared by every product carrying it. Returns one row per product x constraint-tag. Filter with `product_ids and/or tag_ids. Per-supplier MOQ/lead time/price lives in get_product_supplier_constraints; supplier-wide rules in get_supplier_constraints`.
get_view
ChatGPTReturn the full config of a view (columns, filters, sorting, compiled where). Use it to verify a view you just created, or to mirror an existing working view before cloning its column/filter set. Works for any view on a site you can access (not just ones you created).
get_weekly_supply_review
ChatGPTOne-call weekly supply-chain review for a site: KPIs, risks, and order actions. Capstone digest for the recurring weekly supply-chain presentation. Combines the site headline KPIs, the stock-out and overstock risk counts (including how many stock-outs have no firm order on the way), the order validation backlog (overdue / 7d / 14d / 30d) and late deliveries, plus short top-top_n lists of the orders to validate this week and the stock-outs that need an order. Use this for a weekly summary instead of calling the KPI, alert and order tools separately.
join_uploaded_files
ChatGPTCompare two files the user uploaded, matched on a shared reference. The question this exists for is "last month's export against this month's": two files whose rows correspond through a SKU, a supplier code or an article reference, where the answer is a number over the pair rather than over either one. The reply says how many rows found a partner, always. A pairing that matched nothing looks exactly like a file with nothing above the threshold, and the usual cause is one of the two exports having lost an identifier's leading zeros in Excel — describe_uploaded_file warns about that, and this is where it bites. Rows that matched nothing are counted, not listed. Both files must belong to the caller's company; either one that does not resolves to nothing. Call describe_uploaded_file on each file first, for its column names. Pass chart=True on /mcp to get a grouped answer as an image as well; the agent bridge strips both the flag and this paragraph, since that channel has the cheaper chart event.
list_capacity_units
ChatGPTList site capacity units with supplier and product counts.
list_customers
ChatGPTList the site company's customers with their internal ids. Use this to resolve a customer name or external id (e.g. "Aldi") into the internal id that create_promotion(customer_ids=...) expects. search matches name and external id; Products counts the products linked to the customer on this site.
list_demo_tables
ChatGPTList all tables in demo schemas (schemas starting with demo).
list_eol_items
ChatGPTList products with an end-of-life (EOL) date and their remaining stock. Surfaces products carrying a sale_end_at date so planners can monitor and run down stock. Each row also carries past demand and the forecast model, which is what separates an item that is genuinely finished from one whose EOL date is simply wrong: zero 12-month demand with a no_data model is dead, while a named model and recent demand means the date needs correcting, not the status. Both come off a table this query already joins, so the whole set is one call rather than one get_demand_summary per row. Set past_due_only=True for products already past EOL, and only_with_stock=True to keep only those still holding stock: together they answer "which discontinued items still have warehouse stock to push to stores". The summary line also reports how many products have an EOL date defined at the site. Set chart=True to also get the stock value per item as a chart image, drawn from the same column the table prints. Leave it off unless a picture is wanted: an image costs input tokens on this turn and on every later one.
list_orders
ChatGPTList order lines for a site with optional filters.
list_product_alerts
ChatGPTList product alerts and summary counts by criticality.
list_products
ChatGPTSearch and list products with inventory and demand KPIs.
list_promotion_budgets
ChatGPTList the promotion budget envelopes with what the promotions charge them. One envelope is a (retailer × cost type × period) pocket of money. Only Allocated is stored: Consumed, Confirmed only, Ceiling and Remaining are summed at read time from the promotions pointing at the envelope, the same way the app's budget checkbook does it. - Consumed (net) — every linked promotion's net forecast cost. - Confirmed only — the subset in status confirmed; the finance-grade number, since that is what reaches the ERP. - Ceiling — the worst case: for a NIP, the whole committed volume selling through with every unit redeemed. - Remaining — allocated − consumed. Negative means overcommitted. Filters: customer_id (resolve with list_customers), budget_type (nip consumer discounts, rsf invoice discounts, tmp trade-marketing fees — comma-separated for several), period_start / period_end for envelopes overlapping that window, and owner_email for one key account manager's envelopes (substring match).
list_promotions
ChatGPTList forecast events/promotions visible from the site context.
list_shortage_periods
ChatGPTList detected past shortage periods (possible shortages) for a site. Flowlity detects periods in the demand history where a drop in demand is likely explained by a stock shortage rather than a real demand decrease. Status reflects planner review: possible (detected, not yet reviewed), confirmed, or rejected. When a planner adjusted the period, the user-set dates replace the detected ones. Use this to avoid flagging past demand drops that are already explained by a (possible) shortage. start_date/end_date (YYYY-MM-DD) keep only periods overlapping the given range.
list_sites
ChatGPTList accessible sites with key company and feature data.
list_stockouts_without_firm_orders
ChatGPTList products in stock-out (or below minimum) that have no firm order incoming. Composite tool for the "stock-out + no firm order" review: it finds product-sites with an active or upcoming shortage alert (OUT_OF_STOCK or BELOW_FLOWLITY_MIN) and no firm (released) order with a delivery date today or later. Use this instead of calling list_product_alerts and list_orders separately and cross-checking. Pass horizon_days to keep only shortages starting within that many days.
list_tags
ChatGPTList tags available for a site's company and product links.
list_view_columns
ChatGPTList the column keys a view of module accepts, each with a human label. Pass site_id to also list this company's tag categories as tag_category_id:{id} columns (usable as columns or as group_by). Unlisted snake_case KPI keys are also accepted; the app ignores unknown columns at render, so they never crash a view.
list_views
ChatGPTList saved views for demand/planning modules on a site.
open_view
ChatGPTReturn a link that opens a saved view in the Flowlity web app. Identify the view by view_id, or by name (case-insensitive; add module to disambiguate). Works for any view on a site you can access. For demand/planning/pricing views the app activates the view on arrival; for other modules the link lands on the module's page where the view can be picked from the views bar (except tactical, whose page has no views bar — the response says so). Two caveats the response flags: the app opens on the user's last-used site (they may need to switch to site_id), and a view not linked to the caller's user is absent from their views bar — the app silently shows the Default view.
query_uploaded_file
ChatGPTCount, filter or aggregate the rows of a file the user uploaded. This is the only way to get numbers out of an upload, and the reason it exists: a file is stored as a table, not pasted into the conversation, so a total is computed over every row rather than estimated from the first few. Pass chart=True on /mcp and ChartImageMiddleware turns whatever record_series recorded into a PNG; the flag is never read here. The agent bridge strips the schema argument and this paragraph — which only works because the paragraph contains the literal the strip looks for (chart=True), and this one did not, so that channel was advertising an argument its own schema had removed. Call describe_uploaded_file first for the column names and types.
read_artifact
ChatGPTRead a page published with create_artifact — yours or a colleague's in the same company — by its id: its title, the tool calls that filled its tables and charts, and the text on it. Call it when the user brings a page into the conversation (a line naming an artifact id) or asks to extend, update or redo one. Then build the new version from fresh tool calls — the calls listed are where to start — and publish it with create_artifact: with replaces set to this id if the page is the user's own, as a new page otherwise.
restore_artifact
ChatGPTPut a published page back to how it was before the last republish, on the same link. Use it when a page was updated and should not have been — the wrong page changed, or the change itself was wrong. Takes the file id printed in create_artifact's answer. Only the previous version, and only your own pages. Restoring keeps a copy of what it replaced, so calling it twice puts the newer version back.
update_demo_rows
ChatGPTUpdate rows of a demo table matching equality filters. set_values maps columns to their new values; where maps columns to the values identifying the rows to update (a null value matches IS NULL). Defaults to a dry-run preview of the matched row count; re-run with dry_run=False to apply.
update_promotion
ChatGPTEdit an existing promotion: its product lines, dates, retailer or name. Find the promotion with list_promotions, the product ids with list_products and the retailer with list_customers. - product_impacts: entries like {"product_id": 123, "impact_qty": 500} or {"product_id": 123, "impact_rate": 0.2}. A product already in the promotion gets that impact on every one of its lines at this site; a product not in it yet is added, for the promotion's own retailer (with none, the one customer its other lines share; an adjustment: the customers its other lines already have). - remove_product_ids: products whose lines at this site are removed. Swapping a product for another version is one add plus one remove. - customer_id: the retailer the promotion targets; a promotion's lines move to it too. Only lines on site_id are touched. Dates and the retailer apply to the whole promotion, so they only change when all its lines are on site_id. dry_run defaults to true and changes nothing: show the user the preview, and call again with dry_run=false only once they confirm.
update_view
ChatGPTUpdate a view you created, preserving untouched fields. Same high-level filters/group_by/columns contract as create_view. The filter representations (config.filters, zenstack_where, filters_dto) are rebuilt only when filters is given; every other field — including a group_by regroup, which just adds a leading tag-category column — is a config-level change that preserves the untouched fields.
upsert_demo_rows
ChatGPTInsert rows into a demo table, updating existing ones on primary-key conflict. Every row must provide the same set of columns. With on_conflict_update=True (default), rows whose primary key already exists are updated instead of rejected. Defaults to a dry-run preview; re-run with dry_run=False to apply.
