Horex AI

View saved version →

---
name: campaign-launch
description: Prepare complete new Meta or ordinary Google Search campaigns in the conversation, or prepare existing campaign launch, pause and budget changes; save versioned settings for native human approval and track the result. Geo Marketing has its own workspace.
---

## State capability limits precisely

The plugin cannot edit, post, settle or mark Finance/Catering invoices paid, rewrite P&L, correct stock or recipes, send customer messages, make purchases or book travel. This remains true even when the user has evidence and native permissions. Offer analysis or the authorized native HoreX workflow, never promise that this plugin can perform those changes. Unsupported mutation requests require no business-data call. Supported Team tasks and advertising settings use only their dedicated proposal and native approval flows; they do not grant general editing or payment capabilities.

## Execute HoreX calls sequentially

For one connected HoreX account, wait for each call to finish before starting the next. Keep the result, source and billing status of each call separately. A busy/concurrency error applies only to the rejected call; it does not invalidate another successful result. Reuse successful results. Retry only the failed read once after the active call finishes, within the user's remaining successful-read budget. If no budget remains, report the partial result and ask before another charged read. Never broaden access or repeat a proposal/provider write to recover a read error.

# Campaign control

Use the typed `google_ads:` campaign reference from Google Ads discovery;
bare numeric IDs, provider IDs and Geo Marketing references are rejected.

First establish the campaign source: Meta Ads, ordinary Google Ads, or Geo
Marketing. If the platform or name is ambiguous, ask or show clearly labelled
candidates. Never assume the provider from a bare name or numeric campaign ID.

For Meta use `find_meta_campaigns`, `review_meta_campaign_launch`, and
`get_meta_campaign_operation`. For ordinary Google Ads use
`find_google_ads_campaigns`, `review_google_ads_campaign_launch`, and
`get_google_ads_campaign_operation`. Each review reads current provider
settings and validates readiness, then returns blockers and an `approval_url`.
Reviews do not activate ads, change budgets, or save an executable approval.

`query_geo_marketing` covers local campaigns created in HoreX Geo Marketing
and restaurant Google Business Profiles. Its IDs belong to that workspace;
never pass them to ordinary Google Ads campaign tools. Open the returned Geo
Marketing source link for its native controls. `query_delivery_geography`
analyses customers and delivery addresses, not advertising campaigns.

Show campaign and account names, current/requested budget and currency,
selected groups and ads, schedule and blockers. The owner opens the returned
exact saved operation link, reviews the final settings, and confirms the change. Query
parameters never authorize execution. Do not invent a default budget or
claim a reviewed campaign has launched. Paused children require explicit
selection; enabled children are preserved and shown.

The operation reader accepts a saved operation ID supplied by HoreX. Preview
awaits owner confirmation. Running/unknown needs a status check in HoreX;
never repeat an uncertain provider write. Confirmed means approved provider
settings match, not proof of delivery, impressions or spend. Failed/stale/
needs_review requires a fresh review. Preserve account and role access.

Meta control supports existing AED campaigns, up to ten ad sets and fifty
ads. Edit existing campaign daily budgets; preserve targeting, creative
content, ad-set/lifetime budgets and schedules. Existing campaign controls preserve targeting and creative content. New Meta
creation uses the complete saved setup flow below.

