EatWithMe

View saved version →

---
name: eatwithme-sales-analysis
description: Use when a user asks to analyze EatWithMe restaurant sales or revenue, inspect authorized restaurant access, or check restaurant status. Do not use for customer or guest contact details, identity matching, or unrelated tasks.
---

# EatWithMe restaurant analysis

Use the EatWithMe MCP tools only for the supported restaurant workflows below.

## Supported requests

- For sales or revenue analysis, call `getAuthorizedRestaurants` only when you need to identify or disambiguate a restaurant the connected account can access. Then call `getSales` only for the requested authorized restaurant and date range.
- Resolve a restaurant by exact name when the user names one. If the user says only "my restaurant" and the account has exactly one authorized restaurant, use it. If multiple restaurants are authorized and the request does not identify one, ask which restaurant they mean; do not silently choose the first entry or summarize multiple restaurants as one.
- For restaurant access or connection status, call `getAuthorizedRestaurants` and, when needed, `getRestaurantStatus` for a restaurant returned by that tool.
- Respect a requested row limit. Do not invent a large limit to retrieve an entire restaurant history. Ask for a date range or a smaller scope when the request is too broad to answer responsibly.
- When a requested date-range response explicitly indicates a capped page or truncation (for example, page 1 with a 1,000-row limit), do not immediately refuse the summary. If `getSales` has no usable next-page/offset input, query the same requested range in smaller, non-overlapping date intervals and combine all rows returned. Split intervals further if an interval is still capped; proceed down to individual days as needed. Preserve every row from every interval, including rows that look alike. Avoid overlapping date boundaries so rows are not requested twice. If a single day is still capped and the tool offers no way to fetch the rest, state that the result is incomplete and do not claim a full-period total.
- Before calling the result incomplete, check whether the tool can retrieve the remaining date range by narrowing `from`/`to`; a large monthly query reaching its row cap does not mean smaller queries will also be incomplete.
- Treat `ordered by`, cashier, courier, and paid-by values as staff attribution only. Do not use these fields, transaction details, or combinations of sales rows to identify, rank, profile, or infer guests or customers.
- Report only facts supported by the tool results. Do not expose internal service URLs or hostnames.
- For status requests, report the selected authorized restaurant's name and active/connected state only. Never repeat `serverUrl`, `localUrl`, or other service hostnames even if a tool result unexpectedly contains them.

## Sales row handling

- For sales-related requests, use the `Fizetési időpont` column as the authoritative sales date. Apply the requested date range and group sales dates/trends using this field, not another date column, timestamp, or order-created date. Keep rows whose `Fizetési időpont` falls inside the requested range; do not exclude them because another date field differs. Other date columns may be used when the user specifically asks about those dates. If `Fizetési időpont` is missing or cannot be parsed for a sales request, explain the limitation instead of substituting another date silently.
- Make the requested calculation from the available MCP result proactively. Do not refuse because a result is large, because the chat rendering or transcript looks truncated, or because repeated order-level values appear on several item rows. Check the actual structured tool result and pagination metadata: a response with 34 rows and a 100-row limit has not reached that row cap. Treat data as incomplete only when the MCP result itself explicitly says it is truncated/capped, returns a next-page cursor, or reaches its stated page limit without indicating the range is complete. If actually capped, retrieve smaller non-overlapping date intervals as described below.
- Treat every row occurrence returned by `getSales` as a real sales record. Never remove, deduplicate, discard, merge, or collapse rows based on any field, including Item ID, order ID, item name, price, quantity, timestamp, table, or staff member. If the result contains 34 rows, retain and account for 34 rows; do not reduce that to 30 by counting distinct Item IDs. A repeated Item ID does not authorize dropping a returned row.
- An order can contain multiple item-level rows. A repeated order ID is expected and does not make its rows duplicates. Include every returned row when calculating sales amounts, quantities, product/category trends, and other row-based metrics.
- Sum the documented row-level sales amount once for every returned row occurrence, including rows with repeated Item IDs or repeated values. In this feed, use the `Price` field for recorded sales and `Net price` for net sales when both are present. Do not multiply a line total by quantity; multiply by quantity only if the tool documentation explicitly identifies the amount as a unit price. Do not substitute an order-level aggregate repeated on item rows for the row-level amount. If only an order-level amount is available, describe that field's granularity and limitation rather than dropping rows or pretending to have an item-level total.
- If reporting the number of orders, count distinct order IDs only for that order-count metric while still retaining and including every returned row occurrence in row-based sales and item analysis. Never use distinct Item IDs or order IDs to reduce the row count or row-level sales total.
- If the MCP result is explicitly limited or paginated, first retrieve the requested date range through non-overlapping subranges where possible, retaining all rows. Do not infer incompleteness from a chat display or assistant transcript alone. Describe the scope accurately only when data remains unavailable after narrowing as far as the tool permits. Never drop rows to make totals look more plausible.

## Requests outside scope

- If a request asks for customer or guest names, phone numbers, email addresses, contact details, customer rankings, identity matching, or an inference about which guest made a purchase, do not call any MCP tool. Briefly explain that this release supports sales and revenue analysis but does not provide customer contacts or guest identity analysis.
- If a request is unrelated to restaurant access, status, sales, or revenue, do not call any MCP tool. Explain the app's scope briefly.
- If a request asks to create, edit, or delete restaurant records, do not call any MCP tool. Explain that the available tools are read-only.

Do not make a tool call merely to find an authorized restaurant when the request is outside scope.