ADECI

Fetch ADECI's stored SHAP feature importance and explain why a revenue or client forecast has its predicted value. For a combined forecast-and-explanation request, use this tool as the sole forecast source and do not also call execute_metrics_query for the same metric and dates. Never invent a reason for a difference between forecast sources. Use when the user asks why, what drives, what increases/decreases, or requests justification for a forecast. Returns the authoritative explained prediction, ranked positive and negative drivers, grounded calendar evidence, model versions and a concise explanation. Product SHAP explanations are not currently available.

explain_forecast

List every restaurant available to the authenticated ADECI user, including exact restaurant IDs, first/last available sales dates, and which restaurant is currently selected. Use this to resolve a restaurant name or historical coverage before calling another tool. Based on data recency, the latest available sales date may be the reference date for named historical periods.

list_restaurants

Query external factors that can impact restaurant performance from ADECI's calendar, including weather, holidays, local events, strikes, sports fixtures, and movies. Use this tool for event-calendar questions, external context for a period, or possible external sales-impact drivers. Results are read-only and scoped to a restaurant available to the authenticated user.

query_external_factors

Execute a metrics query against the ADECI backend API. Fetches sales and forecast data by selecting a metric and optional grouping dimensions. Use for direct data retrieval: revenue, units, clients, tickets, discount, cancellation. Pass ordinary named historical periods such as last_week and last_month unchanged; do not translate them into wall-clock ISO dates. ADECI resolves them from the selected restaurant's sales reference date, which may be its latest available sales date based on data recency, and returns the exact effective dates in data.metadata. Comparison periods previous_week and previous_month are resolved relative to the main period. Historical revenue, units, clients, and tickets can be broken into bounded 10-, 15-, 20-, or 30-minute intervals. Sub-hourly chronological output preserves dates and is limited to 1,008 potential buckets; time-of-day profiles collapse recurring clock slots and support up to 400 inclusive days. For sub_hourly use explicit start/end dates, source='sales', and no grouping, filters, comparison, ranking, or objectives. The shared client normalizes explicit sub-hourly dates to the authenticated restaurant's known sales bounds and reports that adjustment. Use covered_calendar_day_count only as a calendar-day denominator. Buckets contain whole eligible checks attributed by sale opening time, not revenue accrued during the interval. A zero may be an unobserved bucket or an observed net zero and does not distinguish closure, zero demand, returns/offsets, or missing imports. Opening-time results are descriptive, not causal or proof of profit. Supports multi-dimensional grouping via `group_by` array, including product taxonomy groupings, filtering, comparison, and ranking (top-N / bottom-N). The backend resolves the data source (sales vs forecast) from the timeframe automatically — use `source` only when you need to override this behaviour. Discount and cancellation are historical sales metrics only. Call search_catalog first when the query involves specific products, ingredients, families, or subfamilies.

execute_metrics_query

Search the restaurant's product or ingredient catalog to resolve natural-language names into exact catalog IDs, families, or subfamilies. MUST be called BEFORE a metrics or KPI query whenever the query involves specific products, ingredients, families, or subfamilies. Use the returned IDs or family names to build filters entries (e.g. {"field": "product.id", "op": "in", "value": [<ids>]}) in subsequent tool calls.

search_catalog