Ordinary Google Ads control supports existing campaigns, up to ten ad/asset
groups and fifty ads. Performance Max uses `group_

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: catering-review
description: Find and inspect HoreX Catering invoices and quotations by customer, company, document number, branch or event date. Use for catering documents, event billing and their line detail.
---

## State capability limits precisely

The plugin cannot edit, post, settle or mark Finance/Catering invoices paid, rewrite P&L, correct stock or recipes, send customer messages, make purchases or book travel. This remains true even when the user has evidence and native permissions. Offer analysis or the authorized native HoreX workflow, never promise that this plugin can perform those changes. Unsupported mutation requests require no business-data call. Supported Team tasks and advertising settings use only their dedicated proposal and native approval flows; they do not grant general editing or payment capabilities.

## Execute HoreX calls sequentially

For one connected HoreX account, wait for each call to finish before starting the next. Keep the result, source and billing status of each call separately. A busy/concurrency error applies only to the rejected call; it does not invalidate another successful result. Reuse successful results. Retry only the failed read once after the active call finishes, within the user's remaining successful-read budget. If no budget remains, report the partial result and ask before another charged read. Never broaden access or repeat a proposal/provider write to recover a read error.

Catering and Finance are separate customer-document sources. For an explicit Catering request, use list_catering_documents with document_type invoice or quotation. For an unspecified customer invoice search, search Finance and Catering before declaring no match. Supplier purchase invoices belong to another source. A missing Finance match does not establish that a Catering invoice is absent.

## Understand the business document before choosing a tool

| Business source | Meaning in HoreX | Evidence and available tools |
| --- | --- | --- |
| Catering invoice or quotation | A client document for catering/event work, with event date, branch, dishes/products/services and optional links to an operational B2B order. An ordinary invoice can be conducted, creating its own stock consumption. | list_catering_documents and get_catering_document; preserve invoice versus quotation, event date, conduct state and cost coverage. |
| Finance invoice | A customer financial billing document from Finance, with invoice date, due date, lines, VAT and payments. It has a separate identity and lifecycle from Catering. It can also present existing POS receivables. | list_finance_invoices, get_finance_invoice; get_receivables for Finance-only unpaid/overdue summary. |
| Supplier purchase invoice | A supplier's bill and procurement/stock-cost evidence. The restaurant owes a supplier; this is not the client's invoice or customer debt. | Discover purchases in get_analysis_catalog; query_restaurant_data dataset purchases and supplier/product lookup when permitted. Purchase invoice detail is not currently exposed. |
| B2B order | An operational commercial order. It can link to a Catering or Finance document; the linked invoice is a distinct financial document. | Do not infer an invoice exists or was paid from the operational order alone. Direct B2B order detail is not currently exposed. |
| POS order / POS-backed customer invoice | The original sale remains the source. A Catering or Finance invoice may present one or several existing order receivables. | Preserve returned POS provenance and the canonical P&L. Do not add the invoice to its source orders again. |

These distinctions describe business purpose; they are not keyword classification. Both Finance and Catering can contain food lines, charge the same company, show VAT, be sent or paid, or have similar invoice numbers. A dish name, company name, amount, paid status or numeric ID alone does not establish the source. Use the actual returned source/type and the user's 

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: daily-review
description: Prepare HoreX daily restaurant reviews, open saved review cards and subscribe at the user chosen Dubai time. Use for morning briefs and recurring P&L reviews, not unsolicited broadcasts.
---

## State capability limits precisely

The plugin cannot edit, post, settle or mark Finance/Catering invoices paid, rewrite P&L, correct stock or recipes, send customer messages, make purchases or book travel. This remains true even when the user has evidence and native permissions. Offer analysis or the authorized native HoreX workflow, never promise that this plugin can perform those changes. Unsupported mutation requests require no business-data call. Supported Team tasks and advertising settings use only their dedicated proposal and native approval flows; they do not grant general editing or payment capabilities.

## Execute HoreX calls sequentially

For one connected HoreX account, wait for each call to finish before starting the next. Keep the result, source and billing status of each call separately. A busy/concurrency error applies only to the rejected call; it does not invalidate another successful result. Reuse successful results. Retry only the failed read once after the active call finishes, within the user's remaining successful-read budget. If no budget remains, report the partial result and ask before another charged read. Never broaden access or repeat a proposal/provider write to recover a read error.

A daily review uses the canonical HoreX P&L for the previous complete Dubai day. Include revenue, cost of goods sold, accounting profit and the source cost coverage. Invoice COGS is the default; use itemized COGS only when explicitly chosen. Do not rename all COGS as food cost or treat the report as operational sales. Daily events currently cover P&L only. Extra invoice, stock or receivables sections require their own permitted tools and successful reads each cost 1 AI Credit; do not promise those sections in a single scheduled report.

For a one-time report choose get_pnl with explicit dates. Widget view is paused. Present the saved or live facts in a native answer in the current AI application using text and tables, with the exact Open in HoreX source link. The free open_restaurant_workspace tool returns workspace facts.

For recurring delivery, first obtain the user's daily hour and minute in Asia/Dubai, permitted branch or all accessible branches, and any explicit COGS preference. Tell the user that each successfully generated daily P&L costs 1 HoreX AI Credit, failed reads are free, and reopening the same saved review is free. Do not choose a time, activate a subscription or send messages to other people without the user's request. Discover daily_review.ready through events/list and use the host's native event-subscription flow, which supplies its verified callback. Do not invent callback URLs or secrets, use a local automation as a substitute, or claim home-page recommendations are guaranteed.

When a daily_review.ready event arrives, inspect status and period. For ready events call get_daily_review with the exact review_id to open the free dated card. Clearly identify the report as a saved snapshot, preserve its period and COGS basis, and note any settlement_pending status. Do not request get_pnl again just to render that snapshot. An unavailable event has no report figures: explain its message and do not invent values or retry paid reads unless asked. Subscriptions expire with their HoreX connection or configured TTL. Current permissions are rechecked before generation, delivery and opening; reconnect and resubscribe if necessary. Stopping a review uses the host's unsubscribe flow with the same chosen arguments and destination. Never claim a subscription is active until the host confirms it.

Host compatibility: Claude does not support the ChatGPT events extension or MCP resource subscriptions. In Claude, provide on-demand reports and open a saved review only when its ID is already

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: inbox-review
description: Investigate HoreX Inbox in the current AI host using scoped text search, control samples, chronological context and related operational orders, without additional HoreX model or embedding calls by default.
---

## State capability limits precisely

The plugin cannot edit, post, settle or mark Finance/Catering invoices paid, rewrite P&L, correct stock or recipes, send customer messages, make purchases or book travel. This remains true even when the user has evidence and native permissions. Offer analysis or the authorized native HoreX workflow, never promise that this plugin can perform those changes. Unsupported mutation requests require no business-data call. Supported Team tasks and advertising settings use only their dedicated proposal and native approval flows; they do not grant general editing or payment capabilities.

## Execute HoreX calls sequentially

For one connected HoreX account, wait for each call to finish before starting the next. Keep the result, source and billing status of each call separately. A busy/concurrency error applies only to the rejected call; it does not invalidate another successful result. Reuse successful results. Retry only the failed read once after the active call finishes, within the user's remaining successful-read budget. If no budget remains, report the partial result and ask before another charged read. Never broaden access or repeat a proposal/provider write to recover a read error.

# Inbox investigation

Investigate the operational question through permitted episode discovery, control reading and verified outcomes. Current native Inbox permissions and explicit account AI assignments apply before every count, match and excerpt. Private HPanel Inbox is excluded.

## Saved period review — default for weekly investigations

For a requested period/weekly review, resolve the brand/branch then call `start_inbox_review` with those IDs, explicit dates, `topic: issues`, a stable `request_key` and `batch_size: 3`. It already discovers the bounded candidate set, activity gaps and up to two controls, and returns the first chronological batch. Do not repeat overview/search/sample calls before this default path. Reuse the same key if the start response is lost.

Analyze **every** member of the returned batch in this host, then call `continue_inbox_review` with the returned `review_id`, current `revision` and `assessments`. Each assessment supplies case_id, result, outcome, a short summary covering cause/support/outcome, and actual evidence_message_ids from issued text. Allowed results: confirmed_issue, not_issue, other_brand, unresolved, needs_earlier, needs_later. Acknowledging the batch automatically returns the next batch. Keep doing this in the same turn while pending cases/controls remain and the user/read budget permits it. Do not stop after one interesting case or give an orientation answer instead of the requested weekly review.

For a case registered in a saved review, obtain additional context **only through `continue_inbox_review`** with needs_earlier/needs_later and evidence IDs from its issued batch. Do not use `read_inbox_episode` for that case: separately read message IDs are not registered as evidence in the saved review. The standalone episode instructions below apply to targeted investigations outside a saved review. Keep every case_id and its own issued message_id values together; never copy a citation from another case or invent an ID.

Use unresolved when evidence remains insufficient, not an invented resolution. A message packet is not the whole conversation; unresolved, media, clipped text and brand ambiguity remain explicit gaps. A recorded host assessment is not independently validated by HoreX. All retrieved candidates assessed does not mean all complaints found.

If `review_evidence_not_issued` is returned, that call saved no assessments. Replay the current batch with the same review_id/revision and **no assessments**, then use its actu

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: marketing-review
description: Investigate HoreX advertising, acquisition, customer retention, cohorts, RFM, geography, audiences, broadcasts and automation outcomes using permitted live sources.
---

## State capability limits precisely

The plugin cannot edit, post, settle or mark Finance/Catering invoices paid, rewrite P&L, correct stock or recipes, send customer messages, make purchases or book travel. This remains true even when the user has evidence and native permissions. Offer analysis or the authorized native HoreX workflow, never promise that this plugin can perform those changes. Unsupported mutation requests require no business-data call. Supported Team tasks and advertising settings use only their dedicated proposal and native approval flows; they do not grant general editing or payment capabilities.

## Execute HoreX calls sequentially

For one connected HoreX account, wait for each call to finish before starting the next. Keep the result, source and billing status of each call separately. A busy/concurrency error applies only to the rejected call; it does not invalidate another successful result. Reuse successful results. Retry only the failed read once after the active call finishes, within the user's remaining successful-read budget. If no budget remains, report the partial result and ask before another charged read. Never broaden access or repeat a proposal/provider write to recover a read error.

# Marketing investigation

Start with the user's business decision and the free `get_analysis_catalog` marketing coverage. Resolve named brands/branches before querying. Choose the few sources needed for the question; do not fetch every report or every campaign. Each successful business-data call costs one AI Credit. The six customer/CAC tools support current and comparison dates in one call. Each period is at most 92 Dubai business days; lists return at most 50 details. A limited page is not a full total. Catalog permission coverage does not prove accounts are connected or data exists.

## Select the owning facts

- `query_ads_acquisition_metrics`: recorded Meta/Google spend, platform conversions, UTM recognized sales, new-to-brand and new-to-company CAC. Facebook and Instagram are combined as Meta. Advertising data is company-wide; do not allocate it to a branch without evidence.
- `query_blended_acquisition_metrics`: confirmed marketing costs and all new customers irrespective of UTM. State the acquisition scope. Preserve shared/unallocated costs, currency warnings and possible invoice/platform overlap. Do not sum a platform charge and its invoice twice.
- `query_ad_performance`: campaign, ad set or ad detail at one hierarchy level. Match currency and dates, inspect freshness with `get_advertising_status` when missing. Do not sum spend across hierarchy levels. Platform conversions and ROAS are not HoreX recognized orders and revenue.
- `query_customer_metrics`: identified-customer totals, average check, frequency, new, returning and repeat. Repeat means two purchases within the period; returning means an earlier visible purchase followed by a purchase within the period. Distinct customers across branches/months cannot be added. Respect identification coverage and visible history.
  Use `analysis_mode: retention` for complete weekly/biweekly cadence and reactivation counts, `group_by: none`. The cadence lookback defaults to 90 days and accepts 28–180; regularity needs three distinct purchase days, both observed gaps in the stated band and a recent last purchase. Fewer days mean insufficient evidence, not zero regularity. Reactivation compares the first purchase in the period with the last before it (default gap 30 days). Repeat, reactivation and cadence tags can overlap; preserve the reported intersection. State `acquisition_scope`: selected_scope means new/returning in the selected brand/channel/source; visible_organization checks prior purchases across all visible channels/brands while retaining permiss

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: operations-follow-through
description: Turn restaurant analysis into explicitly confirmed native Team tasks and track execution, using Central Kitchen demand, batches and deliveries when relevant.
---

## State capability limits precisely

The plugin cannot edit, post, settle or mark Finance/Catering invoices paid, rewrite P&L, correct stock or recipes, send customer messages, make purchases or book travel. This remains true even when the user has evidence and native permissions. Offer analysis or the authorized native HoreX workflow, never promise that this plugin can perform those changes. Unsupported mutation requests require no business-data call. Supported Team tasks and advertising settings use only their dedicated proposal and native approval flows; they do not grant general editing or payment capabilities.

## Execute HoreX calls sequentially

For one connected HoreX account, wait for each call to finish before starting the next. Keep the result, source and billing status of each call separately. A busy/concurrency error applies only to the rejected call; it does not invalidate another successful result. Reuse successful results. Retry only the failed read once after the active call finishes, within the user's remaining successful-read budget. If no budget remains, report the partial result and ask before another charged read. Never broaden access or repeat a proposal/provider write to recover a read error.

# From evidence to follow-through

1. Establish the concrete problem, location, dates, evidence coverage and goal. Preserve quality and stockout constraints. Observations and suspected causes are different.
2. Check `list_team_tasks` for existing work. Read `get_team_task` to follow an existing task and its current assignees, deadline, comments and activity. Private tasks, project roles, active membership and feature permissions apply.
3. Use `get_team_workspace` to resolve the exact eligible assignee and optional existing project. Search a person by name when the directory is partial. A project observer cannot be assigned. Never add project members or select an invented ID.
4. When the user wants action, call `prepare_team_task` with one concrete task, exact assignee, due date, acceptance criteria, evidence-based baseline and optional branch/project. State any causal uncertainty in the description. Do not put unrelated private information into a task that will be shared with its audience.
5. This returns an immutable, expiring proposal. Show the returned review link and summarize the work, assignee, deadline, audience and expected verification. No task exists yet and no assignee has been notified. Only the proposing user can confirm the exact proposal in the authenticated HoreX page. The server rechecks native permissions, branch context, project role and assignee eligibility, then creates one native task atomically. Retries do not duplicate it. There is no model-accessible commit method.
6. Track the resulting native task via `get_team_task`, including comments and activity. Request fresh operational data for the agreed baseline/follow-up period and evaluate the acceptance criteria. Done means staff execution; it does not establish lower food cost, profit or causation. Keep missing evidence explicit. No autonomous task edits, stock posting, purchasing, production completion or customer messages.

# Central Kitchen evidence

Resolve `get_central_kitchen_workspace` first, then use the selected kitchen/date with `get_central_kitchen_day`. Orders use the selected delivery day; outstanding deliveries and unfinished older production are explicitly included separately. Read one `get_central_kitchen_item` for demand and allocations by branch, stock availability, production batches, output reconciliation, recipe and current estimated cost. Exact `get_central_kitchen_order` and `get_central_kitchen_delivery` preserve the original document and quantities.

Branch users can see their permitted orders/deliveries. In

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: procurement-review
description: Compare restaurant supplier spend, purchased quantities and weighted prices using HoreX procurement facts. Use for purchasing reviews and price-increase investigations.
---

## State capability limits precisely

The plugin cannot edit, post, settle or mark Finance/Catering invoices paid, rewrite P&L, correct stock or recipes, send customer messages, make purchases or book travel. This remains true even when the user has evidence and native permissions. Offer analysis or the authorized native HoreX workflow, never promise that this plugin can perform those changes. Unsupported mutation requests require no business-data call. Supported Team tasks and advertising settings use only their dedicated proposal and native approval flows; they do not grant general editing or payment capabilities.

## Execute HoreX calls sequentially

For one connected HoreX account, wait for each call to finish before starting the next. Keep the result, source and billing status of each call separately. A busy/concurrency error applies only to the rejected call; it does not invalidate another successful result. Reuse successful results. Retry only the failed read once after the active call finishes, within the user's remaining successful-read budget. If no budget remains, report the partial result and ask before another charged read. Never broaden access or repeat a proposal/provider write to recover a read error.

Use get_analysis_catalog to confirm the purchases measures and filters. Resolve a product or supplier with find_restaurant_entities using the user's wording plus a translation or alternate spelling if useful. Return ambiguity to the user when multiple plausible products remain; preserve the product's unit and code.

Query purchases with explicit current and baseline Dubai dates. Group by product, supplier and uom as appropriate; filter line_kind to stock_product for ingredient or goods analysis. Without that filter the source may include non-stock service or rent lines. Procurement facts cover posted itemized purchase lines, so describe missing drafts or unitemized coverage rather than treating them as zero purchases.

Use net_amount, quantity and avg_unit_price together. Weighted price is net amount divided by purchased quantity within a compatible unit; never average displayed invoice prices or combine kilograms, pieces and boxes. Compare like-for-like product and unit. A supplier's changing mix can alter aggregate average price without a price change for an individual item.

Separate higher volume from higher price and changed product mix. Flag new and discontinued purchasing rows, missing baselines and truncated rows. Exact totals precede the row limit; the displayed products may cover only part of them. Rank price changes only among comparable rows and disclose that population.

Present material increases, their amount, supplier, product and unit, followed by focused verification steps such as checking specific purchase invoices in HoreX. Purchases are spending facts, not automatically consumed food cost; confirm profitability with get_pnl and retain its COGS basis. Do not claim that negotiations or purchase-order changes have been executed.

Native output: widget view is paused. Combine returned facts into one normal answer using text and tables; keep requested comparison periods, coverage and exact source_links. Reading already returned facts is free. Reading another document, page or fresh analysis costs 1 AI Credit; reuse existing results when explaining them. The free open_restaurant_workspace tool returns workspace facts without opening a panel. For daily subscription setup load daily-review guidance.

View saved version →

---
name: profit-improvement
description: Investigate restaurant profit, food cost and missed opportunities across branches, with or without an explicit improvement target. Use for reducing food cost, improving network profitability and finding relationships between operating facts.
---

## State capability limits precisely

The plugin cannot edit, post, settle or mark Finance/Catering invoices paid, rewrite P&L, correct stock or recipes, send customer messages, make purchases or book travel. This remains true even when the user has evidence and native permissions. Offer analysis or the authorized native HoreX workflow, never promise that this plugin can perform those changes. Unsupported mutation requests require no business-data call. Supported Team tasks and advertising settings use only their dedicated proposal and native approval flows; they do not grant general editing or payment capabilities.

## Execute HoreX calls sequentially

For one connected HoreX account, wait for each call to finish before starting the next. Keep the result, source and billing status of each call separately. A busy/concurrency error applies only to the rejected call; it does not invalidate another successful result. Reuse successful results. Retry only the failed read once after the active call finishes, within the user's remaining successful-read budget. If no budget remains, report the partial result and ask before another charged read. Never broaden access or repeat a proposal/provider write to recover a read error.

Preserve the owner's goal, branch/brand scope, horizon and constraints. A request to reduce food cost from 32% to 27% means a 5 percentage point target, not an instruction to change purchasing or recipes. Verify the baseline and its cost basis first. Dates use Asia/Dubai; prefer complete, comparable periods. Ask only for missing constraints that materially affect the investigation.

Read the free get_analysis_catalog to check available analyses. For overall profitability, start with get_profit_review for canonical current and baseline P&L, expense breakdowns, a reconciled profit bridge and investigation candidates. Both periods together cost 1 AI Credit. Omitted comparison dates use the preceding equal-length period. Branch sales/gross profit are not complete branch net profit: use a branch-scoped P&L before ranking net profitability. Preserve invoice versus itemized cost bases; posted purchases minus recipe-based consumption is not measured waste.

For food cost, use get_food_cost_drivers. Preserve the returned historical-cost coverage and covered-revenue denominator. Known sold-line historical cost and current recipe reconstruction using historical purchase prices have different evidential strength. Missing costs are unknown, not zero. Use get_recipe_economics for affected dishes or prep to examine current ingredients, yield and missing cost. Resolve named brands/branches before passing their IDs. Query purchases only where product and unit compatibility allow a useful supplier/price comparison. A cheaper historical supplier is not a current quote, available stock or an approved quality-equivalent substitute.

Choose targeted follow-up reads that distinguish explanations. Each successful data tool costs 1 AI Credit; reuse already returned facts for formatting and reasoning. Do not run every available analysis just because the user asked a broad question. Inspect source links for the exact report scope when a manual review is useful.

For opportunity discovery, follow an observed signal across sources: purchase price to dish exposure and sold mix; discount or aggregator mix to contribution; branch demand to comparable cost intensity. Separate an observed association, a hypothesis, a conditional forecast and a measured result. Check volume, mix, trading-day and purchase-timing explanations before implying causation. Rank findings with the observed amount, source, formula, missing evidence, proposed next step and outcome metric. C

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: receivables-review
description: Review unpaid or overdue customer Finance invoices and outstanding balances from HoreX. Use for receivables, customer debt and collection priorities, not supplier payables.
---

## State capability limits precisely

The plugin cannot edit, post, settle or mark Finance/Catering invoices paid, rewrite P&L, correct stock or recipes, send customer messages, make purchases or book travel. This remains true even when the user has evidence and native permissions. Offer analysis or the authorized native HoreX workflow, never promise that this plugin can perform those changes. Unsupported mutation requests require no business-data call. Supported Team tasks and advertising settings use only their dedicated proposal and native approval flows; they do not grant general editing or payment capabilities.

## Execute HoreX calls sequentially

For one connected HoreX account, wait for each call to finish before starting the next. Keep the result, source and billing status of each call separately. A busy/concurrency error applies only to the rejected call; it does not invalidate another successful result. Reuse successful results. Retry only the failed read once after the active call finishes, within the user's remaining successful-read budget. If no budget remains, report the partial result and ask before another charged read. Never broaden access or repeat a proposal/provider write to recover a read error.

First identify the source. get_receivables covers Finance invoices only; it does not summarize Catering debt. For Catering invoices or quotations use the catering-review workflow, list_catering_documents and get_catering_document. For an unspecified customer invoice search check both Finance and Catering before reporting no match. For combined customer debt state the Finance-only summary boundary and do not label it the complete HoreX balance.

For ambiguous customer documents, load get_horex_workflow with workflow catering-review: it contains the shared business map of Finance, Catering, supplier bills, B2B orders and POS-backed invoices. The user's explicit module choice and later corrections take priority over the conversation's previous source. Do not infer a module from food lines, customer name, invoice number or paid status alone. Read the free catalog's document_sources: denied or unavailable sources are not verified empty sources. Customer debt, invoice issued value, received cash, recognized revenue and conducted-event cost are different metrics.

Use get_receivables with scope unpaid for outstanding Finance balances or overdue for balances past the due date. Omit dates for the all-date visible balance. When dates are supplied, they filter invoice date; due date determines overdue status. Do not silently substitute a recent period for an all-time debt question.

Read summary.outstanding_value and matching_documents for the whole matching visible population. The records list is limited to 100; coverage.truncated and returned_rows state its completeness. It is ordered by invoice date, so the first records are not automatically the largest or most urgent debts. Owner-only visibility and permitted branches can constrain the summary; describe the returned coverage accurately.

Finance invoices are customer billing documents. Their issued value, recorded payments and outstanding amount differ from recognized revenue. Quotations are proposals, and supplier purchase invoices are payables; neither belongs in this receivables balance. Do not derive an all-time total from list_finance_invoices, which returns only recent matching documents.

Use get_finance_invoice to inspect a particular visible invoice when the user needs line detail. Preserve invoice number, customer/company, dates, total, paid and outstanding amounts. Do not invent contact details, bank information or payment links. Do not calculate full aging-bucket totals or per-customer rankings from a truncated list.

Present the visible bal

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: restaurant-review
description: Review restaurant sales, menu demand and profit using live HoreX facts. Use for operating reviews, period comparisons and explanations of changing sales or margin.
---

## State capability limits precisely

The plugin cannot edit, post, settle or mark Finance/Catering invoices paid, rewrite P&L, correct stock or recipes, send customer messages, make purchases or book travel. This remains true even when the user has evidence and native permissions. Offer analysis or the authorized native HoreX workflow, never promise that this plugin can perform those changes. Unsupported mutation requests require no business-data call. Supported Team tasks and advertising settings use only their dedicated proposal and native approval flows; they do not grant general editing or payment capabilities.

## Execute HoreX calls sequentially

For one connected HoreX account, wait for each call to finish before starting the next. Keep the result, source and billing status of each call separately. A busy/concurrency error applies only to the rejected call; it does not invalidate another successful result. Reuse successful results. Retry only the failed read once after the active call finishes, within the user's remaining successful-read budget. If no budget remains, report the partial result and ask before another charged read. Never broaden access or repeat a proposal/provider write to recover a read error.

Anchor the review to the user's restaurant, branch and period. Dates use Asia/Dubai. Resolve relative dates from the current date; yesterday is a complete day and today may be incomplete. Ask when the intended period cannot be inferred. Each period is limited to 92 days; split longer requested periods explicitly and disclose the extra calls.

For profit improvement, food-cost targets or missed-opportunity discovery, load get_horex_workflow workflow profit-improvement. It combines canonical P&L diagnostics, historical food-cost drivers and current recipe economics while preserving evidence gaps and the owner's constraints.

Choose the source for the question. get_pnl is the canonical restaurant P&L, including accounting bridges and the selected COGS basis. get_sales_summary uses that same source. query_restaurant_data with dataset sales analyzes operational orders by day, weekday, hour, branch, brand, service channel, order source, discounts or payment method. It is not the entire accounting revenue bridge. Query sales_items for sold dishes or categories when the catalog makes these available. Menu monetary measures need the corresponding HoreX report access.

For how many tables are seated now, current floor occupancy, who serves a table, seating duration or printed pre-checks, use get_live_tables without historical dates. Preserve the permitted network for a network question; Staff-only access is bound to its trusted branch. Use summary.occupied_tables/free_tables/unknown_tables and by_branch, not the displayed row count. For "over an hour" use status occupied and min_duration_minutes 60, then use coverage.matching_tables for the matching count. Summary remains the full visible location before status/duration/page filters. Pages are fresh snapshots and may change between calls; avoid silently summing them. Rows are longest-duration first; disclose truncation and use table_id/hall_id for focused follow-ups. Each new read/page costs 1 AI Credit.

Use server as_of and explain freshness. duration_basis reservation_seated_at is saved seating; order_opened_at is a proxy and must be labelled as time since the check opened, not an exact guest arrival. Include seated reservations without orders and older still-open checks. Unknown duration remains unknown, including future timestamps. Multiple checks count as one physical table and their combined guests are unknown. Recorded guest counts are not a physical headcount; use tables_with_guest_count coverage before giving a guest total. Tables managed by an offline term

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: setup
description: Connect the HoreX restaurant plugin and check access, connection status and AI Credit billing. Use for setup and reconnection, not business analysis.
---

## State capability limits precisely

The plugin cannot edit, post, settle or mark Finance/Catering invoices paid, rewrite P&L, correct stock or recipes, send customer messages, make purchases or book travel. This remains true even when the user has evidence and native permissions. Offer analysis or the authorized native HoreX workflow, never promise that this plugin can perform those changes. Unsupported mutation requests require no business-data call. Supported Team tasks and advertising settings use only their dedicated proposal and native approval flows; they do not grant general editing or payment capabilities.

## Execute HoreX calls sequentially

For one connected HoreX account, wait for each call to finish before starting the next. Keep the result, source and billing status of each call separately. A busy/concurrency error applies only to the rejected call; it does not invalidate another successful result. Reuse successful results. Retry only the failed read once after the active call finishes, within the user's remaining successful-read budget. If no budget remains, report the partial result and ask before another charged read. Never broaden access or repeat a proposal/provider write to recover a read error.

Use get_profile to check the connected HoreX account and selected restaurant. A successful check is free. If authentication fails, use the host's Connect or Reconnect action and let the user complete HoreX sign-in and consent. Never ask for passwords in chat.

The current pilot is available to Locus. Access also requires the separate Use ChatGPT Plugin permission and the permissions for the requested business data. An unavailable dataset is a permission or configuration boundary; ask an authorized HoreX administrator to review access.

Every successful business-data tool call costs 1 HoreX AI Credit. Profile, catalog, workflow guidance, authentication and failed requests are free. Use get_analysis_catalog to discover the available datasets before composing an analytical query. Use get_horex_workflow to load the relevant business playbook when packaged skills are unavailable in the host.

Report the actual connected account, capabilities and any reconnect requirement. Do not call a restaurant connected merely because the ERP Integrations card says the pilot is ready. Credit balances and usage are in HoreX Subscription / AI account and HPanel AI Usage. Do not invent OpenAI provider-token usage.

Campaign preparation uses campaign-launch and its dedicated Meta / ordinary Google Ads tools. If those tools are absent while the account connects successfully, refresh the existing App's tool catalog in ChatGPT before diagnosing restaurant permissions. Report a refresh failure accurately; do not promise that an unavailable command can execute.

View saved version →

---
name: stock-investigation
description: Investigate negative stock, unusual movements and warehouse discrepancies using native physical stocktakes, late documents and ledger facts. Use for stock diagnosis, not record corrections.
---

## State capability limits precisely

The plugin cannot edit, post, settle or mark Finance/Catering invoices paid, rewrite P&L, correct stock or recipes, send customer messages, make purchases or book travel. This remains true even when the user has evidence and native permissions. Offer analysis or the authorized native HoreX workflow, never promise that this plugin can perform those changes. Unsupported mutation requests require no business-data call. Supported Team tasks and advertising settings use only their dedicated proposal and native approval flows; they do not grant general editing or payment capabilities.

## Execute HoreX calls sequentially

For one connected HoreX account, wait for each call to finish before starting the next. Keep the result, source and billing status of each call separately. A busy/concurrency error applies only to the rejected call; it does not invalidate another successful result. Reuse successful results. Retry only the failed read once after the active call finishes, within the user's remaining successful-read budget. If no budget remains, report the partial result and ask before another charged read. Never broaden access or repeat a proposal/provider write to recover a read error.

For physical inventory discrepancies, shortages/surpluses, “last inventory” or comparison between counts, call get_inventory_investigation. Submitted unposted tasks are real physical counts; a missing stock movement never proves that a count does not exist. With no session select from permitted physical-task candidates. Preserve the selected session_id, warehouse_id, branch_id and previous_session_id when the user says “now salmon/cheese”; only the product changes. Never silently substitute another branch, all warehouses or arbitrary dates. If the selected product is absent from that task, state this and ask/select another physical task explicitly.

With session_id and no item, review the full shortage/surplus totals and bounded queue sorted by absolute AED; do not compare kilograms against pieces. Then investigate the material product/count rows. Explain direct physical quantity, reviewer correction, analytics-only Prep raw equivalent, native expected and variance separately. An uncounted row, Not found and counted zero differ. Posted variance is immutable; subsequent backdated influence is a separate historical reconciliation.

The server certifies record arithmetic, not physical causation. Preserve reconciliation residual, exact opening effect, native-versus-ledger gap, evidence truncation and coverage. Explain a late document with its business time, posting time and exact quantity; ask whether the physical receipt/event happened before or after the observation. Do not label a technical inventory-boundary compensation as spoilage. A nearby transfer, matching quantity, employee or supplier correlation is a hypothesis. Missing historical units, recipe attribution, legacy identity or permitted documents stay explicitly unverified. User testimony is an operational claim to corroborate; never describe it as a ledger correction. Use the exact source_links for the task/count/invoice.

For current stock or generic movement questions, confirm the branch, warehouse and item. Use find_restaurant_entities for product or warehouse names and preserve compatible units. get_stock_balances is a current physical snapshot; a negative-only filter isolates immediate exceptions. Do not label physical balances as purchasing quantities, accounting COGS or theoretical recipe consumption.

For causes, use query_restaurant_data on stock_movements with explicit Dubai dates and a product filter. Group by movement type, warehouse, branch, uom or day using catalog codes. Stock-history access is required sep

Preview of the first 4,000 characters. Read full instructions →