Free restaurant profit check, recipe costing, calculators, website check, deadlines, guides, blog.
Scored across 21 tools
Each tool maps to a distinct calculator or knowledge operation, and the descriptions carefully distinguish close pairs such as cost_recipe (draft ingredient pricing) versus plate_cost (final plate cost and menu price). The main risk is that 21 adjacent financial calculators (prime cost, labor cost, budget, break-even, restaurant_budget) require reading long descriptions to select correctly, so some ambiguity remains.
All names use a consistent restaurantdoctor_ prefix and snake_case, which makes the set predictable and readable. However, most calculator tools are noun phrases (prime_cost, tip_out, par_levels) while knowledge and action tools use verb_noun (list_knowledge, read_knowledge, run_free_check), so it is not a fully uniform verb_noun convention.
The 21 tools are each distinct and purposeful, but the count is heavy for a calculator-and-knowledge server and falls into the borderline 16–25 range. The breadth is justified only if all calculators are truly needed, which makes the surface feel somewhat oversized.
The surface covers a broad restaurant finance and operations domain: cost, pricing, labor, fees, budgets, cash handling, deadlines, website checks, and sourced knowledge. Minor gaps remain around saved restaurant profiles/history, vendor or invoice workflows, and employee scheduling, but those may be intentionally outside scope.
Works out what a US restaurant's reservation app costs it, as the free booking fee check on restaurantdoctorai.com does: a month, a year, per guest who booked through it and as a share of the average spend, from the plan's published price (dated, sourced) or the owner's invoice, plus fees per guest and the percentage on deposits. Of the apps checked, only OpenTable charges per guest: for guests from its own app and website, possibly from Google and partners, and on Basic from the restaurant's own website. Returns a one-sentence headline first, the month line by line, what isn't counted, what the owner can do (book direct, mark no-shows, the contract's notice date), other apps' published prices as information, not a recommendation, the caveats and sources. It answers what OpenTable, Resy, Tock, Yelp, Toast Tables, SpotOn or SevenRooms costs a restaurant per reservation or per guest. It needs the app and plan (on the invoice) and, for OpenTable, last month's guests from its covers report by where they booked; the rest is optional. A figure that isn't sent is never counted as 0. Not affiliated with any app; it reads no account. The figures aren't stored; only an anonymous daily count of calculator runs is kept.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | Yes | The app and plan, on the invoice. tock_ = Tock, now sold by Resy; other = any app not listed, with monthlyFee. | |
| firstMonth | No | ||
| monthlyFee | No | ||
| renewalDate | No | ||
| averageSpend | No | ||
| networkCovers | No | ||
| partnerCovers | No | ||
| prepaidAmount | No | ||
| websiteCovers | No | ||
| networkCoverFee | No | ||
| partnerCoverFee | No | ||
| websiteFlatAddOn | No | ||
| prepaidFeePercent | No |
| Name | Required | Description |
|---|---|---|
| asOf | Yes | The day prices were read. |
| link | Yes | Opens the check with these figures. |
| name | Yes | The plan. |
| year | Yes | |
| month | Yes | US dollars, like every amount. |
| notes | Yes | |
| result | Yes | |
| caveats | Yes | |
| feeFrom | Yes | |
| ofSpend | Yes | |
| partial | Yes | True when the headline says at least. |
| sources | Yes | |
| headline | Yes | The result in one sentence. |
| noticeBy | Yes | |
| perGuest | Yes | |
| breakdown | Yes | The month. |
| freeCheck | Yes | |
| workedOut | Yes | |
| firstMonth | Yes | |
| notCounted | Yes | |
| alternatives | Yes | Other apps' monthly prices: information, not a recommendation. |
| whatYouCanDo | Yes | |
| ifBookedDirect | Yes | |
| perNetworkGuest | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds real value beyond them: it is not affiliated with any app, reads no account, stores no figures, and keeps only an anonymous daily run count. It also discloses the output shape (one-sentence headline, month line by line, what isn't counted, caveats and sources) and that it is informational, not a recommendation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose and required inputs are front-loaded, which is good, but the body is a dense, comma-spliced run-on that mixes output format, caveats, coverage list, input requirements and privacy notes into a single block. Given the tool's complexity some length is justified, but the packing makes it harder to scan than it needs to be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be spelled out, yet the description still sketches them. Combined with the input requirements, the missing-value rule, the source/caveat disclosure and the privacy statement, an agent has enough to call this correctly for a 13-parameter calculator. The only shortfall is coverage of the less-common optional fee parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 13 parameters and very low reported schema coverage, the description has to carry weight, and it does partially: it names platform as the required input, states that OpenTable needs last month's guests by booking source, that sevenrooms/other need monthlyFee, that the rest is optional, and that a missing figure is never treated as 0. It does not add per-field semantics for the remaining fields (renewalDate, prepaidAmount, prepaidFeePercent, the various fee overrides), leaving those to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: it computes what a US restaurant's reservation app (OpenTable, Resy, Tock, Yelp, Toast Tables, SpotOn, SevenRooms) costs per month, per year, per guest and as a share of average spend. That scope is clearly distinct from siblings like restaurantdoctor_card_fees or restaurantdoctor_delivery_price, so an agent can route without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives the use context (reservation-app cost analysis, mirroring the free check on restaurantdoctorai.com) and lists which apps it answers for, which implies when to reach for it. But it never names an alternative tool or an explicit when-not condition, so selection against the other 20 restaurantdoctor tools is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Works out a restaurant's break-even sales from the owner's figures for one typical month, as the free break-even calculator on restaurantdoctorai.com does: the sales a month needs to pay every bill, also a week, a day open and guests a day; how far the month was above or short of it; what was left over after every bill; what a point of cost moves it by; with and without the owner's own pay; and if prices were 10% lower or higher (an illustration). Hourly pay can rise with sales or stay fixed, or both ways as a range. Takes the month's figures in any currency; a figure not sent is never counted as 0. Returns the result, the working and a link that opens the calculator with the figures in. The figures aren't stored; only an anonymous daily count of calculator runs is kept.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | No | ||
| sales | No | ||
| hourly | No | unsure | |
| ownerPay | No | ||
| hourlyPay | No | ||
| purchases | No | ||
| fixedBills | No | ||
| daysPerWeek | No | ||
| averageSpend | No | ||
| closingStock | No | ||
| openingStock | No | ||
| otherVariable | No |
| Name | Required | Description |
|---|---|---|
| link | Yes | Opens the calculator with these figures. |
| notes | Yes | |
| checks | Yes | Figures that look like a slip. |
| hourly | Yes | |
| result | Yes | The page's result, line by line. |
| whatIf | Yes | |
| figures | Yes | A month, in the currency of the figures sent. |
| leftOver | Yes | Left over after every bill and ownerPay at these sales, before income tax: below 0 when short. Not profit. |
| standing | Yes | Net sales against break-even (at: almost exactly; never: no break-even either way). |
| freeCheck | Yes | |
| scenarios | Yes | Hourly pay one way, or both (rising first). |
| workedOut | Yes | How it was worked out. |
| daysAMonth | Yes | |
| pointValue | Yes | 1% of sales: what a point of cost saved leaves a month. |
| usedStockCounts | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower; the description still adds real context by disclosing currency-agnostic input, that a missing figure is never counted as 0, that the reply returns result + working + a deep link, and that figures are not stored (only an anonymous daily run count). Only light gaps remain, e.g. no note on output format beyond 'the working'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded and every clause carries content, but the body is a single dense run of semicolon-joined clauses ('also a week, a day open and guests a day; how far...; what was left over...; what a point of cost moves it by...') that is hard to scan, and the reference to 'the free break-even calculator on restaurantdoctorai.com' is low-value framing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter computation the description is broadly complete: it explains the model, the variability assumption, currency handling, missing-figure behavior, and data retention, and an output schema exists so return values need not be spelled out. The main omission is any statement of which figures are required versus optional, which the agent must recover from the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The reported schema description coverage is low, so the description would need to compensate; it adds model-level meaning (any currency, missing ≠ 0, hourly pay that rises, stays fixed, or both) but never maps to individual parameters like goal, ownerPay, openingStock/closingStock, otherVariable. The schema itself nonetheless carries very detailed per-parameter text, so the description and schema jointly cover most semantics, landing at minimum-viable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('works out a restaurant's break-even sales') and enumerates the scope precisely: month/week/day/guests, variance to break-even, profit left over, cost sensitivity, with/without owner pay, and ±10% price illustration. An agent can tell this apart from siblings like restaurantdoctor_restaurant_budget or restaurantdoctor_prime_cost without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a rich account of what the calculator produces and implicitly when it applies (owner has one month of figures and wants break-even), but never states when to prefer this over alternative tools such as restaurantdoctor_run_free_check, restaurantdoctor_restaurant_budget or price/menu tools, nor any exclusions. Usage is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks a US restaurant's card processing fees for one month, as the free card fees check on restaurantdoctorai.com does: the cost per 100 dollars of card sales (the effective rate), against a dated fair range for that type of restaurant (an estimate of a competitive interchange-plus account from Visa's published restaurant interchange, network fees and a fair markup); how far above it the fees are, a month and a year; how they compare with Square's, Toast's, Clover's or Stripe's published rate; what's realistic for that processor, words to read out to it, the fees to question on the statement by name, and the caveats. It answers whether card fees are too high, what the effective rate is, and what to ask the processor. It needs the month's total card sales and total card fees from the processor's statement (every fee, monthly and annual ones included), who processes the cards and what kind of restaurant it is; the number of card sales or the average sale narrows it. A figure that isn't sent is never counted as 0. It doesn't read statements, contact a processor or take payment. Returns the result, how it was worked out, and a link that opens the same check with the figures filled in. The figures aren't stored; only an anonymous daily count of calculator runs is kept.
| Name | Required | Description | Default |
|---|---|---|---|
| format | Yes | The type of restaurant, which sets the likely mix of debit and credit cards: quick_service = Quick service (Counter or kiosk, fast turnover); fast_casual = Fast casual (Order at the counter, food brought to the table); full_service = Full service / casual dining (Servers, moderate check); fine_dining = Fine dining (Chef-driven, higher check); bar_lounge = Bar, taproom or lounge (Drinks are about half of sales or more); cafe = Café or coffee shop (Drinks lead, with pastries and light food). | |
| cardCount | No | ||
| cardSales | No | ||
| processor | Yes | Who processes the cards (the name at the top of the statement): bank = a bank or independent processor; other = another processor, or not sure. | |
| totalFees | No | ||
| pricingModel | No | ||
| averageTicket | No |
| Name | Required | Description |
|---|---|---|
| ask | Yes | Words the owner can read out to the processor. |
| fair | Yes | What a competitive interchange-plus account would cost, per $100: an estimate, not a published price. |
| link | Yes | Opens the check on the website with these figures filled in. |
| plan | Yes | |
| checks | Yes | Figures that look like a slip. They don't block the result. |
| format | Yes | |
| result | Yes | The page's words, in its order. |
| caveats | Yes | |
| sources | Yes | |
| verdict | Yes | |
| aboveTop | Yes | Fees above the range's top, whole dollars; 0 unless above it. |
| saleFrom | Yes | |
| cardCount | Yes | |
| cardSales | Yes | US dollars, like every amount here. |
| freeCheck | Yes | |
| processor | Yes | |
| realistic | Yes | |
| totalFees | Yes | |
| workedOut | Yes | |
| costPer100 | Yes | Total fees ÷ card sales × 100: the cost per $100 of card sales, also the effective rate in %. |
| aboveMiddle | Yes | The same above its middle. |
| averageSale | Yes | |
| pricingModel | Yes | |
| overTopPer100 | Yes | Dollars per $100 above the range's top; 0 unless above it. |
| feesToQuestion | Yes | By the names statements print. |
| yearlyCardSales | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the read-only, idempotent, non-destructive profile, yet the description adds substantial extra behavior: missing figures are never treated as 0, no data is stored, only an anonymous daily run count is kept, and the return includes the calculation and a prefilled link. These are behavioral traits the annotations cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose, and most clauses earn their place, but it is delivered as one dense run-on paragraph with several multi-clause sentences, making it harder to parse than it needs to be for the amount of information conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a multi-input analytical tool with an output schema, this is complete: inputs and their sources, scope limits, privacy handling, and what the return contains are all covered, so an agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at only 29%, the description carries most of the load and does so well: it names the two result-critical inputs, the statement sources to pull from, that all monthly/annual fees must be included, and which optional fields narrow the range. Only pricingModel is left unmentioned in the prose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb, resource and scope: 'Checks a US restaurant's card processing fees for one month,' then enumerates exactly what it answers (whether fees are too high, the effective rate, what to ask the processor). This is clearly distinguishable from siblings like booking_fees, delivery_price, or labor_cost.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit preconditions (needs the month's total card sales and total card fees, processor, restaurant type; card count/average sale narrows it) and clear exclusions ('doesn't read statements, contact a processor or take payment'). It does not, however, name sibling tools or state when a different check should be used instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Works out a restaurant's nightly cash close for one drawer and one day or shift, as the free cash-out sheet on restaurantdoctorai.com does: expected cash (starting bank + cash sales - cash tips paid out - paid outs), over or short against the cash counted, the deposit (counted minus the starting bank), the card difference (processor batch minus POS card sales) when both are sent, and comps, voids and discounts as a share of net sales. Takes the starting bank, cash sales and cash counted, plus optional paid outs, card figures and sales totals, in any currency; a figure that isn't sent is never counted as 0. It sets no normal for over or short. Returns the result, how it was worked out, and a link to the free cash-out sheet. The figures aren't stored; only an anonymous daily count of calculator runs is kept.
| Name | Required | Description | Default |
|---|---|---|---|
| comps | No | ||
| voids | No | ||
| netSales | No | ||
| paidOuts | No | ||
| cardBatch | No | ||
| cardSales | No | ||
| cashSales | No | ||
| discounts | No | ||
| cashCounted | No | ||
| startingBank | No | ||
| cashTipsPaidOut | No |
| Name | Required | Description |
|---|---|---|
| card | Yes | |
| link | Yes | The free cash-out sheet, to print or download. |
| notes | Yes | |
| checks | Yes | Figures that look like a slip. |
| result | Yes | The result in the sheet's words. |
| shares | Yes | |
| deposit | Yes | Cash counted minus the starting bank, which stays in the drawer. Below 0 when the drawer holds less than its bank. |
| freeCheck | Yes | |
| overShort | Yes | |
| workedOut | Yes | How it was worked out. |
| cashCounted | Yes | |
| expectedCash | Yes | Starting bank + cash sales - cash tips paid out - paid outs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety bar is met. The description adds genuine context: no normal/threshold is imposed on over or short, figures are not stored (only an anonymous daily run count), and the reply includes the workings plus a link. Missing only error/permission behavior, which is minor for a stateless calculator.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and inputs are front-loaded in the first sentence, and the second covers semantics and storage. It is dense and the opening sentence runs long enumerating every output, but for an 11-parameter financial calculator nearly every clause adds usable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a stateless calculator with an output schema, the description covers the essentials: required vs optional inputs, currency agnosticism, the missing-value rule, the non-storage behavior, and that no over/short threshold is applied. The only redundancy is re-describing return contents that the output schema already defines.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Reported schema coverage is 0% because descriptions sit inside anyOf branches, so the description must carry the load. It does: it names the three needed inputs (starting bank, cash sales, cash counted), groups the optional ones (paid outs, card figures, sales totals), supplies the formula role for several, and states the key semantic rule that an unsent figure is never treated as 0.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: works out a restaurant's nightly cash close for one drawer and one day or shift, and names the exact outputs (expected cash, over/short, deposit, card difference, comps/voids/discounts share). This cleanly separates it from sibling calculators like prime_cost or labor_cost, which compute entirely different figures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Scope is implied well (one drawer, one day or shift; send optional figures only if you have them), and it ties itself to the free cash-out sheet for context. However, it never explicitly states when to choose this over a sibling tool or what prerequisite data must be gathered first, leaving usage to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks a restaurant's own website as the online check on restaurantdoctorai.com does: secure (https) and on its own address, made for phones, a menu written as text that phones and Google can read, online orders on its own terms or only through delivery apps, the address, hours and phone written on the page, tap to call, a way to get in touch, email sign-up and gift cards, what Google reads (a headline, title and description, not hidden from search, restaurant structured data), the preview a shared link shows, the page's text, story, questions, reviews, photo descriptions and social links, and Google's phone speed test with its measures one by one and real visitors' speed when Google has it (15 to 40 seconds; phoneSpeed: false skips it). Returns each check with what to fix, the three to fix first, and a link to the full online check, which adds the Google listing and places nearby, free on the website. A check it couldn't make (a page drawn by scripts, a security screen instead of the page) is marked "Couldn't check" and left out of the score, never failed; every check, its points and where its facts come from are listed at https://restaurantdoctorai.com/online-check/checks. Takes only the website address. The website isn't stored; only an anonymous daily count of checks is kept.
| Name | Required | Description | Default |
|---|---|---|---|
| website | Yes | The restaurant's own website address, such as joesdiner.com or https://www.joesdiner.com. Not a DoorDash, Uber Eats or Google Maps page. | |
| phoneSpeed | No | Whether to run Google's phone speed test too (the default). It takes 15 to 40 seconds; false skips it. |
| Name | Required | Description |
|---|---|---|
| grade | Yes | |
| score | Yes | 0 to 100, from the website and phone-speed checks only (the full check adds the Google listing). |
| checks | Yes | |
| website | Yes | Where the site answered after redirects: its scheme and host only, such as https://www.joesdiner.com. |
| fixFirst | Yes | Up to three checks to fix first, most important first. |
| fullCheckUrl | Yes | The full online check on restaurantdoctorai.com: adds the Google listing and the places nearby, free. |
| phoneSpeedSkipped | Yes | Google's phone speed test wasn't run, because phoneSpeed was false. It isn't in the score. |
| ordersOnlyThroughApps | Yes | The site links online orders only to delivery apps (DoorDash, Uber Eats, Grubhub…), which charge a commission on each. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/destructive annotations, the description discloses latency (15–40 seconds, skippable via phoneSpeed: false), the privacy posture (website not stored, only an anonymous daily count), and an important failure semantic: checks that cannot be made are marked "Couldn't check" and excluded from the score rather than failed. That is real value-add over the annotations, though the scoring/return shape is left to the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded, but the body is a single sprawling comma-list enumerating every individual check (email sign-up, gift cards, photo descriptions, social links...), which reads as marketing copy rather than selection guidance. The reader must wade through ~250 words to reach the genuinely useful parts about "Couldn't check" handling and data retention.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description needn't explain return values, and it still covers the essentials: input scope, runtime cost, failure handling, and data retention. The only material gap is the absence of routing guidance against the similar run_free_check sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are already documented, including the same 15–40 second note for phoneSpeed. The description's "Takes only the website address" and its phoneSpeed aside merely restate the schema, adding no new syntax, format, or constraint information. Baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it audits a restaurant's own website, enumerating concrete check categories (https, mobile, text menu, tap-to-call, structured data, page speed). An agent can immediately tell this is a website audit rather than a calculator or knowledge tool. It does not, however, distinguish itself from the sibling restaurantdoctor_run_free_check, which is the most likely source of confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the schema's website description excludes DoorDash, Uber Eats and Google Maps pages, and the description notes that the returned link leads to a fuller check adding the Google listing and places nearby. There is no explicit statement of when to pick this over restaurantdoctor_run_free_check, nor any prerequisite guidance beyond latency.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads a recipe's ingredient lines as written, weighs each one with USDA FoodData Central and USDA yields, and prices it with the owner's own prices when given, else dated US public prices (BLS and USDA ERS store averages, USDA wholesale prices, and USDA weekly store-ad sale prices, which run low). Returns a draft in US dollars: each line's grams, cost and price source, what each line still needs, the cost per plate as a range, and a link that opens the draft on restaurantdoctorai.com, where the owner checks each line and adds prices for one plate cost and a menu price. The draft never gives one plate cost or a menu price, and says nothing about allergens or nutrition. The recipe isn't stored; only an anonymous daily count of drafts is kept.
| Name | Required | Description | Default |
|---|---|---|---|
| prices | No | The owner's own prices, when they give them. Lines without one use US public prices: store averages (BLS, USDA ERS), wholesale prices (USDA) and, for items those don't cover, USDA weekly store-ad sale prices, which run low. None is the owner's cost. Tap water is costed at 0. | |
| recipe | Yes | The recipe as written: its name, its servings line ("Serves 6") and its ingredient lines, one a line, each amount and unit exactly as the recipe or the photo gives it. Method steps may follow under a heading such as "Instructions"; only ingredient lines are costed. The lines are read as sent, not converted, rounded or corrected: the owner checks them on the website. At most 8000 characters and 60 ingredient lines. | |
| source | No | Where the recipe came from: text the owner typed or pasted (text), a photo or scan of a printed or typed page (typed-photo), a handwritten card (handwriting), or a PDF (pdf). It sets how many lines the owner confirms on the website: handwriting, every line. | text |
| servings | No | How many plates the recipe makes, when its text doesn't say. |
| Name | Required | Description |
|---|---|---|
| cost | Yes | |
| link | Yes | Opens this draft on the website, where the owner checks each line. |
| lines | Yes | |
| notes | Yes | What the draft assumed about the whole recipe. |
| checks | Yes | Amounts that look like slips, such as a lot of salt for the plates. |
| recipe | Yes | |
| sources | Yes | The public prices used. |
| currency | Yes | |
| nextStep | Yes | |
| servings | Yes | |
| disclaimer | Yes | |
| priceFirst | Yes | The dearest lines not on the owner's prices yet: their prices move the cost the most. |
| unusedPrices | Yes | Prices sent that matched no line. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, yet the description adds substantial behavioral context: the draft never yields a single plate cost or menu price, it says nothing about allergens or nutrition, the recipe is not stored (only an anonymous daily draft count), public sale prices 'run low', and tap water is costed at 0. That is exactly the kind of constraint disclosure annotations cannot carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is one dense paragraph, but it is front-loaded with the core verb chain and each sentence carries a distinct fact (pricing sources, output shape, limitations, storage). A few clauses duplicate what the schema already states about public/sale prices, which costs it the top mark.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description need not detail returns, yet it still summarizes the draft's contents, states the key limitations, and explains the privacy/storage behavior and the website hand-off. Nothing an agent needs to invoke this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: how the prices array is used as an override versus the public-price fallback, that 'source' controls how many lines the owner must confirm on the website, and that recipe lines are read as sent without conversion or correction.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource chain: it reads a recipe's ingredient lines, weighs them via USDA FoodData Central and USDA yields, prices them from owner prices or dated US public sources, and returns a draft in USD. This is far more specific than the sibling costing tools (plate_cost, prime_cost, menu_calories) and an agent can tell exactly what artifact it gets back.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for when this tool applies: you have recipe text (typed, photo, handwriting, PDF) and want a draft costing, and the owner then completes prices on the website for a final plate/menu price. However, it never names an alternative sibling (e.g., restaurantdoctor_plate_cost) or states a when-not-to-use condition, so the routing is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists a US restaurant's coming tax, payroll, license and permit deadlines, as the deadline calendar on restaurantdoctorai.com does: federal dates (payroll forms, tip reports, W-2s, 1099s, returns, estimated tax) and the state's (sales tax, unemployment reports, yearly reports, franchise taxes, minimum wage changes, liquor and health permit dates where one date applies to everyone), each moved for weekends and holidays by the agency's rule, with the rule, what a miss costs and the official source. A state date is given only where the state's own page confirms it; the rest come as what to check with the agency. Also the rules for each hire, and a link that opens the same calendar on the website, where the owner adds their own license and permit dates and gets free email reminders. Takes the state and yes/no answers, no names or emails; scope (federal or state) and withinDays (the next so many days) cut the list. Reminders, not legal or tax advice. The answers aren't stored; only an anonymous daily count of calendars is kept.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | A city with its own minimum wage, as an id like los-angeles or chicago; left out, the state's rate applies. | |
| tips | No | Customers usually tip the staff. | |
| scope | No | Optional, to cut the list: federal (the IRS's and other federal dates only), state (the state's and the city's only) or all (the default). The rules for each hire are listed either way. | |
| staff | Yes | Has anyone on payroll. | |
| state | Yes | The restaurant's US state, two letters (DC for Washington DC). | |
| formed | No | The month the LLC or corporation was formed with the state, YYYY-MM. Some states set the yearly report by it. | |
| months | No | How many months ahead to list, 1 to 15 (default 3). The calendar runs to the end of 2027. withinDays, when sent, sets the window instead. | |
| alcohol | Yes | Sells alcohol. | |
| caterer | No | Mainly catering or a food truck, not a restaurant or bar (OSHA's injury log). | |
| business | No | How the business is set up: sole (sole owner, no LLC), llc_single, llc_multi, partnership (no LLC), s_corp or c_corp. Decides the tax return and the state's yearly report. Left out, both return dates come with an "If". | |
| deposits | No | Who pays the payroll taxes to the IRS: provider (a payroll company), monthly (the owner, by the 15th), semiweekly (the owner, after each payday). | |
| salesTax | No | How often the state has the restaurant file sales tax (on its permit letter or state account). | |
| bigTipped | No | Tipped, and staff worked more than 80 hours in total on a typical day last year, all locations together (Form 8027). | |
| estimated | No | The owner pays quarterly estimated tax on the business's profit. | |
| fullTime50 | No | 50 or more full-time staff on average, counting part-timers' hours, related businesses together (ACA forms). | |
| withinDays | No | Optional: only the dates in the next so many days, 1 to 460, from today in the state (7 for the coming week). Sent, it replaces months. | |
| contractors | No | Pays a contractor, or rent to a landlord that isn't a corporation, $2,000 or more a year (1099 forms). |
| Name | Required | Description |
|---|---|---|
| from | Yes | The first day listed (today in the state), YYYY-MM-DD. |
| note | Yes | |
| state | Yes | |
| through | Yes | The last day listed, YYYY-MM-DD. |
| eachHire | Yes | Rules that run each time the restaurant hires (or something happens), not on a date. |
| checkWith | Yes | What we can't date for this owner: their own schedule or papers, or a state page not yet confirmed. No date here is guessed. |
| deadlines | Yes | |
| calendarUrl | Yes | The same calendar on restaurantdoctorai.com, where the owner can add the dates printed on their own licenses and permits and get email reminders or a calendar link, free. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations (readOnly/idempotent/non-destructive): it discloses data provenance ('A state date is given only where the state's own page confirms it; the rest come as what to check with the agency'), what gets stored ('The answers aren't stored; only an anonymous daily count of calendars is kept'), and the week/holiday adjustment rule. This is exactly the kind of context structured fields cannot carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose is front-loaded, but the single dense paragraph runs long and restates schema content ('Takes the state and yes/no answers... scope... withinDays cut the list') alongside genuinely new information. It is comprehensive rather than economical; trimming the input re-description would tighten it without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 17 parameters, an output schema, and safety annotations already present, the description supplies the remaining pieces an agent needs: data provenance, fallback behavior when no state page confirms a date, privacy handling, and the website link. Nothing material is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and every parameter carries a rich enum/detail description, so the schema does the heavy lifting. The description restates scope and withinDays generally but adds no syntax or format detail beyond what the schema already documents, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Lists) and resource (a US restaurant's coming tax, payroll, license and permit deadlines) and enumerates the concrete content (federal forms, state reports, holiday-moved dates). It is instantly distinguishable from every sibling, which are all cost/fee/knowledge calculators rather than a deadline calendar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear usage context: it names the driving inputs ('Takes the state and yes/no answers'), explains the scope/withinDays trimming, and sets expectations ('Reminders, not legal or tax advice'). It does not name an explicit alternative or a when-not-to-use condition, but no sibling overlaps this function, so the gap is minor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Works out a dish's break-even price on a delivery app, the app price that leaves the owner the same money as selling it in their dining room, as the free delivery app price calculator on restaurantdoctorai.com does: the in-house price ÷ (1 − the app's real commission rate), the markup on the in-house price that takes (rounded up to a whole percent), and what the app keeps. Takes the dish's in-house price, in any currency, and one app's real commission rate from its payout statements; a figure that isn't sent is never counted as 0. Returns the calculator's result, how it was worked out, and a link that opens the calculator with the same figures filled in. The figures aren't stored; only an anonymous daily count of calculator runs is kept.
| Name | Required | Description | Default |
|---|---|---|---|
| rate | No | ||
| price | No |
| Name | Required | Description |
|---|---|---|
| link | Yes | Opens the calculator on the website with these figures filled in. |
| rate | Yes | The real commission rate, %. |
| notes | Yes | |
| price | Yes | The in-house price it was worked out from, in the currency it was sent in. |
| result | Yes | The result in the page's words, in its order. |
| appKeeps | Yes | What the app keeps at the break-even app price, to the cent as the page shows it. |
| appPrice | Yes | The break-even app price, price ÷ (1 − rate), to the cent as the page shows it: the app price that leaves the owner the in-house price. |
| freeCheck | Yes | |
| workedOut | Yes | How it was worked out, with the figures in each step. |
| markupPercent | Yes | The markup on the in-house price that takes, %, rounded up to a whole number so it's never short. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds real value on top: 'The figures aren't stored; only an anonymous daily count of calculator runs is kept,' plus the note that a missing figure is never treated as 0 and triggers a follow-up request. That is meaningful behavioral context beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose and formula are front-loaded in the first sentence, and each subsequent sentence carries distinct information (inputs, missing-value behavior, outputs, storage). It is dense and appositive-heavy — the opening sentence is a long chain of dashes and clauses — but nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be explained, yet the description still summarizes them (result, working, prefilled link) and adds storage/privacy behavior plus missing-input handling. For a 2-parameter, zero-required calculator, nothing an agent needs to call it correctly is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is reported at 0%, so the description must carry the load, and it does: it defines the in-house price as what a dining-room guest pays in the owner's own currency and the rate as the app's real commission drawn from payout statements, and clarifies that an omitted figure is not defaulted to 0. It adds meaning but does not restate the percent-vs-decimal convention or the 0–89 bound that the schema actually documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (computes a dish's break-even delivery-app price) and immediately defines the scope: the app price that nets the owner the same as an in-house sale, plus the markup and app's cut. The explicit formula and the naming of the real commission rate distinguish it cleanly from siblings like restaurantdoctor_break_even and restaurantdoctor_card_fees.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear usage conditions: one app's real commission rate per call, taken from a month of payout statements rather than the plan rate, with each app worked out on its own. It does not name an alternative tool or state when-not to use this one, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimates a US restaurant's FICA tip credit (IRS Form 8846, the 45B credit) for a year like the one in its payroll figures, as the free FICA tip credit check on restaurantdoctorai.com does: the employer's 7.65% Social Security and Medicare tax on reported tips, less the tips needed to bring tipped staff's cash wage up to the 5.15 dollars an hour the law fixes for restaurants. Returns the reasons the real answer may be zero first (already claimed, no federal income tax owed, service charges aren't tips, only the business can claim it), then the credit as a range, its worth after the deduction it replaces, the years that may still be open, and sources. It answers questions about taxes on tips, Form 8846, the 45B credit or money the business may be missing on tips. It needs the state, a year's tips reported through payroll (never service charges) and, where the cash wage is under 5.15 dollars, tipped staff's hours that year; whether the return already includes Form 8846 comes first, if known. A figure that isn't sent is never counted as 0. It files nothing, isn't tax advice and takes no payment: the result is an estimate to take to the accountant, with a link that opens the same check with the figures filled in. The figures aren't stored; only an anonymous daily count of calculator runs is kept.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | ||
| cashWage | No | ||
| tippedHours | No | ||
| businessType | No | ||
| reportedTips | No | ||
| owesIncomeTax | No | ||
| alreadyClaimed | No |
| Name | Required | Description |
|---|---|---|
| base | Yes | $5.15: tips needed to bring the cash wage up to this don't count. |
| link | Yes | Opens the check on the website with these figures filled in. |
| state | Yes | |
| checks | Yes | Figures that look like a slip. They don't block the result. |
| credit | Yes | The gross FICA tip credit for a year like this; exact when the cash wage is $5.15 or more. |
| result | Yes | The page's words, in its order. |
| sources | Yes | |
| afterTax | Yes | After the deduction it replaces, before state tax: federal rates assumed, share of each credit dollar kept. |
| cashWage | Yes | |
| headline | Yes | |
| setAside | Yes | Hours × the gap. |
| freeCheck | Yes | |
| hoursUsed | Yes | Only when the cash wage is under $5.15. |
| openYears | Yes | Years a missed credit may still be claimed for. |
| gapPerHour | Yes | |
| irsWebPage | Yes | At the IRS web page's $7.25: the most cautious reading. |
| tippedHours | Yes | |
| tipsPerHour | Yes | |
| zeroReasons | Yes | Why the real answer may be $0 (applies: these answers say so; check: one to rule out), said before any dollar figure. |
| businessType | Yes | |
| headlineKind | Yes | |
| reportedTips | Yes | US dollars, like every amount here. |
| tipsBelowGap | Yes | |
| allTipsCredit | Yes | 7.65% of every tip: the most it can be. |
| assumedUnsure | Yes | Left out, read as unsure. |
| owesIncomeTax | Yes | |
| alreadyClaimed | Yes | |
| creditableTips | Yes | |
| usableThisYear | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, and the description adds substantial context beyond them: it files nothing, isn't tax advice, takes no payment, figures aren't stored (only an anonymous daily count), and it returns zero-reasons first. That is rich behavioral disclosure an agent can rely on.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose is front-loaded in the first sentence and every clause carries real information, but the description is a dense run-on block that crams multiple ideas (output order, disclaimers, data handling, inputs) into very long sentences, reducing scanability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and annotations covering the safety profile, the description fills the remaining gaps: what it returns (zero-reasons first, then a range, after-tax worth, open years, sources), disclaimers, and data handling. Nothing needed to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already carries detailed per-parameter descriptions, so the baseline is 3; the description adds meaning on top by stating which inputs drive a result ('needs the state, a year's tips reported through payroll... and, where the cash wage is under 5.15, tipped staff's hours'), the priority of alreadyClaimed, and that 'a figure that isn't sent is never counted as 0.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: 'Estimates a US restaurant's FICA tip credit (IRS Form 8846, the 45B credit).' It scopes precisely (US restaurants, per year) and is clearly distinguishable from siblings like tip_out or labor_cost. An agent knows exactly what this computes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear usage context: 'It answers questions about taxes on tips, Form 8846, the 45B credit or money the business may be missing on tips,' and lists the inputs needed. However, it names no alternative sibling tool or an explicit when-not-to-use condition, so routing against other tools is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the 12 multiple-choice questions of the free restaurant profit check, with the answer values each one accepts. Money ranges, delivery apps and review sites follow the restaurant's country (default US).
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | Where the restaurant is: a two-letter ISO 3166-1 code such as US, CA, AU or DE (GB for the United Kingdom). Sets the currency and local wording. Defaults to US. | US |
| Name | Required | Description |
|---|---|---|
| country | Yes | |
| currency | Yes | Of the money ranges (ISO 4217). |
| countries | Yes | |
| questions | Yes | |
| countryName | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description still adds useful context beyond them: exactly 12 questions, that each question enumerates its accepted answer values, and that country drives money ranges, delivery apps and review sites with a US default.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences, front-loaded with what is returned and followed by the country-dependent variation. Every clause carries information and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value details need not be in the description. With the question count, answer-value enumeration, and country effects covered, an agent has everything needed to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single country parameter is fully documented in the schema, so baseline would be 3. The description adds meaning beyond the schema by explaining what the country actually affects (money ranges, delivery apps, review sites) and confirming the US default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (Lists) and resource (the 12 multiple-choice questions of the free restaurant profit check), plus the scope of the returned data (answer values each question accepts). It is clear without opening the schema, but it never names the closely related sibling run_free_check, so the boundary is only implicitly distinguishable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent can infer this retrieves the question set, presumably as groundwork for run_free_check, but the description gives no explicit when-to-use, when-not-to-use, or alternative routing. No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Works out a restaurant's labor cost from the owner's own payroll figures for one week or month, as the free labor cost calculator on restaurantdoctorai.com does, in one of its three modes: share (labor as a % of net sales, against the range for its type of restaurant, with what the points over are worth), hours (next period's labor budget and the hourly staff hours it pays for once salaries are paid) or line (the cut line: the sales per labor hour below which the first person goes home). Takes net sales, hourly pay and hours worked, plus optional salaries, payroll taxes and benefits, expected sales, a target and more, in any currency; a figure that isn't sent is never counted as 0. Returns the calculator's result, how it was worked out, and a link that opens the calculator with the same figures filled in. The figures aren't stored; only an anonymous daily count of calculator runs is kept.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | What to work out, as the page's tabs. share: last period's labor cost, % of net sales, against the range (needs sales, hourlyWages). hours: the labor budget for next period's expected sales and the hourly staff hours it pays for (needs forecast, hourlyWages, hours). line: the cut line, the sales per labor hour below which the first person goes home (needs hourlyWages, hours, and sales or forecast). | |
| hours | No | ||
| sales | No | ||
| format | Yes | The type of restaurant, which sets the labor range and the starting target: quick_service = Quick service (Counter or kiosk, fast turnover); fast_casual = Fast casual (Order at the counter, food brought to the table); full_service = Full service / casual dining (Servers, moderate check); fine_dining = Fine dining (Chef-driven, higher check); bar_lounge = Bar, taproom or lounge (Drinks are about half of sales or more); cafe = Café or coffee shop (Drinks lead, with pastries and light food). | |
| period | Yes | Whether the figures are a week's or a month's: last period's, all for the same dates, and forecast for the next. Sets how a year is worked out (52 weeks or 12 months). | |
| target | No | ||
| forecast | No | ||
| ownerPay | No | ||
| salaries | No | ||
| hourSales | No | ||
| hourlyWages | No | ||
| payrollCosts | No | ||
| overtimeHours | No |
| Name | Required | Description |
|---|---|---|
| link | Yes | Opens the calculator with these figures. |
| mode | Yes | |
| guide | Yes | |
| notes | Yes | |
| range | Yes | |
| share | Yes | |
| checks | Yes | Figures that look like a slip, as the page flags them. |
| format | Yes | |
| period | Yes | |
| result | Yes | The result in the page's words, in its order. |
| target | Yes | |
| cutLine | Yes | |
| hourCost | Yes | |
| freeCheck | Yes | |
| workedOut | Yes | How it was worked out. |
| nextPeriod | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavior: figures are not stored (only an anonymous daily run count), unsent figures are never treated as 0, any currency is accepted, and the response includes the working plus a pre-filled calculator link. It does not discuss rate limits or failure modes, but the added context is well beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and mode list are front-loaded, so a skimming agent gets value immediately. However the whole body is one sprawling comma-chained sentence with stacked parentheticals, which makes it harder to parse than it needs to be and repeats some mode specifics that the schema already carries.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 13-parameter, three-mode calculator the description covers mode selection, input sourcing, currency and missing-value handling, privacy, and the output link, and an output schema exists so return values need no elaboration. The only real gap is that it never situates the tool against the other cost calculators in the sibling set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With reported schema description coverage at 23%, the description carries real weight: it names the core inputs (net sales, hourly pay and hours worked), the optional ones (salaries, payroll taxes, benefits, expected sales, target) and two important semantics — any currency is accepted and omitted figures are not counted as zero. It does not name every one of the 13 parameters (e.g. ownerPay, overtimeHours, hourSales are only covered in the schema), which keeps it short of a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('works out a restaurant's labor cost from the owner's own payroll figures') and then enumerates its three modes with what each computes. An agent can distinguish this from siblings like prime_cost, restaurant_budget or break_even without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly frames usage around three named modes and what each requires ('share: labor as a % of net sales...', 'hours: next period's labor budget...', 'line: the cut line...'), which tells an agent how to pick a mode. It never says when to prefer this tool over adjacent calculators such as prime_cost or restaurant_budget, so sibling-level routing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the entries of RestaurantDoctorAI's sourced library, all or one kind (guide, post, play, targets, fact or knowledge), up to 50 at a time: each with its id, kind, title, link and source, and for guides and blog posts the day it was published and last updated. It shows what the library has, such as every blog post and its date. Pages with offset and limit; nextOffset gives the next page. Nothing about the request is stored; only an anonymous daily count of searches (a list counts as one) is kept.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Which kind of entry to list: guide (the website's guides), post (blog posts), play (RestaurantDoctorAI's step-by-step fixes), targets (RestaurantDoctorAI's targets by type of restaurant), fact (sourced industry facts) or knowledge (sourced how-tos, rules and checklists); or all (the default). | all |
| limit | No | How many entries to return, 1 to 50 (default 20). | |
| offset | No | How many entries to skip (default 0). The next page starts at the nextOffset the previous list returned. |
| Name | Required | Description |
|---|---|---|
| kind | Yes | |
| note | Yes | |
| total | Yes | How many entries of this kind there are. |
| offset | Yes | |
| entries | Yes | In the library's order: guides, blog posts, playbook fixes, targets, facts, then knowledge entries. |
| nextOffset | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real behavioral context beyond them: the 50-item cap per call, offset/limit paging with nextOffset as the cursor, and the privacy statement that nothing about the request is stored except an anonymous daily search count.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The opening is well front-loaded, but the paragraph is longer than needed: "It shows what the library has, such as every blog post and its date" re-states the field list already enumerated in the preceding clause, and the pagination statement duplicates the schema. Several sentences could be dropped without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple read-only list with an output schema, so return values need not be explained. With 0 required params, full schema coverage, and pagination plus privacy notes covered, the agent has essentially everything needed to call it correctly; only explicit sibling routing is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (including the full kind enum and the offset/limit defaults and bounds) are already documented in the schema. The description largely restates the kind list and pagination behavior rather than adding new syntax or format meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a concrete verb and resource ("Lists the entries of RestaurantDoctorAI's sourced library") and scopes it to all-or-one kind. That is unambiguous, but it never names or contrasts the obvious siblings (read_knowledge, search_knowledge), so the agent must infer the enumeration-vs-lookup distinction itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"It shows what the library has, such as every blog post and its date" implies a browse/inventory use case, which is useful context. However there is no explicit when-to-use guidance and no exclusions or pointers to read_knowledge/search_knowledge, so the selection logic against alternatives is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Works out par levels and what to order for up to 50 kitchen or bar items, as the free prep and par sheet on restaurantdoctorai.com does. Par = use per day × days covered + safety stock (days covered: from the day of the count and the order until the next delivery after this one arrives); order = par minus what's on hand, never below 0, rounded up to whole packs when a pack size is sent. Takes each item's use per day (or per week and the days open a week), days covered, optional safety stock and pack size, and what's on hand, in the owner's own units; a figure that isn't sent is never counted as 0, and an item missing one is returned as incomplete. Returns each item's par and order, the items that need an order, and a link to the free prep and par sheet. The figures aren't stored; only an anonymous daily count of calculator runs is kept.
| Name | Required | Description | Default |
|---|---|---|---|
| items | No | ||
| daysCovered | No | ||
| daysOpenPerWeek | No |
| Name | Required | Description |
|---|---|---|
| link | Yes | The free prep and par sheet, to print or download. |
| items | Yes | |
| notes | Yes | |
| result | Yes | The result in the sheet's words. |
| totals | Yes | |
| toOrder | Yes | The items that need an order. |
| freeCheck | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial behavior beyond them: the exact formulas for par and order, rounding to whole packs, the rule that an unsent figure is never treated as 0 and yields an 'incomplete' item, and the privacy statement that figures are not stored with only an anonymous daily run count kept. That is rich disclosure of computation and side-effect posture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first clause, and the two paragraphs stay on task. It is dense and somewhat long, with parenthetical restatements of the days-covered window that the schema already carries, so it is efficient rather than tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite three parameters and a nested item array, the description covers inputs, formula behavior, error handling for incomplete items, and the non-persistence guarantee. An output schema exists, yet the description still names the returns (par, order, items needing order, link), leaving nothing an agent needs in order to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Reported schema description coverage is 0%, so the description carries the burden and largely does: it explains use-per-day vs use-per-week with daysOpenPerWeek, the days-covered window definition, safety stock as optional, pack size forcing whole-pack rounding, and that on-hand is required. It stops short of mapping every nested field (name, unit) and of clarifying all requiredness rules, so it is strong but not exhaustive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: works out par levels and order quantities for up to 50 kitchen or bar items. It clearly distinguishes itself from sibling costing tools (cost_recipe, plate_cost, prime_cost) by naming its domain and anchoring to the public prep and par sheet. An agent can identify the tool without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when the tool applies: a kitchen or bar prep/par calculation with use-per-day, days covered, safety stock and pack size inputs. It never names an alternative sibling or an explicit when-not condition, so it falls short of the top band. There is enough context to select it correctly but no routing guidance against the other costing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Works out what one plate of a dish costs and what to charge for it, as the free plate cost calculator on restaurantdoctorai.com does: from each ingredient's pack price and the amount used (with a usable % for trim), or from a plate cost the owner already knows; then the food cost at the menu price, what's left per plate, the price for their target food cost and the prices inside the range for their type of restaurant, with the tax taken out of a tax-inclusive menu. It works from the owner's own prices and amounts, in any currency; a figure that isn't sent is never counted as 0. Returns the calculator's result, how it was worked out, and a link that opens the calculator with the same figures filled in. The figures aren't stored; only an anonymous daily count of calculator runs is kept.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | ingredients: from each ingredient's pack price and the amount used. known: from a plate cost the owner already has. | |
| sold | No | ||
| extras | No | ||
| format | Yes | The type of restaurant, which sets the food cost range and the starting target: quick_service = Quick service (Counter or kiosk, fast turnover); fast_casual = Fast casual (Order at the counter, food brought to the table); full_service = Full service / casual dining (Servers, moderate check); fine_dining = Fine dining (Chef-driven, higher check); bar_lounge = Bar, taproom or lounge (Drinks are about half of sales or more); cafe = Café or coffee shop (Drinks lead, with pastries and light food). | |
| target | No | ||
| taxRate | No | ||
| portions | No | ||
| menuPrice | No | ||
| plateCost | No | ||
| ingredients | No | ||
| taxIncluded | No |
| Name | Required | Description |
|---|---|---|
| link | Yes | Opens the calculator with these figures. |
| mode | Yes | |
| batch | Yes | |
| guide | Yes | |
| notes | Yes | |
| range | Yes | The format's whole-menu food and drink cost range, % of sales. |
| checks | Yes | Figures to look at again. They don't hold up the result. |
| format | Yes | |
| result | Yes | The result in the page's words, in its order. |
| target | Yes | |
| taxPct | Yes | The tax rate in menu prices; 0 when they don't include it. |
| standing | Yes | |
| freeCheck | Yes | |
| plateCost | Yes | One plate's ingredient cost. |
| workedOut | Yes | How it was worked out. |
| priceRange | Yes | |
| atMenuPrice | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent/non-destructive annotations, it discloses currency-agnostic behavior, the rule that a missing figure is never treated as 0, what is returned (result, derivation, shareable link with figures pre-filled), and the privacy posture (figures not stored, only an anonymous daily run count). That is exactly the value-add context annotations cannot carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded, but the body is a long chained sentence with heavy clause stacking ('...then the food cost at the menu price, what's left per plate, the price for their target food cost and the prices inside the range...'), which is harder to parse than a short bulleted breakdown would be. The reference to the website calculator is filler for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 11-parameter calculator with an output schema and strong annotations, the description covers the conceptual model, currency behavior, null handling and data-retention note, which is enough to call it correctly. It leaves a few parameters (portions, sold, extras) to the schema, which is acceptable given the schema does document them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With reported schema coverage at 18%, the description must carry the load, and it explains mode semantics, the usable-% trim concept, plateCost vs ingredients, menuPrice optionality ('as for a new dish'), target and the format-driven range, and tax removal from a tax-inclusive menu. It stays silent on portions, sold and extras, which are the main gaps; the null-handling sentence offsets some of that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'works out what one plate of a dish costs and what to charge for it', plus the derived outputs (food cost at menu price, margin per plate, target price, format range, tax extraction). An agent can tell this is a plate-cost/pricing tool rather than a general recipe or prime-cost tool. It never names the close siblings (cost_recipe, prime_cost, delivery_price), so differentiation is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The two input paths are spelled out clearly ('from each ingredient's pack price and the amount used ... or from a plate cost the owner already knows'), which implies when each mode applies. But there is no explicit when-to-use/when-not guidance relative to cost_recipe or prime_cost, and no preconditions (e.g. what the caller must already know before choosing mode known).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Works out a restaurant's prime cost from the owner's own figures for one week or month, as the free prime cost calculator on restaurantdoctorai.com does: food and drink used plus labor, as a share of net sales, against the target for its type of restaurant, with what the points over or under are worth, food and labor each against their own range, and which to look at first. Takes net sales, food and drink purchases and wages, plus optional payroll taxes and benefits, stock counts and the owner's unpaid hours, in any currency; a figure that isn't sent is never counted as 0. Returns the calculator's result, how it was worked out, and a link that opens the calculator with the same figures filled in. The figures aren't stored; only an anonymous daily count of calculator runs is kept.
| Name | Required | Description | Default |
|---|---|---|---|
| sales | No | ||
| wages | No | ||
| format | Yes | The type of restaurant, which sets the targets: prime cost, and the ranges for food and drink and for labor: quick_service = Quick service (Counter or kiosk, fast turnover); fast_casual = Fast casual (Order at the counter, food brought to the table); full_service = Full service / casual dining (Servers, moderate check); fine_dining = Fine dining (Chef-driven, higher check); bar_lounge = Bar, taproom or lounge (Drinks are about half of sales or more); cafe = Café or coffee shop (Drinks lead, with pastries and light food). | |
| period | Yes | Whether every figure covers one week or one month, the same dates for all of them. Sets how a year is worked out (52 weeks or 12 months). | |
| ownerPay | No | ||
| purchases | No | ||
| closingStock | No | ||
| openingStock | No | ||
| payrollCosts | No |
| Name | Required | Description |
|---|---|---|
| left | Yes | |
| link | Yes | Opens the calculator on the website with these figures filled in. |
| guide | Yes | |
| notes | Yes | |
| checks | Yes | Figures that look like a slip, as the page flags them. They don't block the result. |
| format | Yes | |
| period | Yes | |
| points | Yes | Points over the target, or to spare under it; 0 right at it. |
| result | Yes | The result in the page's words, in its order. |
| target | Yes | The prime cost ceiling for this type of restaurant, % of net sales. |
| figures | Yes | In the currency of the figures sent. |
| standing | Yes | Against the target, on the share as shown. |
| freeCheck | Yes | |
| workedOut | Yes | How it was worked out, with the figures in each step. |
| laborShare | Yes | |
| overTarget | Yes | |
| pointValue | Yes | One point of prime cost (1% of net sales), a period and a year, rounded as the page shows it. |
| primeCostPct | Yes | Food and drink used plus labor, % of net sales, one decimal. |
| withOwnerPay | Yes | |
| usedStockCounts | Yes | |
| foodAndDrinkShare | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations, which already cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds the crucial missing-input rule ('a figure that isn't sent is never counted as 0'; a needed figure missing triggers a request), currency-agnostic behavior, and data handling ('figures aren't stored; only an anonymous daily count of calculator runs is kept'). These are exactly the traits an agent needs and cannot infer from structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the purpose in the opening clause and then layer by layer: inputs, missing-value behavior, outputs, privacy. Information density is high, though the first sentence is a long run-on chain of clauses and the comparison to restaurantdoctorai.com's free calculator adds little for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a calculation tool with 9 parameters and an output schema, this covers the full picture: what goes in, which inputs are mandatory, how absent values are treated, currency neutrality, privacy of the figures, and that a pre-filled link comes back. Nothing an agent needs in order to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With reported schema description coverage at 22%, the description carries real weight, and it does: it groups the 9 inputs into required (net sales, food and drink purchases, wages) plus optional (payroll taxes and benefits, stock counts, owner's unpaid hours) and states the key semantic that omitted figures are not treated as zero. It does not explain the opening/closing stock pairing or the period-annualization rule, which remain only in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb and resource: it 'works out a restaurant's prime cost' and enumerates the components (food and drink used + labor as a share of net sales, against type-of-restaurant targets). An agent knows exactly what computation this performs. It does not, however, distinguish itself from near-siblings such as restaurantdoctor_labor_cost, restaurantdoctor_break_even or restaurantdoctor_restaurant_budget, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: the tool is for turning one week/month of owner figures into a prime-cost read-out, and required inputs (sales, wages, purchases) are named, which signals the preconditions. But there is no explicit when-to-use, when-not-to-use, or pointer to an alternative sibling for labor-only or food-only analysis. Adequate but with a clear routing gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads one entry of RestaurantDoctorAI's library in full (a guide, a blog post, a playbook fix, the targets, a fact or a knowledge entry), by its id (such as 'guide:restaurant-prime-cost'), with its title, link and source. A long entry comes 8,000 characters at a time, with its total length: the next part starts at the nextOffset it returns. The query isn't stored; only an anonymous daily count of searches and reads is kept.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | An entry id, as the library's search and list give it, e.g. 'guide:restaurant-prime-cost' or 'post:restaurant-break-even-point'. | |
| offset | No | Where to start, in characters (default 0, the start). A long entry comes 8,000 characters at a time: the next part starts at the nextOffset the previous read returned. |
| Name | Required | Description |
|---|---|---|
| id | Yes | The entry's id, which reading the entry in full takes. |
| url | Yes | Where a reader can check it: the page on restaurantdoctorai.com, or the fact's own source. |
| kind | Yes | |
| note | Yes | |
| text | Yes | The entry's text from offset, up to 8,000 characters. |
| title | Yes | |
| offset | Yes | Where this part starts, in characters. |
| source | Yes | Who says so, with the date it was checked or updated where there is one. |
| truncated | Yes | More of the entry follows this part (nextOffset says where). |
| nextOffset | Yes | |
| totalLength | Yes | The whole entry's length, in characters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds meaningful context beyond those annotations: it explains the 8,000-character pagination behavior, the nextOffset return value for continuing, and that queries are not stored beyond anonymous daily counts. It does not cover error behavior or rate limits, so it is not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and remains compact across three sentences. The parenthetical list of entry types is somewhat long, but each sentence contributes useful detail about scope, pagination, or privacy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the description need not explain return values. It covers the key operational detail for long entries through pagination and nextOffset, and annotations cover the safety profile. It would be stronger if it explicitly routed users from search/list to this read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents both the id and offset parameters with examples and character-count semantics. The description reinforces pagination but does not add meaning beyond what the schema provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it reads one entry of RestaurantDoctorAI's library in full by id, including guides, posts, playbook fixes, targets, facts, and knowledge entries. This clearly distinguishes it from sibling tools like list_knowledge and search_knowledge, which would return multiple or matched entries rather than one full entry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: the id format and the phrase 'by its id' suggest this tool is used after obtaining an id from search or list. However, the description does not explicitly say when to use this tool instead of search_knowledge or list_knowledge, nor does it state exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Works out a restaurant's monthly budget from the owner's expected sales and type of restaurant, as the free restaurant budget calculator on restaurantdoctorai.com does: food and drink, labor, prime cost and rent with utilities as money ranges by RestaurantDoctorAI's targets for that type, other operating costs at the owner's share or a 20% working assumption, what's left after every bill, and break-even sales with labor counted both ways. Takes expected net sales and the type, plus optional rent, the owner's own pay and the other costs share, in any currency; a figure that isn't sent is never counted as 0. Returns the calculator's result, how it was worked out, and a link that opens the calculator with the same figures filled in. The figures aren't stored; only an anonymous daily count of calculator runs is kept.
| Name | Required | Description | Default |
|---|---|---|---|
| rent | No | ||
| sales | No | ||
| format | Yes | The type of restaurant, which sets RestaurantDoctorAI's targets the budget is split by: quick_service = Quick service (Counter or kiosk, fast turnover); fast_casual = Fast casual (Order at the counter, food brought to the table); full_service = Full service / casual dining (Servers, moderate check); fine_dining = Fine dining (Chef-driven, higher check); bar_lounge = Bar, taproom or lounge (Drinks are about half of sales or more); cafe = Café or coffee shop (Drinks lead, with pastries and light food). | |
| otherPct | No | ||
| ownerPay | No |
| Name | Required | Description |
|---|---|---|
| left | Yes | Left over after every bill, before income tax, not profit; low is the budget at the top of the targets. |
| link | Yes | Opens the calculator with these figures. |
| rent | Yes | |
| lines | Yes | A month, low to high, money to the unit. primeCost is food and drink plus labor, a subtotal. |
| notes | Yes | |
| sales | Yes | |
| checks | Yes | Figures that look like a slip. |
| format | Yes | |
| result | Yes | The result in the page's words, in its order. |
| breakEven | Yes | With the budget at the top of the targets, rounded up to the unit. |
| freeCheck | Yes | |
| workedOut | Yes | How it was worked out. |
| otherCostsAssumed | Yes | True when the other operating costs share is the working assumption. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuine behavioral context beyond them: a missing figure is never treated as 0, otherPct defaults to 20% as a 'working assumption, not a target', rent replaces the occupancy range, figures are not stored and only an anonymous daily run count is kept, and a shareable link is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Content is front-loaded with purpose and outputs, and every clause carries information, but the body is one very long comma-chained sentence that is hard to scan. Splitting input, output and privacy facts into separate sentences would improve structure without losing content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, yet the description still usefully flags that the reply includes the result, the reasoning, and a pre-filled calculator link, plus the privacy posture — enough for an agent to call and set expectations. The only real omission is sibling routing against the adjacent cost/break-even calculators.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite the reported 20% schema coverage, the description names and gives meaning to every parameter family — expected net sales, restaurant type, optional rent, owner's own pay, other-costs share — and adds cross-cutting semantics (any currency, omitted ≠ zero) that the schema states only piecemeal. It stops short of restating the enum options or numeric bounds, leaving those to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — 'works out a restaurant's monthly budget from the owner's expected sales and type of restaurant' — and enumerates the outputs (food and drink, labor, prime cost, rent/utilities, other opex, what's left, break-even). That scope implicitly separates it from narrower siblings like prime_cost or break_even, but neither sibling is named, so separation is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the framing ('as the free restaurant budget calculator on restaurantdoctorai.com does') and by the note that sales is needed for a result and will be asked for if missing. However, there is no explicit when-to-use/when-not guidance and no routing against the overlapping sibling tools (restaurantdoctor_break_even, restaurantdoctor_prime_cost, restaurantdoctor_labor_cost).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scores a restaurant's 12 answers against RestaurantDoctorAI's targets for its type of restaurant and returns the free result the website shows: an overall grade, grades by area, the estimated profit leak of all the leaks together a month and a year, the biggest leak or opportunity with its estimated money a month, what one point of prime cost is worth, and the first fix. Includes a link that opens the same result on restaurantdoctorai.com. Takes only the 12 answers and the country, each answer one of the values its question accepts. The answers aren't stored; only an anonymous daily count of checks is kept.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | Where the restaurant is: a two-letter ISO 3166-1 code such as US, CA, AU or DE (GB for the United Kingdom). Sets the currency and local wording. Defaults to US. | US |
| laborFlexing | Yes | When a shift gets slow, what happens to staffing? realtime_cuts_splh = We cut staff based on sales per labor hour; fixed_shifts_regardless = Everyone works their scheduled shift anyway; overtime_above_8_percent = Overtime is common (More than 8% of hours); chronic_understaffing_owner_covers = We're short-staffed (The owner or GM works the line). | |
| serviceModel | Yes | What kind of restaurant do you run? quick_service = Quick service (Counter or kiosk, fast turnover); fast_casual = Fast casual (Order at the counter, food brought to the table); full_service = Full service / casual dining (Servers, moderate check); fine_dining = Fine dining (Chef-driven, higher check); bar_lounge = Bar, taproom or lounge (Drinks are about half of sales or more); cafe = Café or coffee shop (Drinks lead, with pastries and light food). | |
| contactCapture | Yes | How do you bring guests back? automated_pos_loyalty_50plus = Loyalty or email list with automatic campaigns (50+ new contacts a week); occasional_checkout_emails = We collect some emails but rarely use them; no_database_social_only = Social media and walk-ins only; paid_ads_no_list = Paid ads, but no guest list of our own. | |
| monthlyRevenue | Yes | About how much do you sell in a typical month? Amounts are in US dollars, or in the local currency where that's the euro, pound sterling, Swiss franc, or Canadian, Australian or New Zealand dollar. under_25k = Under $25,000 (Under $300K a year); 25k_60k = $25,000 – $60,000 ($300K – $720K a year); 60k_120k = $60,000 – $120,000 ($720K – $1.44M a year); 120k_200k = $120,000 – $200,000 ($1.44M – $2.4M a year); over_200k = Over $200,000 (Over $2.4M a year). | |
| seatingDynamics | Yes | How full is your dining room across the week? consistent_weekround = Steady all week; packed_weekends_dead_midweek = Packed on weekends, quiet midweek; strong_lunch_weak_dinner = Busy lunches, slow dinners; erratic_unpredictable = Hard to predict week to week. | |
| reputationHealth | Yes | What's your average rating on Google and Yelp? 4_5_to_5_0 = 4.5 – 5.0 stars; 4_0_to_4_4 = 4.0 – 4.4 stars; 3_5_to_3_9 = 3.5 – 3.9 stars; under_3_5 = Below 3.5 stars. | |
| beverageMonitoring | Yes | How do you control drink pours? no_alcohol = We don't serve alcohol; measured_pour_keg_audits = Measured pours, plus weekly pour-cost checks; occasional_spot_checks = Spot checks when bottles run out early; free_pour_no_audit = Free pours, no pour-cost checks. | |
| deliveryDependency | Yes | How much of your sales come through DoorDash, Uber Eats or similar apps? zero_direct_only = None (Dine-in and our own ordering only); under_15_with_markup = Under 15% (With higher app prices to cover fees); 15_to_35_standard_cut = 15% – 35% (At regular menu prices); over_35_heavy_drag = More than 35%. | |
| occupancyCostRatio | Yes | What share of sales goes to rent, property costs and utilities? under_8_percent = Under 8%; 8_to_12_percent = 8% – 12%; over_12_percent = More than 12%; unsure_ratio = I'm not sure. | |
| primeCostAwareness | Yes | What's your prime cost: food, drink and labor costs as a share of sales? under_58 = Under 58%; 58_to_64 = 58% – 64%; over_65 = 65% or more; not_tracked_weekly = I don't track it regularly. | |
| wasteTrackingMethod | Yes | How do you track kitchen waste and spoilage? daily_signed_log = A daily log the chef signs off; weekly_visual_estimate = A rough estimate during weekly inventory; bulk_loss_only = Only when a big batch or case goes bad; no_formal_logging = We don't track it. | |
| plateCostingFrequency | Yes | How often do you update recipe costs with current supplier prices? live_monthly_software = Monthly or live, with software (Synced to supplier invoices); 6_to_12m_manual = Once or twice a year (In a spreadsheet); new_menu_only = Only when the menu changes; rarely_gut_feeling = Rarely (Prices are set by feel or by competitors). |
| Name | Required | Description |
|---|---|---|
| link | Yes | Opens this result on the website. |
| risk | Yes | |
| areas | Yes | |
| grade | Yes | A (best) to F. |
| notes | Yes | What the result assumes. |
| biggest | Yes | The biggest leak, or the biggest sales opportunity when nothing leaks. |
| country | Yes | |
| leakText | Yes | |
| alsoCheck | No | |
| areasNote | Yes | |
| dayOneFix | Yes | |
| disclaimer | Yes | |
| primePoint | Yes | What one point of prime cost (1% of sales) is worth a month, at the working figure for the sales range. |
| yearlyLeak | Yes | The same total a year. null when no major leak was found. |
| countryName | Yes | |
| monthlyLeak | Yes | The total of all the leaks a month, as the website leads with it. null when no major leak was found. |
| needsAttention | Yes | |
| needsAttentionText | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: the answers aren't stored (only an anonymous daily count), and it returns a shareable link to the same result on the website. It stops short of pagination/rate details, but for a stateless compute tool that is minor.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then params and data handling, and every sentence carries information. The long enumeration of return fields is somewhat redundant given an output schema exists, which is the only real waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 13-param, enum-heavy computation tool with an output schema and full annotations, the description covers purpose, input constraints, data-retention behavior, and the link/return nature. Nothing an agent needs in order to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with richly documented enums, so the schema does the heavy lifting and the baseline is 3. The description adds only that the tool 'takes only the 12 answers and the country' and each answer must be one of its question's accepted values, which the enums already convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Scores a restaurant's 12 answers against RestaurantDoctorAI's targets') and resource, and enumerates the concrete outputs. It is clearly the aggregate 'free check' tool, distinguishable from the single-metric sibling calculators like prime_cost or break_even that compute one number.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys what the tool does but never states when to reach for it versus the many sibling calculators, nor any prerequisites beyond the inputs. Usage is only implied by the self-describing name and content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches RestaurantDoctorAI's sourced library: the website's guides and blog posts, RestaurantDoctorAI's step-by-step fixes, RestaurantDoctorAI's targets by type of restaurant, sourced industry facts, and an expert knowledge base of sourced how-tos, rules and checklists (costs, labor, money, growth, compliance, operations). Keyword search: "break-even", "breakeven" and "break even" are one term, and plurals match. Returns the best passages, each with its id, kind, title, link and source; kind narrows the search to one kind of entry. RestaurantDoctorAI's targets are its own, not industry benchmarks. The query isn't stored; only an anonymous daily count of searches and reads is kept.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Only this kind of entry: guide (the website's guides), post (blog posts), play (RestaurantDoctorAI's step-by-step fixes), targets (RestaurantDoctorAI's targets by type of restaurant), fact (sourced industry facts) or knowledge (sourced how-tos, rules and checklists). Left out, every kind. | |
| limit | No | How many passages to return, 1 to 8 (default 5). | |
| query | Yes | What to look up, in plain words, e.g. 'how to lower food cost', 'tip pool rules' or 'delivery app commission'. |
| Name | Required | Description |
|---|---|---|
| hits | Yes | Best match first. Empty when nothing matches. |
| note | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world. The description adds genuinely non-obvious behavior: keyword normalization ('break-even', 'breakeven', 'break even' are one term; plurals match), that only the best passages are returned, and a privacy note that queries aren't stored while an anonymous daily count of searches and reads is kept. That privacy and matching behavior is information the annotations cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The content scope is front-loaded in the first sentence, followed by search behavior, return shape, the targets caveat, and the privacy note. It is dense and runs long, but nearly every sentence carries information an agent could act on; only the enumeration of library contents and the brief return-field list have mild overlap with structured fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the description is not obligated to explain return values, and annotations carry the safety profile. With those covered, the remaining gap is routing guidance relative to list_knowledge and read_knowledge; otherwise the definition gives enough for an agent to call this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description goes beyond the schema by explaining the matching semantics of the query parameter (hyphen/space/plural equivalence) and by clarifying the meaning of the 'targets' kind ('RestaurantDoctorAI's targets are its own, not industry benchmarks'), which is a semantic distinction the enum description does not make.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (searches) and a well-defined resource (RestaurantDoctorAI's sourced library), enumerating exactly which content families it covers: guides, blog posts, step-by-step fixes, targets, sourced facts, and an expert knowledge base. This is far more specific than a generic 'search' tool, though it never names the closely related siblings (list_knowledge, read_knowledge) that an agent might otherwise confuse it with.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: the tool is a keyword search, and 'kind narrows the search to one kind of entry' hints at narrowing behavior. There is no explicit when-to-use, when-not-to-use, or routing to alternatives such as list_knowledge (browsing) or read_knowledge (fetching a specific entry), which are exactly the siblings an agent would need to disambiguate against.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Works out how a restaurant shares tips, two ways, as the free tip-out sheet on restaurantdoctorai.com does. method percent: a server's tip-out to support roles, each a percentage of the server's net sales or tips, with the total tip-out, what the server keeps from their tips, and an error-level check when the tip-out is more than the tips. method pool: a tip pool shared by hours, with optional points for each role, rounded to the cent with the rounding remainder placed on the largest share. Takes the figures in any currency; a figure that isn't sent is never counted as 0. Returns the split, how it was worked out, the Department of Labor's published points on tips with their sources, and a link to the free tip-out sheet. It only works out a split from the numbers sent; it doesn't say whether a tip-out or a tip pool is allowed. The figures aren't stored; only an anonymous daily count of calculator runs is kept.
| Name | Required | Description | Default |
|---|---|---|---|
| base | No | ||
| pool | No | ||
| tips | No | ||
| roles | No | ||
| method | Yes | percent: one server's tip-out to support roles, each a % of the base. pool: a tip pool shared by hours, with optional points. | |
| members | No | ||
| baseKind | No |
| Name | Required | Description |
|---|---|---|
| law | Yes | The Department of Labor's published points on tips and its state minimum wage page, each with its source. |
| link | Yes | The free tip-out sheet, to print or download. |
| pool | Yes | |
| notes | Yes | |
| checks | Yes | An error when the tip-out is more than the tips. |
| method | Yes | |
| result | Yes | The result in the sheet's words. |
| percent | Yes | |
| freeCheck | Yes | |
| workedOut | Yes | How it was worked out. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavior beyond the readOnly/idempotent/non-destructive annotations: rounding to the cent with remainder pushed onto the largest share, an error-level check when tip-out exceeds tips, currency-agnostic input, and the rule that an unsent figure is never counted as 0. It also discloses data handling ('figures aren't stored; only an anonymous daily count is kept'), which annotations do not cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the purpose and mode definitions before the return and privacy details, so the essential information comes first. It is dense but mostly earns its length; the recurring plug for the free tip-out sheet (mentioned twice) is mildly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter, single-required-field tool with an output schema, the description covers both modes, edge cases, and limitations well enough to invoke correctly without the output schema explaining returns. The only shortfall is the absence of sibling cross-references among the many restaurantdoctor_* calculators.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains how parameters interlock across modes — base vs. pool, baseKind determining whether percentages come off net sales or tips, and that omitted figures are ignored rather than zeroed. This adds real meaning beyond the field-level schema text, though it doesn't enumerate every constraint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — works out how a restaurant shares tips — and names the two modes (percent, pool) with a one-line definition of each. An agent can distinguish this from siblings like restaurantdoctor_fica_tip_credit without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context for each mode: percent is one server's tip-out to support roles off net sales or tips; pool is shared by hours with optional points. It also states a scope exclusion ('it doesn't say whether a tip-out or tip pool is allowed'), but never routes the agent to a sibling tool for related tip questions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
restaurantdoctor_deadlines1 field changedOutput schema / properties / checkWith / descriptionPrevious value: -"What we can't date for this owner: their own schedule or papers, or a state page not yet confirmed. Never a guessed date."New value: +"What we can't date for this owner: their own schedule or papers, or a state page not yet confirmed. No date here is guessed."restaurantdoctor_list_knowledge2 fields changedInput schema / properties / kind / descriptionPrevious value: -"Which kind of entry to list: guide (the website's guides), post (blog posts), play (the step-by-step fixes from the paid report's playbook), targets (RestaurantDoctorAI's targets by type of restaurant), fact (sourced industry facts) or knowledge (sourced how-tos, rules and checklists); or all (the default)."New value: +"Which kind of entry to list: guide (the website's guides), post (blog posts), play (RestaurantDoctorAI's step-by-step fixes), targets (RestaurantDoctorAI's targets by type of restaurant), fact (sourced industry facts) or knowledge (sourced how-tos, rules and checklists); or all (the default)."Output schema / properties / nextOffset / anyOfPrevious value: -[
- {
- "description": "Send it as offset for the next page.",
- "type": "number"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "description": "Where the next page starts: the offset of the next list.",
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]restaurantdoctor_menu_calories1 field changedInput schema / properties / ingredients / anyOfPrevious value: -[
- {
- "description": "What goes into the dish or batch, one entry each. Needed for a result; if missing, the reply asks for it.",
- "items": {
- "additionalProperties": false,
- "properties": {
- "amount": {
- "anyOf": [
- {
- "description": "How much goes in, after trimming, in unit. Weighed if possible. Needed for a result; if missing, the reply asks for it.",
- "maximum": 1000000000,
- "minimum": 0,
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "food": {
- "anyOf": [
- {
- "description": "The food: its name on the counter's list of USDA foods, as an earlier answer gave it, or the owner's words for it, matched to that list. Words that fit several foods, or none, come back as a tool error naming the foods to pick from, or saying it isn't on the list. With kcalPer100g, just its name.",
- "maxLength": 100,
- "minLength": 1,
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "kcalPer100g": {
- "anyOf": [
- {
- "description": "For a food not on the list: kcal per 100 g from the nutrition panel on the owner's own pack, as the owner reads it (a US label gives a serving: its calories ÷ its grams × 100). Never an estimate by the assistant: if the owner has no label, the ingredient can't be counted yet. Weighed only.",
- "maximum": 900,
- "minimum": 0,
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "unit": {
- "description": "g, kg, oz or lb for any food. ml, l, floz, cup, tbsp or tsp (US measures) for liquids and fats only; each for foods counted by the piece.",
- "enum": [
- "g",
- "kg",
- "oz",
- "lb",
- "ml",
- "l",
- "floz",
- "cup",
- "tbsp",
- "tsp",
- "each"
- ],
- "type": "string"
- }
- },
- "required": [
- "unit"
- ],
- "type": "object"
- },
- "maxItems": 30,
- "type": "array"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "description": "What goes into the dish or batch, one entry each. Needed for a result; if missing, the reply asks for it.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "amount": {
+ "anyOf": [
+ {
+ "description": "How much goes in, after trimming, in unit. Weighed if possible. Needed for a result; if missing, the reply asks for it.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "food": {
+ "anyOf": [
+ {
+ "description": "The food: its name on the counter's list of USDA foods, as an earlier answer gave it, or the owner's words for it, matched to that list. Words that fit several foods, or none, come back as a tool error naming the foods to pick from, or saying it isn't on the list. With kcalPer100g, just its name.",
+ "maxLength": 100,
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "kcalPer100g": {
+ "anyOf": [
+ {
+ "description": "For a food not on the list: kcal per 100 g from the nutrition panel on the owner's own pack, as the owner reads it (a US label gives a serving: its calories ÷ its grams × 100). It's the label's figure, not an estimate by the assistant: without the owner's label, the ingredient can't be counted yet. Weighed only.",
+ "maximum": 900,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "unit": {
+ "description": "g, kg, oz or lb for any food. ml, l, floz, cup, tbsp or tsp (US measures) for liquids and fats only; each for foods counted by the piece.",
+ "enum": [
+ "g",
+ "kg",
+ "oz",
+ "lb",
+ "ml",
+ "l",
+ "floz",
+ "cup",
+ "tbsp",
+ "tsp",
+ "each"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "unit"
+ ],
+ "type": "object"
+ },
+ "maxItems": 30,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+]restaurantdoctor_par_levels1 field changedOutput schema / properties / items / items / properties / par / anyOfPrevious value: -[
- {
- "description": "Use per day × days covered + safety, rounded up to 0.01.",
- "type": "number"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "description": "The use per day × days covered + safety, rounded up to 0.01.",
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]restaurantdoctor_plate_cost1 field changedInput schema / properties / ingredients / anyOfPrevious value: -[
- {
- "description": "With mode ingredients: each ingredient. A sauce or side already costed is one: its cost for a pack of 1 each, 1 each used.",
- "items": {
- "additionalProperties": false,
- "properties": {
- "name": {
- "anyOf": [
- {
- "description": "Optional: what it is, as the owner calls it.",
- "maxLength": 100,
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "packSize": {
- "anyOf": [
- {
- "description": "How much one pack holds, in packUnit: 5 for a 5 lb bag. A case of 6 cans is 6 each; a 4 × 5 lb case is 20 lb.",
- "exclusiveMinimum": 0,
- "maximum": 1000000000,
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "packUnit": {
- "description": "The pack's unit: floz and gal are US fluid ounces and gallons.",
- "enum": [
- "g",
- "kg",
- "oz",
- "lb",
- "ml",
- "l",
- "floz",
- "gal",
- "each"
- ],
- "type": "string"
- },
- "paid": {
- "anyOf": [
- {
- "description": "What the owner paid for one pack, from their latest invoice, before any VAT or GST they claim back.",
- "maximum": 1000000000,
- "minimum": 0,
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "usable": {
- "anyOf": [
- {
- "description": "Optional: of what's bought, the % left after trimming or cooking: 85 for 1 kg that trims to 850 g. Left out, 100.",
- "maximum": 100,
- "minimum": 1,
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "used": {
- "anyOf": [
- {
- "description": "The amount that goes in the pot or on the plate, after trimming, for the plates in portions. Spoons or cups: weigh it once.",
- "maximum": 1000000000,
- "minimum": 0,
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "usedUnit": {
- "description": "The amount's unit, of the pack's kind: weight, volume and count don't convert into each other.",
- "enum": [
- "g",
- "kg",
- "oz",
- "lb",
- "ml",
- "l",
- "floz",
- "gal",
- "each"
- ],
- "type": "string"
- }
- },
- "required": [
- "packUnit",
- "usedUnit"
- ],
- "type": "object"
- },
- "maxItems": 30,
- "type": "array"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "description": "With mode ingredients: each ingredient. A sauce or side already costed is one: its cost for a pack of 1 each, 1 each used.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "anyOf": [
+ {
+ "description": "Optional: what it is, as the owner calls it.",
+ "maxLength": 100,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "packSize": {
+ "anyOf": [
+ {
+ "description": "How much one pack holds, in packUnit: 5 for a 5 lb bag. A case of 6 cans is 6 each; a 4 × 5 lb case is 20 lb.",
+ "exclusiveMinimum": 0,
+ "maximum": 1000000000,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "packUnit": {
+ "description": "The pack's unit: floz and gal are US fluid ounces and gallons.",
+ "enum": [
+ "g",
+ "kg",
+ "oz",
+ "lb",
+ "ml",
+ "l",
+ "floz",
+ "gal",
+ "each"
+ ],
+ "type": "string"
+ },
+ "paid": {
+ "anyOf": [
+ {
+ "description": "What the owner paid for one pack, from their latest invoice, before any VAT or GST they claim back.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "usable": {
+ "anyOf": [
+ {
+ "description": "Optional: of what's bought, the % left after trimming or cooking: 85 for 1 kg that trims to 850 g. Left out, 100.",
+ "maximum": 100,
+ "minimum": 1,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "used": {
+ "anyOf": [
+ {
+ "description": "The amount that goes in the pot or on the plate, after trimming, for the plates in portions. Spoons or cups: weighed once.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "usedUnit": {
+ "description": "The amount's unit, of the pack's kind: weight, volume and count don't convert into each other.",
+ "enum": [
+ "g",
+ "kg",
+ "oz",
+ "lb",
+ "ml",
+ "l",
+ "floz",
+ "gal",
+ "each"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "packUnit",
+ "usedUnit"
+ ],
+ "type": "object"
+ },
+ "maxItems": 30,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+]restaurantdoctor_run_free_check3 fields changedOutput schema / properties / fullReportRemoved value: -{
- "additionalProperties": false,
- "properties": {
- "note": {
- "type": "string"
- },
- "prices": {
- "anyOf": [
- {
- "additionalProperties": false,
- "properties": {
- "premium": {
- "anyOf": [
- {
- "description": "With the owner's own numbers and a check-up.",
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "standard": {
- "type": "string"
- }
- },
- "required": [
- "standard",
- "premium"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "description": "null when they couldn't be read."
- }
- },
- "required": [
- "note",
- "prices"
- ],
- "type": "object"
-}Output schema / properties / fullReportAddsRemoved value: -{
- "description": "What the paid full report adds.",
- "items": {
- "type": "string"
- },
- "type": "array"
-}Output schema / requiredPrevious value: -[
- "country",
- "countryName",
- "grade",
- "risk",
- "needsAttention",
- "needsAttentionText",
- "areas",
- "areasNote",
- "monthlyLeak",
- "yearlyLeak",
- "leakText",
- "biggest",
- "primePoint",
- "notes",
- "dayOneFix",
- "link",
- "fullReport",
- "fullReportAdds",
- "disclaimer"
-]New value: +[
+ "country",
+ "countryName",
+ "grade",
+ "risk",
+ "needsAttention",
+ "needsAttentionText",
+ "areas",
+ "areasNote",
+ "monthlyLeak",
+ "yearlyLeak",
+ "leakText",
+ "biggest",
+ "primePoint",
+ "notes",
+ "dayOneFix",
+ "link",
+ "disclaimer"
+]restaurantdoctor_search_knowledge1 field changedInput schema / properties / kind / descriptionPrevious value: -"Only this kind of entry: guide (the website's guides), post (blog posts), play (the step-by-step fixes from the paid report's playbook), targets (RestaurantDoctorAI's targets by type of restaurant), fact (sourced industry facts) or knowledge (sourced how-tos, rules and checklists). Left out, every kind."New value: +"Only this kind of entry: guide (the website's guides), post (blog posts), play (RestaurantDoctorAI's step-by-step fixes), targets (RestaurantDoctorAI's targets by type of restaurant), fact (sourced industry facts) or knowledge (sourced how-tos, rules and checklists). Left out, every kind."restaurantdoctor_cost_recipe1 field changedInput schema / properties / recipe / descriptionPrevious value: -"The recipe as written: its name, its servings line (\"Serves 6\") and its ingredient lines, one a line, each amount and unit exactly as the recipe or the photo gives it. Method steps may follow under a heading such as \"Instructions\"; only ingredient lines are costed. Don't convert, round or correct anything: the owner checks the lines on the website. At most 8000 characters and 60 ingredient lines."New value: +"The recipe as written: its name, its servings line (\"Serves 6\") and its ingredient lines, one a line, each amount and unit exactly as the recipe or the photo gives it. Method steps may follow under a heading such as \"Instructions\"; only ingredient lines are costed. The lines are read as sent, not converted, rounded or corrected: the owner checks them on the website. At most 8000 characters and 60 ingredient lines."restaurantdoctor_fica_tip_credit1 field changedInput schema / properties / reportedTips / anyOfPrevious value: -[
- {
- "description": "A year's tips reported through payroll for one business, in US dollars: line 5b of the year's four Forms 941 added up, W-2 box 7 totals, or the year's total from the payroll tips report (Toast, Gusto). Never service charges, automatic gratuities or delivery fees: they're wages. Needed for a result; if missing, the reply asks for it.",
- "maximum": 1000000000,
- "minimum": 0,
- "type": "number"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "description": "A year's tips reported through payroll for one business, in US dollars: line 5b of the year's four Forms 941 added up, W-2 box 7 totals, or the year's total from the payroll tips report (Toast, Gusto). Service charges, automatic gratuities and delivery fees don't count: they're wages. Needed for a result; if missing, the reply asks for it.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]restaurantdoctor_list_knowledge1 field changedInput schema / properties / offset / descriptionPrevious value: -"How many entries to skip (default 0). Send the nextOffset a list gave for the next page."New value: +"How many entries to skip (default 0). The next page starts at the nextOffset the previous list returned."restaurantdoctor_read_knowledge1 field changedInput schema / properties / offset / descriptionPrevious value: -"Where to start, in characters (default 0, the start). A long entry comes 8,000 characters at a time: send the nextOffset a read gave for the next part."New value: +"Where to start, in characters (default 0, the start). A long entry comes 8,000 characters at a time: the next part starts at the nextOffset the previous read returned."restaurantdoctor_booking_fees1 field changedOutput schema / properties / headline / descriptionPrevious value: -"Show it first."New value: +"The result in one sentence."restaurantdoctor_get_questions1 field changedOutput schema / properties / questions / items / properties / key / descriptionPrevious value: -"The answer's name in restaurantdoctor_run_free_check."New value: +"The answer's name, as the free check takes it."restaurantdoctor_list_knowledge1 field changedOutput schema / properties / entries / items / properties / id / descriptionPrevious value: -"The entry's id, for restaurantdoctor_read_knowledge."New value: +"The entry's id, which reading the entry in full takes."restaurantdoctor_par_levels1 field changedInput schema / properties / items / anyOfPrevious value: -[
- {
- "description": "Needed: the items, up to 50.",
- "items": {
- "additionalProperties": false,
- "properties": {
- "daysCovered": {
- "anyOf": [
- {
- "description": "This item's days covered. Left out, the list's daysCovered.",
- "exclusiveMinimum": 0,
- "maximum": 60,
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "name": {
- "anyOf": [
- {
- "description": "Optional: the item.",
- "maxLength": 60,
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "onHand": {
- "anyOf": [
- {
- "description": "Units on hand when the order is placed. Needed.",
- "maximum": 1000000000,
- "minimum": 0,
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "packSize": {
- "anyOf": [
- {
- "description": "Optional: units in one pack. With it, the order is whole packs.",
- "exclusiveMinimum": 0,
- "maximum": 1000000000,
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "safety": {
- "anyOf": [
- {
- "description": "Optional: units kept on top for a busy day or a late truck. Left out, 0.",
- "maximum": 1000000000,
- "minimum": 0,
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "unit": {
- "anyOf": [
- {
- "description": "Optional: the unit, such as lb or each.",
- "maxLength": 60,
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "usePerDay": {
- "anyOf": [
- {
- "description": "Units used in a day open. Needed, or usePerWeek.",
- "maximum": 1000000000,
- "minimum": 0,
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "usePerWeek": {
- "anyOf": [
- {
- "description": "Units used in a week: divided by daysOpenPerWeek. Not used when usePerDay is sent.",
- "maximum": 1000000000,
- "minimum": 0,
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "type": "object"
- },
- "maxItems": 50,
- "type": "array"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "description": "Needed: the items, up to 50.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "daysCovered": {
+ "anyOf": [
+ {
+ "description": "This item's days covered. Left out, the list's daysCovered.",
+ "exclusiveMinimum": 0,
+ "maximum": 60,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "name": {
+ "anyOf": [
+ {
+ "description": "Optional: the item.",
+ "maxLength": 60,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "onHand": {
+ "anyOf": [
+ {
+ "description": "Units on hand when the order is placed. Needed.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "packSize": {
+ "anyOf": [
+ {
+ "description": "Optional: units in one pack, to 3 decimals. With it, the order is whole packs.",
+ "exclusiveMinimum": 0,
+ "maximum": 1000000000,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "safety": {
+ "anyOf": [
+ {
+ "description": "Optional: units kept on top for a busy day or a late truck. Left out, 0.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "unit": {
+ "anyOf": [
+ {
+ "description": "Optional: the unit, such as lb or each.",
+ "maxLength": 60,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "usePerDay": {
+ "anyOf": [
+ {
+ "description": "Units used in a day open. Needed, or usePerWeek.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "usePerWeek": {
+ "anyOf": [
+ {
+ "description": "Units used in a week: divided by daysOpenPerWeek. Not used when usePerDay is sent.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "maxItems": 50,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+]restaurantdoctor_read_knowledge2 fields changedOutput schema / properties / id / descriptionPrevious value: -"The entry's id, for restaurantdoctor_read_knowledge."New value: +"The entry's id, which reading the entry in full takes."Output schema / properties / nextOffset / anyOfPrevious value: -[
- {
- "description": "Where the next part starts: send it as offset to restaurantdoctor_read_knowledge.",
- "type": "number"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "description": "Where the next part starts, in characters: the offset of the next read.",
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]restaurantdoctor_restaurant_budget2 fields changedOutput schema / properties / left / descriptionPrevious value: -"Left over after every bill, before income tax; low is the budget at the top of the targets. Never call it profit."New value: +"Left over after every bill, before income tax, not profit; low is the budget at the top of the targets."Output schema / properties / rent / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "description": "The owner's rent against the occupancy range.",
- "properties": {
- "band": {
- "enum": [
- "under",
- "inside",
- "over"
- ],
- "type": "string"
- },
- "pct": {
- "type": "number"
- }
- },
- "required": [
- "pct",
- "band"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "description": "The owner's rent against the occupancy ceiling, the top of the range: within it or over it.",
+ "properties": {
+ "band": {
+ "enum": [
+ "within",
+ "over"
+ ],
+ "type": "string"
+ },
+ "pct": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "pct",
+ "band"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]restaurantdoctor_search_knowledge1 field changedOutput schema / properties / hits / items / properties / id / descriptionPrevious value: -"The entry's id, for restaurantdoctor_read_knowledge."New value: +"The entry's id, which reading the entry in full takes."restaurantdoctor_cash_outrestaurantdoctor_par_levelsrestaurantdoctor_tip_outrestaurantdoctor_break_even27 fields changedInput schema / properties / averageSpend / anyOfPrevious value: -[
- {
- "description": "Optional: average spend per guest, the POS average check or net sales ÷ guests or orders. Turns sales into guests.",
- "maximum": 1000000000,
- "minimum": 0,
- "type": "number"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "description": "Optional: average spend per guest, the POS average check or net sales ÷ guests. Turns sales into guests.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / daysPerWeek / anyOfPrevious value: -[
- {
- "description": "Optional: days open a week, a whole number from 1 to 7. Turns the month into sales a day open (and guests a day, with averageSpend); left out, the day figures are left out.",
- "maximum": 7,
- "minimum": 1,
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "description": "Optional: days open a week, a whole number from 1 to 7. Turns the month into a day open (and guests a day, with averageSpend).",
+ "maximum": 7,
+ "minimum": 1,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / fixedBills / anyOfPrevious value: -[
- {
- "description": "A month of the bills that stay the same however busy it is: rent and utilities, salaries with their payroll taxes and benefits, insurance, software, marketing, loan and lease payments in full, and the owner's own pay if it isn't on payroll (left out, break-even assumes they work for free). No depreciation. Yearly bills ÷ 12. Needed for a result; if missing, the reply asks for it.",
- "maximum": 1000000000,
- "minimum": 0,
- "type": "number"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "description": "A month of the bills that stay the same: rent and utilities, salaries with their payroll taxes and benefits, insurance, software, marketing, loan and lease payments in full. No depreciation. Yearly bills ÷ 12. Not the owner's pay. Needed; if missing, the reply asks for it.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / goal / anyOfPrevious value: -[
- {
- "description": "Optional: what the owner would like left over each month after every bill, before income tax. Adds the sales a month that would take.",
- "maximum": 1000000000,
- "minimum": 0,
- "type": "number"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "description": "Optional: what the owner would like left over a month after every bill, before income tax. Adds the sales for it.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / hourly / anyOfPrevious value: -[
- {
- "description": "Whether hourly staff time goes up and down with sales: yes if shifts are added and cut as it gets busy or quiet; no if about the same team works every shift, so hourly pay is a bill that stays the same; unsure (the default) works it out both ways, as a range.",
- "enum": [
- "yes",
- "no",
- "unsure"
- ],
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "description": "Whether hourly staff time goes up and down with sales: yes, shifts are added and cut as it gets busy or quiet; no, about the same team every shift (a bill that stays the same); unsure (the default): both ways, as a range.",
+ "enum": [
+ "yes",
+ "no",
+ "unsure"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / hourlyPay / anyOfPrevious value: -[
- {
- "description": "That month's hourly wages from payroll, plus the employer's payroll taxes and benefits on them; no tips. Paid every two weeks: one pay run × 26 ÷ 12. Needed for a result (0 with no hourly staff); if missing, the reply asks for it.",
- "maximum": 1000000000,
- "minimum": 0,
- "type": "number"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "description": "That month's hourly wages from payroll, plus the employer's payroll taxes and benefits; no tips. Paid every two weeks: one pay run × 26 ÷ 12. Needed (0 with no hourly staff); if missing, the reply asks for it.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / openingStock / anyOfPrevious value: -[
- {
- "description": "Optional: stock at cost at the start of the month. Used only with closingStock: food and drink then becomes what was used, opening + purchases - closing. Skip both if stock stayed about the same.",
- "maximum": 1000000000,
- "minimum": 0,
- "type": "number"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "description": "Optional: stock at cost at the start of the month. Used only with closingStock: food and drink is then opening + purchases - closing. Skip both if stock stayed steady.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / otherVariable / anyOfPrevious value: -[
- {
- "description": "That month's other costs that rise with every sale: card fees, delivery app commissions (app sales minus payouts, both without tax and tips), to-go packaging, any percentage rent, royalties or ad fund fees. Nothing already in the food and drink invoices. Needed for a result (0 if none); if missing, the reply asks for it.",
- "maximum": 1000000000,
- "minimum": 0,
- "type": "number"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "description": "That month's other costs that rise with every sale: card fees, app commissions (app sales minus payouts, without tax and tips), packaging, percentage rent, royalties, ad fund fees; nothing in the food and drink invoices. Needed (0 if none); if missing, the reply asks for it.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / ownerPayAdded value: +{
+ "anyOf": [
+ {
+ "description": "Optional: the owner's own pay a month, if not on payroll. Counted as a bill; break-even is also given without it.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Input schema / properties / purchases / anyOfPrevious value: -[
- {
- "description": "That month's food and drink supplier invoices, added up by delivery date. Needed for a result; if missing, the reply asks for it.",
- "maximum": 1000000000,
- "minimum": 0,
- "type": "number"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "description": "That month's food and drink supplier invoices, by delivery date. Needed; if missing, the reply asks for it.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / sales / anyOfPrevious value: -[
- {
- "description": "Net sales for one typical month, in the owner's own currency like every figure here: the POS sales summary, before tax and tips, delivery app orders at menu price. Not a holiday rush or a one-off: every figure is for that same month. Needed for a result, and more than 0; if missing, the reply asks for it.",
- "maximum": 1000000000,
- "minimum": 0,
- "type": "number"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "description": "Net sales for one typical month, in the owner's own currency: the POS sales summary, before tax and tips, app orders at menu price. Not a holiday rush: every figure is for that month. Needed, more than 0; if missing, the reply asks for it.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / checks / descriptionPrevious value: -"Figures that look like a slip, as the page flags them."New value: +"Figures that look like a slip."Output schema / properties / figures / properties / foodAndDrink / descriptionPrevious value: -"Used: opening + purchases - closing with both stock counts, else purchases."New value: +"Opening + purchases - closing with both stock counts, else purchases."Output schema / properties / figures / properties / ownerPayAdded value: +{
+ "anyOf": [
+ {
+ "description": "Null: not sent.",
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / figures / requiredPrevious value: -[
- "sales",
- "foodAndDrink",
- "hourlyPay",
- "otherVariable",
- "fixedBills"
-]New value: +[
+ "sales",
+ "foodAndDrink",
+ "hourlyPay",
+ "otherVariable",
+ "fixedBills",
+ "ownerPay"
+]Output schema / properties / leftOver / descriptionPrevious value: -"Left over after every bill at this month's sales, before income tax, to the unit: below 0 when short. Never call it profit."New value: +"Left over after every bill and ownerPay at these sales, before income tax: below 0 when short. Not profit."Output schema / properties / pointValue / descriptionPrevious value: -"1% of sales, to the unit: what each point of cost saved leaves a month."New value: +"1% of sales: what a point of cost saved leaves a month."Output schema / properties / result / descriptionPrevious value: -"The result in the page's words, in its order."New value: +"The page's result, line by line."Output schema / properties / scenarios / descriptionPrevious value: -"Hourly pay one way, or both (rising first) when the owner isn't sure and has hourly pay."New value: +"Hourly pay one way, or both (rising first)."Output schema / properties / scenarios / items / properties / breakEven / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "description": "Sales and guests rounded up to the unit, the rest to the nearest, as the page shows them. Null: no amount of sales breaks even this way.",
- "properties": {
- "cushion": {
- "description": "Net sales minus break-even: below 0 when short.",
- "type": "number"
- },
- "cushionPct": {
- "description": "The cushion, % of net sales, one decimal.",
- "type": "number"
- },
- "dayOpen": {
- "anyOf": [
- {
- "description": "Needs daysPerWeek.",
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "goalSales": {
- "anyOf": [
- {
- "description": "Sales a month to have the goal left over. Needs goal.",
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "guestsADay": {
- "anyOf": [
- {
- "description": "Needs daysPerWeek and averageSpend.",
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "guestsAMonth": {
- "anyOf": [
- {
- "description": "Needs averageSpend.",
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "monthly": {
- "type": "number"
- },
- "moreGuestsADay": {
- "anyOf": [
- {
- "description": "When short, with daysPerWeek and averageSpend: the guests a day that close it.",
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "perThousandOffBills": {
- "description": "The same, for each 1,000 a month off fixedBills.",
- "type": "number"
- },
- "pointOffFixed": {
- "description": "The same, for one point off a fixed bill (salaries).",
- "type": "number"
- },
- "pointOffRising": {
- "description": "How far break-even falls a month for one point of sales off a rising cost.",
- "type": "number"
- },
- "shortADayOpen": {
- "anyOf": [
- {
- "description": "When short, with daysPerWeek: the gap a day open.",
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "weekly": {
- "type": "number"
- }
- },
- "required": [
- "monthly",
- "weekly",
- "dayOpen",
- "guestsADay",
- "guestsAMonth",
- "cushion",
- "cushionPct",
- "shortADayOpen",
- "moreGuestsADay",
- "goalSales",
- "pointOffRising",
- "pointOffFixed",
- "perThousandOffBills"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "description": "Sales and guests rounded up, the rest to the nearest unit. Null: never breaks even this way.",
+ "properties": {
+ "cushion": {
+ "description": "Net sales minus break-even.",
+ "type": "number"
+ },
+ "cushionPct": {
+ "description": "The cushion, % of net sales.",
+ "type": "number"
+ },
+ "dayOpen": {
+ "anyOf": [
+ {
+ "description": "Needs daysPerWeek.",
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "goalSales": {
+ "anyOf": [
+ {
+ "description": "Sales a month for the goal. Needs goal.",
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "guestsADay": {
+ "anyOf": [
+ {
+ "description": "Needs daysPerWeek and averageSpend.",
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "guestsADayWithoutPay": {
+ "anyOf": [
+ {
+ "description": "Needs ownerPay, daysPerWeek, averageSpend.",
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "guestsAMonth": {
+ "anyOf": [
+ {
+ "description": "Needs averageSpend.",
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "monthly": {
+ "type": "number"
+ },
+ "moreGuestsADay": {
+ "anyOf": [
+ {
+ "description": "When short, with daysPerWeek and averageSpend: guests a day to close it.",
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "perThousandOffBills": {
+ "description": "The same, 1,000 a month off the bills.",
+ "type": "number"
+ },
+ "pointOffFixed": {
+ "description": "The same, a point off a fixed bill.",
+ "type": "number"
+ },
+ "pointOffRising": {
+ "description": "Fall in break-even for a point of sales off a rising cost.",
+ "type": "number"
+ },
+ "shortADayOpen": {
+ "anyOf": [
+ {
+ "description": "When short, with daysPerWeek: the gap a day open.",
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "weekly": {
+ "type": "number"
+ },
+ "withoutPay": {
+ "anyOf": [
+ {
+ "description": "Without ownerPay. Needs it.",
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "monthly",
+ "weekly",
+ "dayOpen",
+ "guestsADay",
+ "guestsAMonth",
+ "withoutPay",
+ "guestsADayWithoutPay",
+ "cushion",
+ "cushionPct",
+ "shortADayOpen",
+ "moreGuestsADay",
+ "goalSales",
+ "pointOffRising",
+ "pointOffFixed",
+ "perThousandOffBills"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / scenarios / items / properties / costsThatRisePct / descriptionPrevious value: -"% of net sales, one decimal. At 100 or more, no amount of sales breaks even."New value: +"% of net sales. At 100 or more, it never breaks even."Output schema / properties / scenarios / items / properties / hourlyPay / descriptionPrevious value: -"With the costs that rise with sales, or as a fixed bill."New value: +"Rising with sales, or a fixed bill."Output schema / properties / scenarios / items / properties / pricesAdded value: +{
+ "description": "Prices -10%, as now, +10%: same guests, plates, hourly pay, bills. An illustration.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "changePct": {
+ "type": "number"
+ },
+ "guestsADay": {
+ "anyOf": [
+ {
+ "description": "Needs daysPerWeek, averageSpend.",
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "monthly": {
+ "anyOf": [
+ {
+ "description": "Null: never.",
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "changePct",
+ "monthly",
+ "guestsADay"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / scenarios / items / requiredPrevious value: -[
- "hourlyPay",
- "costsThatRisePct",
- "breakEven"
-]New value: +[
+ "hourlyPay",
+ "costsThatRisePct",
+ "breakEven",
+ "prices"
+]Output schema / properties / standing / descriptionPrevious value: -"Net sales against break-even (at: almost exactly); never: no amount of sales breaks even, either way."New value: +"Net sales against break-even (at: almost exactly; never: no break-even either way)."Output schema / properties / whatIfAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / requiredPrevious value: -[
- "hourly",
- "standing",
- "figures",
- "usedStockCounts",
- "daysAMonth",
- "scenarios",
- "leftOver",
- "pointValue",
- "result",
- "checks",
- "notes",
- "workedOut",
- "link",
- "freeCheck"
-]New value: +[
+ "hourly",
+ "standing",
+ "figures",
+ "usedStockCounts",
+ "daysAMonth",
+ "scenarios",
+ "leftOver",
+ "pointValue",
+ "result",
+ "checks",
+ "whatIf",
+ "notes",
+ "workedOut",
+ "link",
+ "freeCheck"
+]restaurantdoctor_read_knowledge1 field changedInput schema / properties / id / descriptionPrevious value: -"An entry id from restaurantdoctor_search_knowledge or restaurantdoctor_list_knowledge, e.g. 'guide:restaurant-prime-cost' or 'post:restaurant-break-even-point'."New value: +"An entry id, as the library's search and list give it, e.g. 'guide:restaurant-prime-cost' or 'post:restaurant-break-even-point'."restaurantdoctor_run_free_check1 field changedInput schema / properties / monthlyRevenue / descriptionPrevious value: -"About how much do you sell in a typical month? Amounts are in US dollars, or in the local currency where that's the euro, pound sterling, Swiss franc, or Canadian, Australian or New Zealand dollar; restaurantdoctor_get_questions shows the exact ranges for a country. under_25k = Under $25,000 (Under $300K a year); 25k_60k = $25,000 – $60,000 ($300K – $720K a year); 60k_120k = $60,000 – $120,000 ($720K – $1.44M a year); 120k_200k = $120,000 – $200,000 ($1.44M – $2.4M a year); over_200k = Over $200,000 (Over $2.4M a year)."New value: +"About how much do you sell in a typical month? Amounts are in US dollars, or in the local currency where that's the euro, pound sterling, Swiss franc, or Canadian, Australian or New Zealand dollar. under_25k = Under $25,000 (Under $300K a year); 25k_60k = $25,000 – $60,000 ($300K – $720K a year); 60k_120k = $60,000 – $120,000 ($720K – $1.44M a year); 120k_200k = $120,000 – $200,000 ($1.44M – $2.4M a year); over_200k = Over $200,000 (Over $2.4M a year)."restaurantdoctor_card_fees3 fields changedInput schema / properties / format / descriptionPrevious value: -"The type of restaurant, which sets the likely mix of debit and credit cards: quick_service = Quick service (Counter or kiosk, fast turnover); fast_casual = Fast casual (Order at the counter, food brought to the table); full_service = Full service / casual dining (Servers, moderate check); fine_dining = Fine dining (Chef-driven, higher check); bar_lounge = Bar, taproom or lounge (Drinks are about half of sales or more)."New value: +"The type of restaurant, which sets the likely mix of debit and credit cards: quick_service = Quick service (Counter or kiosk, fast turnover); fast_casual = Fast casual (Order at the counter, food brought to the table); full_service = Full service / casual dining (Servers, moderate check); fine_dining = Fine dining (Chef-driven, higher check); bar_lounge = Bar, taproom or lounge (Drinks are about half of sales or more); cafe = Café or coffee shop (Drinks lead, with pastries and light food)."Input schema / properties / format / enumPrevious value: -[
- "quick_service",
- "fast_casual",
- "full_service",
- "fine_dining",
- "bar_lounge"
-]New value: +[
+ "quick_service",
+ "fast_casual",
+ "full_service",
+ "fine_dining",
+ "bar_lounge",
+ "cafe"
+]Output schema / properties / format / enumPrevious value: -[
- "quick_service",
- "fast_casual",
- "full_service",
- "fine_dining",
- "bar_lounge"
-]New value: +[
+ "quick_service",
+ "fast_casual",
+ "full_service",
+ "fine_dining",
+ "bar_lounge",
+ "cafe"
+]restaurantdoctor_labor_cost3 fields changedInput schema / properties / format / descriptionPrevious value: -"The type of restaurant, which sets the labor range and the starting target: quick_service = Quick service (Counter or kiosk, fast turnover); fast_casual = Fast casual (Order at the counter, food brought to the table); full_service = Full service / casual dining (Servers, moderate check); fine_dining = Fine dining (Chef-driven, higher check); bar_lounge = Bar, taproom or lounge (Drinks are about half of sales or more)."New value: +"The type of restaurant, which sets the labor range and the starting target: quick_service = Quick service (Counter or kiosk, fast turnover); fast_casual = Fast casual (Order at the counter, food brought to the table); full_service = Full service / casual dining (Servers, moderate check); fine_dining = Fine dining (Chef-driven, higher check); bar_lounge = Bar, taproom or lounge (Drinks are about half of sales or more); cafe = Café or coffee shop (Drinks lead, with pastries and light food)."Input schema / properties / format / enumPrevious value: -[
- "quick_service",
- "fast_casual",
- "full_service",
- "fine_dining",
- "bar_lounge"
-]New value: +[
+ "quick_service",
+ "fast_casual",
+ "full_service",
+ "fine_dining",
+ "bar_lounge",
+ "cafe"
+]Output schema / properties / format / enumPrevious value: -[
- "quick_service",
- "fast_casual",
- "full_service",
- "fine_dining",
- "bar_lounge"
-]New value: +[
+ "quick_service",
+ "fast_casual",
+ "full_service",
+ "fine_dining",
+ "bar_lounge",
+ "cafe"
+]restaurantdoctor_plate_cost3 fields changedInput schema / properties / format / descriptionPrevious value: -"The type of restaurant, which sets the food cost range and the starting target: quick_service = Quick service (Counter or kiosk, fast turnover); fast_casual = Fast casual (Order at the counter, food brought to the table); full_service = Full service / casual dining (Servers, moderate check); fine_dining = Fine dining (Chef-driven, higher check); bar_lounge = Bar, taproom or lounge (Drinks are about half of sales or more)."New value: +"The type of restaurant, which sets the food cost range and the starting target: quick_service = Quick service (Counter or kiosk, fast turnover); fast_casual = Fast casual (Order at the counter, food brought to the table); full_service = Full service / casual dining (Servers, moderate check); fine_dining = Fine dining (Chef-driven, higher check); bar_lounge = Bar, taproom or lounge (Drinks are about half of sales or more); cafe = Café or coffee shop (Drinks lead, with pastries and light food)."Input schema / properties / format / enumPrevious value: -[
- "quick_service",
- "fast_casual",
- "full_service",
- "fine_dining",
- "bar_lounge"
-]New value: +[
+ "quick_service",
+ "fast_casual",
+ "full_service",
+ "fine_dining",
+ "bar_lounge",
+ "cafe"
+]Output schema / properties / format / enumPrevious value: -[
- "quick_service",
- "fast_casual",
- "full_service",
- "fine_dining",
- "bar_lounge"
-]New value: +[
+ "quick_service",
+ "fast_casual",
+ "full_service",
+ "fine_dining",
+ "bar_lounge",
+ "cafe"
+]restaurantdoctor_prime_cost3 fields changedInput schema / properties / format / descriptionPrevious value: -"The type of restaurant, which sets the targets: prime cost, and the ranges for food and drink and for labor: quick_service = Quick service (Counter or kiosk, fast turnover); fast_casual = Fast casual (Order at the counter, food brought to the table); full_service = Full service / casual dining (Servers, moderate check); fine_dining = Fine dining (Chef-driven, higher check); bar_lounge = Bar, taproom or lounge (Drinks are about half of sales or more)."New value: +"The type of restaurant, which sets the targets: prime cost, and the ranges for food and drink and for labor: quick_service = Quick service (Counter or kiosk, fast turnover); fast_casual = Fast casual (Order at the counter, food brought to the table); full_service = Full service / casual dining (Servers, moderate check); fine_dining = Fine dining (Chef-driven, higher check); bar_lounge = Bar, taproom or lounge (Drinks are about half of sales or more); cafe = Café or coffee shop (Drinks lead, with pastries and light food)."Input schema / properties / format / enumPrevious value: -[
- "quick_service",
- "fast_casual",
- "full_service",
- "fine_dining",
- "bar_lounge"
-]New value: +[
+ "quick_service",
+ "fast_casual",
+ "full_service",
+ "fine_dining",
+ "bar_lounge",
+ "cafe"
+]Output schema / properties / format / enumPrevious value: -[
- "quick_service",
- "fast_casual",
- "full_service",
- "fine_dining",
- "bar_lounge"
-]New value: +[
+ "quick_service",
+ "fast_casual",
+ "full_service",
+ "fine_dining",
+ "bar_lounge",
+ "cafe"
+]restaurantdoctor_restaurant_budgetrestaurantdoctor_run_free_check2 fields changedInput schema / properties / serviceModel / descriptionPrevious value: -"What kind of restaurant do you run? quick_service = Quick service (Counter or kiosk, fast turnover); fast_casual = Fast casual (Order at the counter, food brought to the table); full_service = Full service / casual dining (Servers, moderate check); fine_dining = Fine dining (Chef-driven, higher check); bar_lounge = Bar, taproom or lounge (Drinks are about half of sales or more)."New value: +"What kind of restaurant do you run? quick_service = Quick service (Counter or kiosk, fast turnover); fast_casual = Fast casual (Order at the counter, food brought to the table); full_service = Full service / casual dining (Servers, moderate check); fine_dining = Fine dining (Chef-driven, higher check); bar_lounge = Bar, taproom or lounge (Drinks are about half of sales or more); cafe = Café or coffee shop (Drinks lead, with pastries and light food)."Input schema / properties / serviceModel / enumPrevious value: -[
- "quick_service",
- "fast_casual",
- "full_service",
- "fine_dining",
- "bar_lounge"
-]New value: +[
+ "quick_service",
+ "fast_casual",
+ "full_service",
+ "fine_dining",
+ "bar_lounge",
+ "cafe"
+]restaurantdoctor_check_website1 field changedOutput schema / properties / website / descriptionPrevious value: -"The address that answered, after redirects."New value: +"Where the site answered after redirects: its scheme and host only, such as https://www.joesdiner.com."restaurantdoctor_booking_feesrestaurantdoctor_run_free_check1 field changedOutput schema / properties / alsoCheckAdded value: +{
+ "type": "string"
+}restaurantdoctor_break_even63 fields changedInput schema / properties / averageSpend / anyOfAdded value: +[
+ {
+ "description": "Optional: average spend per guest, the POS average check or net sales ÷ guests or orders. Turns sales into guests.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / averageSpend / descriptionRemoved value: -"Optional: average spend per guest, the POS average check or net sales ÷ guests or orders. Turns sales into guests."Input schema / properties / averageSpend / maximumRemoved value: -1000000000Input schema / properties / averageSpend / minimumRemoved value: -0Input schema / properties / averageSpend / typeRemoved value: -"number"Input schema / properties / closingStock / anyOfAdded value: +[
+ {
+ "description": "Optional: stock at cost at the end of the month. Used only with openingStock.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / closingStock / descriptionRemoved value: -"Optional: stock at cost at the end of the month. Used only with openingStock."Input schema / properties / closingStock / maximumRemoved value: -1000000000Input schema / properties / closingStock / minimumRemoved value: -0Input schema / properties / closingStock / typeRemoved value: -"number"Input schema / properties / daysPerWeek / anyOfAdded value: +[
+ {
+ "description": "Optional: days open a week, a whole number from 1 to 7. Turns the month into sales a day open (and guests a day, with averageSpend); left out, the day figures are left out.",
+ "maximum": 7,
+ "minimum": 1,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / daysPerWeek / descriptionRemoved value: -"Optional: days open a week, a whole number from 1 to 7. Turns the month into sales a day open (and guests a day, with averageSpend); left out, the day figures are left out."Input schema / properties / daysPerWeek / maximumRemoved value: -7Input schema / properties / daysPerWeek / minimumRemoved value: -1Input schema / properties / daysPerWeek / typeRemoved value: -"integer"Input schema / properties / fixedBills / anyOfAdded value: +[
+ {
+ "description": "A month of the bills that stay the same however busy it is: rent and utilities, salaries with their payroll taxes and benefits, insurance, software, marketing, loan and lease payments in full, and the owner's own pay if it isn't on payroll (left out, break-even assumes they work for free). No depreciation. Yearly bills ÷ 12. Needed for a result; if missing, the reply asks for it.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / fixedBills / descriptionRemoved value: -"A month of the bills that stay the same however busy it is: rent and utilities, salaries with their payroll taxes and benefits, insurance, software, marketing, loan and lease payments in full, and the owner's own pay if it isn't on payroll (left out, break-even assumes they work for free). No depreciation. Yearly bills ÷ 12. Needed for a result; if missing, the reply asks for it."Input schema / properties / fixedBills / maximumRemoved value: -1000000000Input schema / properties / fixedBills / minimumRemoved value: -0Input schema / properties / fixedBills / typeRemoved value: -"number"Input schema / properties / goal / anyOfAdded value: +[
+ {
+ "description": "Optional: what the owner would like left over each month after every bill, before income tax. Adds the sales a month that would take.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / goal / descriptionRemoved value: -"Optional: what the owner would like left over each month after every bill, before income tax. Adds the sales a month that would take."Input schema / properties / goal / maximumRemoved value: -1000000000Input schema / properties / goal / minimumRemoved value: -0Input schema / properties / goal / typeRemoved value: -"number"Input schema / properties / hourly / anyOfAdded value: +[
+ {
+ "description": "Whether hourly staff time goes up and down with sales: yes if shifts are added and cut as it gets busy or quiet; no if about the same team works every shift, so hourly pay is a bill that stays the same; unsure (the default) works it out both ways, as a range.",
+ "enum": [
+ "yes",
+ "no",
+ "unsure"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / hourly / descriptionRemoved value: -"Whether hourly staff time goes up and down with sales: yes if shifts are added and cut as it gets busy or quiet; no if about the same team works every shift, so hourly pay is a bill that stays the same; unsure (the default) works it out both ways, as a range."Input schema / properties / hourly / enumRemoved value: -[
- "yes",
- "no",
- "unsure"
-]Input schema / properties / hourly / typeRemoved value: -"string"Input schema / properties / hourlyPay / anyOfAdded value: +[
+ {
+ "description": "That month's hourly wages from payroll, plus the employer's payroll taxes and benefits on them; no tips. Paid every two weeks: one pay run × 26 ÷ 12. Needed for a result (0 with no hourly staff); if missing, the reply asks for it.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / hourlyPay / descriptionRemoved value: -"That month's hourly wages from payroll, plus the employer's payroll taxes and benefits on them; no tips. Paid every two weeks: one pay run × 26 ÷ 12. Needed for a result (0 with no hourly staff); if missing, the reply asks for it."Input schema / properties / hourlyPay / maximumRemoved value: -1000000000Input schema / properties / hourlyPay / minimumRemoved value: -0Input schema / properties / hourlyPay / typeRemoved value: -"number"Input schema / properties / openingStock / anyOfAdded value: +[
+ {
+ "description": "Optional: stock at cost at the start of the month. Used only with closingStock: food and drink then becomes what was used, opening + purchases - closing. Skip both if stock stayed about the same.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / openingStock / descriptionRemoved value: -"Optional: stock at cost at the start of the month. Used only with closingStock: food and drink then becomes what was used, opening + purchases - closing. Skip both if stock stayed about the same."Input schema / properties / openingStock / maximumRemoved value: -1000000000Input schema / properties / openingStock / minimumRemoved value: -0Input schema / properties / openingStock / typeRemoved value: -"number"Input schema / properties / otherVariable / anyOfAdded value: +[
+ {
+ "description": "That month's other costs that rise with every sale: card fees, delivery app commissions (app sales minus payouts, both without tax and tips), to-go packaging, any percentage rent, royalties or ad fund fees. Nothing already in the food and drink invoices. Needed for a result (0 if none); if missing, the reply asks for it.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / otherVariable / descriptionRemoved value: -"That month's other costs that rise with every sale: card fees, delivery app commissions (app sales minus payouts, both without tax and tips), to-go packaging, any percentage rent, royalties or ad fund fees. Nothing already in the food and drink invoices. Needed for a result (0 if none); if missing, the reply asks for it."Input schema / properties / otherVariable / maximumRemoved value: -1000000000Input schema / properties / otherVariable / minimumRemoved value: -0Input schema / properties / otherVariable / typeRemoved value: -"number"Input schema / properties / purchases / anyOfAdded value: +[
+ {
+ "description": "That month's food and drink supplier invoices, added up by delivery date. Needed for a result; if missing, the reply asks for it.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / purchases / descriptionRemoved value: -"That month's food and drink supplier invoices, added up by delivery date. Needed for a result; if missing, the reply asks for it."Input schema / properties / purchases / maximumRemoved value: -1000000000Input schema / properties / purchases / minimumRemoved value: -0Input schema / properties / purchases / typeRemoved value: -"number"Input schema / properties / sales / anyOfAdded value: +[
+ {
+ "description": "Net sales for one typical month, in the owner's own currency like every figure here: the POS sales summary, before tax and tips, delivery app orders at menu price. Not a holiday rush or a one-off: every figure is for that same month. Needed for a result, and more than 0; if missing, the reply asks for it.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / sales / descriptionRemoved value: -"Net sales for one typical month, in the owner's own currency like every figure here: the POS sales summary, before tax and tips, delivery app orders at menu price. Not a holiday rush or a one-off: every figure is for that same month. Needed for a result, and more than 0; if missing, the reply asks for it."Input schema / properties / sales / maximumRemoved value: -1000000000Input schema / properties / sales / minimumRemoved value: -0Input schema / properties / sales / typeRemoved value: -"number"Output schema / properties / checks / descriptionPrevious value: -"Figures that look like a slip, as the page flags them. They don't block the result."New value: +"Figures that look like a slip, as the page flags them."Output schema / properties / link / descriptionPrevious value: -"Opens the calculator on the website with these figures filled in."New value: +"Opens the calculator with these figures."Output schema / properties / pointValue / descriptionPrevious value: -"One point of sales (1%), to the unit: what each point of cost saved leaves a month."New value: +"1% of sales, to the unit: what each point of cost saved leaves a month."Output schema / properties / scenarios / descriptionPrevious value: -"Hourly pay counted one way, or both ways (rising first) when the owner isn't sure and has hourly pay."New value: +"Hourly pay one way, or both (rising first) when the owner isn't sure and has hourly pay."Output schema / properties / scenarios / items / properties / breakEven / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "description": "Break-even sales and guests rounded up to the unit, the rest to the nearest unit, as the page shows them. Null: no amount of sales breaks even this way.",
- "properties": {
- "cushion": {
- "description": "Net sales minus break-even: below 0 when short.",
- "type": "number"
- },
- "cushionPct": {
- "description": "The cushion, % of net sales, one decimal.",
- "type": "number"
- },
- "dayOpen": {
- "anyOf": [
- {
- "description": "Needs daysPerWeek.",
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "goalSales": {
- "anyOf": [
- {
- "description": "Sales a month to have the goal left over. Needs goal.",
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "guestsADay": {
- "anyOf": [
- {
- "description": "Needs daysPerWeek and averageSpend.",
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "guestsAMonth": {
- "anyOf": [
- {
- "description": "Needs averageSpend.",
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "monthly": {
- "type": "number"
- },
- "moreGuestsADay": {
- "anyOf": [
- {
- "description": "When short, with daysPerWeek and averageSpend: the guests a day that close it.",
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "perThousandOffBills": {
- "description": "The same, for each 1,000 a month off the bills that stay the same.",
- "type": "number"
- },
- "pointOffFixed": {
- "description": "The same, for one point off a fixed bill (salaries).",
- "type": "number"
- },
- "pointOffRising": {
- "description": "How far break-even falls a month for one point of sales off a cost that rises with sales.",
- "type": "number"
- },
- "shortADayOpen": {
- "anyOf": [
- {
- "description": "When short, with daysPerWeek: the gap a day open.",
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "weekly": {
- "type": "number"
- }
- },
- "required": [
- "monthly",
- "weekly",
- "dayOpen",
- "guestsADay",
- "guestsAMonth",
- "cushion",
- "cushionPct",
- "shortADayOpen",
- "moreGuestsADay",
- "goalSales",
- "pointOffRising",
- "pointOffFixed",
- "perThousandOffBills"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "description": "Sales and guests rounded up to the unit, the rest to the nearest, as the page shows them. Null: no amount of sales breaks even this way.",
+ "properties": {
+ "cushion": {
+ "description": "Net sales minus break-even: below 0 when short.",
+ "type": "number"
+ },
+ "cushionPct": {
+ "description": "The cushion, % of net sales, one decimal.",
+ "type": "number"
+ },
+ "dayOpen": {
+ "anyOf": [
+ {
+ "description": "Needs daysPerWeek.",
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "goalSales": {
+ "anyOf": [
+ {
+ "description": "Sales a month to have the goal left over. Needs goal.",
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "guestsADay": {
+ "anyOf": [
+ {
+ "description": "Needs daysPerWeek and averageSpend.",
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "guestsAMonth": {
+ "anyOf": [
+ {
+ "description": "Needs averageSpend.",
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "monthly": {
+ "type": "number"
+ },
+ "moreGuestsADay": {
+ "anyOf": [
+ {
+ "description": "When short, with daysPerWeek and averageSpend: the guests a day that close it.",
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "perThousandOffBills": {
+ "description": "The same, for each 1,000 a month off fixedBills.",
+ "type": "number"
+ },
+ "pointOffFixed": {
+ "description": "The same, for one point off a fixed bill (salaries).",
+ "type": "number"
+ },
+ "pointOffRising": {
+ "description": "How far break-even falls a month for one point of sales off a rising cost.",
+ "type": "number"
+ },
+ "shortADayOpen": {
+ "anyOf": [
+ {
+ "description": "When short, with daysPerWeek: the gap a day open.",
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "weekly": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "monthly",
+ "weekly",
+ "dayOpen",
+ "guestsADay",
+ "guestsAMonth",
+ "cushion",
+ "cushionPct",
+ "shortADayOpen",
+ "moreGuestsADay",
+ "goalSales",
+ "pointOffRising",
+ "pointOffFixed",
+ "perThousandOffBills"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / scenarios / items / properties / costsThatRisePct / descriptionPrevious value: -"Costs that rise with sales, % of net sales, one decimal. At 100 or more, no amount of sales breaks even."New value: +"% of net sales, one decimal. At 100 or more, no amount of sales breaks even."Output schema / properties / scenarios / items / properties / hourlyPay / descriptionPrevious value: -"Counted with the costs that rise with sales, or as a bill that stays the same."New value: +"With the costs that rise with sales, or as a fixed bill."Output schema / properties / standing / descriptionPrevious value: -"The month's net sales against break-even: above it, at it almost exactly, short of it, or never (no amount of sales breaks even, either way)."New value: +"Net sales against break-even (at: almost exactly); never: no amount of sales breaks even, either way."Output schema / properties / workedOut / descriptionPrevious value: -"How it was worked out, with the figures in each step."New value: +"How it was worked out."restaurantdoctor_card_feesrestaurantdoctor_deadlines8 fields changedOutput schema / properties / deadlines / items / properties / appliesIf / anyOfAdded value: +[
+ {
+ "description": "When an answer that decides it wasn't given: the condition it depends on.",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / deadlines / items / properties / appliesIf / descriptionRemoved value: -"When an answer that decides it wasn't given: the condition it depends on."Output schema / properties / deadlines / items / properties / appliesIf / typeRemoved value: -[
- "string",
- "null"
-]Output schema / properties / deadlines / items / properties / missCost / anyOfAdded value: +[
+ {
+ "description": "What missing it costs, from its source, when the source says.",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / deadlines / items / properties / missCost / typeRemoved value: -[
- "string",
- "null"
-]Output schema / properties / deadlines / items / properties / movedFrom / anyOfAdded value: +[
+ {
+ "description": "The date before a weekend or holiday moved it, and why.",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / deadlines / items / properties / movedFrom / descriptionRemoved value: -"The date before a weekend or holiday moved it, and why."Output schema / properties / deadlines / items / properties / movedFrom / typeRemoved value: -[
- "string",
- "null"
-]restaurantdoctor_delivery_price10 fields changedInput schema / properties / price / anyOfAdded value: +[
+ {
+ "description": "The dish's price on the owner's own menu, as a dining room guest pays it, in the owner's own currency (14 or 18.5). Needed for a result, and more than 0; if missing, the reply asks for it.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / price / descriptionRemoved value: -"The dish's price on the owner's own menu, as a dining room guest pays it, in the owner's own currency (14 or 18.5). Needed for a result, and more than 0; if missing, the reply asks for it."Input schema / properties / price / maximumRemoved value: -1000000000Input schema / properties / price / minimumRemoved value: -0Input schema / properties / price / typeRemoved value: -"number"Input schema / properties / rate / anyOfAdded value: +[
+ {
+ "description": "One delivery app's real commission rate, as a percent: 30 for 30%, not 0.30. From a month of that app's payout statements: (menu sales before tax and tips − the app's payout without tax and tips) ÷ those menu sales × 100, so marketing fees, promotions the owner funds and refunds are in it; the rate in the app's plan leaves them out. Each app is worked out on its own. Needed for a result: 0, or from 1 to 89; if missing, the reply asks for it.",
+ "maximum": 89,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / rate / descriptionRemoved value: -"One delivery app's real commission rate, as a percent: 30 for 30%, not 0.30. From a month of that app's payout statements: (menu sales before tax and tips − the app's payout without tax and tips) ÷ those menu sales × 100, so marketing fees, promotions the owner funds and refunds are in it; the rate in the app's plan leaves them out. Each app is worked out on its own. Needed for a result: 0, or from 1 to 89; if missing, the reply asks for it."Input schema / properties / rate / maximumRemoved value: -89Input schema / properties / rate / minimumRemoved value: -0Input schema / properties / rate / typeRemoved value: -"number"restaurantdoctor_fica_tip_creditrestaurantdoctor_labor_cost50 fields changedInput schema / properties / forecast / anyOfAdded value: +[
+ {
+ "description": "Net sales expected next period, more than 0: the last 4 weeks' (or 3 months') average, adjusted for events and holidays. Needed for hours; for line, the line is then for these sales.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / forecast / descriptionRemoved value: -"Net sales expected next period, more than 0: the last 4 weeks' (or 3 months') average, adjusted for events and holidays. Needed for hours; for line, the line is then for these sales."Input schema / properties / forecast / maximumRemoved value: -1000000000Input schema / properties / forecast / minimumRemoved value: -0Input schema / properties / forecast / typeRemoved value: -"number"Input schema / properties / hourSales / anyOfAdded value: +[
+ {
+ "description": "Optional, for line: net sales in the last hour of a shift, for how many hourly staff it pays for.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / hourSales / descriptionRemoved value: -"Optional, for line: net sales in the last hour of a shift, for how many hourly staff it pays for."Input schema / properties / hourSales / maximumRemoved value: -1000000000Input schema / properties / hourSales / minimumRemoved value: -0Input schema / properties / hourSales / typeRemoved value: -"number"Input schema / properties / hourlyWages / anyOfAdded value: +[
+ {
+ "description": "Last period's gross pay for everyone paid by the hour, from payroll: by the days worked, overtime in, tips out. 0 if all are salaried (share only). Needed in every mode.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / hourlyWages / descriptionRemoved value: -"Last period's gross pay for everyone paid by the hour, from payroll: by the days worked, overtime in, tips out. 0 if all are salaried (share only). Needed in every mode."Input schema / properties / hourlyWages / maximumRemoved value: -1000000000Input schema / properties / hourlyWages / minimumRemoved value: -0Input schema / properties / hourlyWages / typeRemoved value: -"number"Input schema / properties / hours / anyOfAdded value: +[
+ {
+ "description": "Hours those staff worked last period, from the time clock: overtime in, salaried managers out. Needed for hours and line.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / hours / descriptionRemoved value: -"Hours those staff worked last period, from the time clock: overtime in, salaried managers out. Needed for hours and line."Input schema / properties / hours / maximumRemoved value: -1000000000Input schema / properties / hours / minimumRemoved value: -0Input schema / properties / hours / typeRemoved value: -"number"Input schema / properties / overtimeHours / anyOfAdded value: +[
+ {
+ "description": "Optional, for share: how many of the hours worked were overtime.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / overtimeHours / descriptionRemoved value: -"Optional, for share: how many of the hours worked were overtime."Input schema / properties / overtimeHours / maximumRemoved value: -1000000000Input schema / properties / overtimeHours / minimumRemoved value: -0Input schema / properties / overtimeHours / typeRemoved value: -"number"Input schema / properties / ownerPay / anyOfAdded value: +[
+ {
+ "description": "Optional, for share: if the owner works without a salary, what someone doing their hours would cost, payroll taxes in. Shown as a second figure.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / ownerPay / descriptionRemoved value: -"Optional, for share: if the owner works without a salary, what someone doing their hours would cost, payroll taxes in. Shown as a second figure."Input schema / properties / ownerPay / maximumRemoved value: -1000000000Input schema / properties / ownerPay / minimumRemoved value: -0Input schema / properties / ownerPay / typeRemoved value: -"number"Input schema / properties / payrollCosts / anyOfAdded value: +[
+ {
+ "description": "Optional: the employer's payroll taxes and benefits on that pay, such as health insurance. Left out, labor reads lower, unless the pay already includes them.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / payrollCosts / descriptionRemoved value: -"Optional: the employer's payroll taxes and benefits on that pay, such as health insurance. Left out, labor reads lower, unless the pay already includes them."Input schema / properties / payrollCosts / maximumRemoved value: -1000000000Input schema / properties / payrollCosts / minimumRemoved value: -0Input schema / properties / payrollCosts / typeRemoved value: -"number"Input schema / properties / salaries / anyOfAdded value: +[
+ {
+ "description": "Optional: salaried pay for the period (a yearly salary ÷ 52, or ÷ 12 for a month).",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / salaries / descriptionRemoved value: -"Optional: salaried pay for the period (a yearly salary ÷ 52, or ÷ 12 for a month)."Input schema / properties / salaries / maximumRemoved value: -1000000000Input schema / properties / salaries / minimumRemoved value: -0Input schema / properties / salaries / typeRemoved value: -"number"Input schema / properties / sales / anyOfAdded value: +[
+ {
+ "description": "Last period's net sales, in the owner's own currency like every amount here, from the POS: after discounts and comps, before tax and tips, plus any service charge paid out to staff. Needed for share, and for line without forecast.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / sales / descriptionRemoved value: -"Last period's net sales, in the owner's own currency like every amount here, from the POS: after discounts and comps, before tax and tips, plus any service charge paid out to staff. Needed for share, and for line without forecast."Input schema / properties / sales / maximumRemoved value: -1000000000Input schema / properties / sales / minimumRemoved value: -0Input schema / properties / sales / typeRemoved value: -"number"Input schema / properties / target / anyOfAdded value: +[
+ {
+ "description": "Optional, for hours and line: the owner's labor target, % of net sales (1 to 99). Left out: the top of the range, where the page starts.",
+ "maximum": 99,
+ "minimum": 1,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / target / descriptionRemoved value: -"Optional, for hours and line: the owner's labor target, % of net sales (1 to 99). Left out: the top of the range, where the page starts."Input schema / properties / target / maximumRemoved value: -99Input schema / properties / target / minimumRemoved value: -1Input schema / properties / target / typeRemoved value: -"number"restaurantdoctor_menu_calories27 fields changedInput schema / properties / cookedWeight / additionalPropertiesRemoved value: -falseInput schema / properties / cookedWeight / anyOfAdded value: +[
+ {
+ "additionalProperties": false,
+ "description": "With weight: the whole batch, weighed after cooking. Needed then; if missing, the reply asks for it.",
+ "properties": {
+ "amount": {
+ "maximum": 1000000000,
+ "minimum": 0.001,
+ "type": "number"
+ },
+ "unit": {
+ "enum": [
+ "g",
+ "kg",
+ "oz",
+ "lb"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "amount",
+ "unit"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / cookedWeight / descriptionRemoved value: -"With weight: the whole batch, weighed after cooking. Needed then; if missing, the reply asks for it."Input schema / properties / cookedWeight / propertiesRemoved value: -{
- "amount": {
- "maximum": 1000000000,
- "minimum": 0.001,
- "type": "number"
- },
- "unit": {
- "enum": [
- "g",
- "kg",
- "oz",
- "lb"
- ],
- "type": "string"
- }
-}Input schema / properties / cookedWeight / requiredRemoved value: -[
- "amount",
- "unit"
-]Input schema / properties / cookedWeight / typeRemoved value: -"object"Input schema / properties / dish / anyOfAdded value: +[
+ {
+ "description": "Optional: the dish's name, for the record.",
+ "maxLength": 100,
+ "minLength": 0,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / dish / descriptionRemoved value: -"Optional: the dish's name, for the record."Input schema / properties / dish / maxLengthRemoved value: -100Input schema / properties / dish / minLengthRemoved value: -0Input schema / properties / dish / typeRemoved value: -"string"Input schema / properties / ingredients / anyOfAdded value: +[
+ {
+ "description": "What goes into the dish or batch, one entry each. Needed for a result; if missing, the reply asks for it.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "amount": {
+ "anyOf": [
+ {
+ "description": "How much goes in, after trimming, in unit. Weighed if possible. Needed for a result; if missing, the reply asks for it.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "food": {
+ "anyOf": [
+ {
+ "description": "The food: its name on the counter's list of USDA foods, as an earlier answer gave it, or the owner's words for it, matched to that list. Words that fit several foods, or none, come back as a tool error naming the foods to pick from, or saying it isn't on the list. With kcalPer100g, just its name.",
+ "maxLength": 100,
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "kcalPer100g": {
+ "anyOf": [
+ {
+ "description": "For a food not on the list: kcal per 100 g from the nutrition panel on the owner's own pack, as the owner reads it (a US label gives a serving: its calories ÷ its grams × 100). Never an estimate by the assistant: if the owner has no label, the ingredient can't be counted yet. Weighed only.",
+ "maximum": 900,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "unit": {
+ "description": "g, kg, oz or lb for any food. ml, l, floz, cup, tbsp or tsp (US measures) for liquids and fats only; each for foods counted by the piece.",
+ "enum": [
+ "g",
+ "kg",
+ "oz",
+ "lb",
+ "ml",
+ "l",
+ "floz",
+ "cup",
+ "tbsp",
+ "tsp",
+ "each"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "unit"
+ ],
+ "type": "object"
+ },
+ "maxItems": 30,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / ingredients / descriptionRemoved value: -"What goes into the dish or batch, one entry each. Needed for a result; if missing, the reply asks for it."Input schema / properties / ingredients / itemsRemoved value: -{
- "additionalProperties": false,
- "properties": {
- "amount": {
- "description": "How much goes in, after trimming, in unit. Weighed if possible. Needed for a result; if missing, the reply asks for it.",
- "maximum": 1000000000,
- "minimum": 0,
- "type": "number"
- },
- "food": {
- "description": "The food: its name on the counter's list of USDA foods, as an earlier answer gave it, or the owner's words for it, matched to that list. Words that fit several foods, or none, come back as a tool error naming the foods to pick from, or saying it isn't on the list. With kcalPer100g, just its name.",
- "maxLength": 100,
- "minLength": 1,
- "type": "string"
- },
- "kcalPer100g": {
- "description": "For a food not on the list: kcal per 100 g from the nutrition panel on the owner's own pack, as the owner reads it (a US label gives a serving: its calories ÷ its grams × 100). Never an estimate by the assistant: if the owner has no label, the ingredient can't be counted yet. Weighed only.",
- "maximum": 900,
- "minimum": 0,
- "type": "number"
- },
- "unit": {
- "description": "g, kg, oz or lb for any food. ml, l, floz, cup, tbsp or tsp (US measures) for liquids and fats only; each for foods counted by the piece.",
- "enum": [
- "g",
- "kg",
- "oz",
- "lb",
- "ml",
- "l",
- "floz",
- "cup",
- "tbsp",
- "tsp",
- "each"
- ],
- "type": "string"
- }
- },
- "required": [
- "unit"
- ],
- "type": "object"
-}Input schema / properties / ingredients / maxItemsRemoved value: -30Input schema / properties / ingredients / typeRemoved value: -"array"Input schema / properties / plates / anyOfAdded value: +[
+ {
+ "description": "With plates: how many plates it makes, 1 for a single plate. Needed then; if missing, the reply asks for it.",
+ "maximum": 1000000000,
+ "minimum": 0.001,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / plates / descriptionRemoved value: -"With plates: how many plates it makes, 1 for a single plate. Needed then; if missing, the reply asks for it."Input schema / properties / plates / maximumRemoved value: -1000000000Input schema / properties / plates / minimumRemoved value: -0.001Input schema / properties / plates / typeRemoved value: -"number"Input schema / properties / portionWeight / additionalPropertiesRemoved value: -falseInput schema / properties / portionWeight / anyOfAdded value: +[
+ {
+ "additionalProperties": false,
+ "description": "With weight: one portion. Needed then; if missing, the reply asks for it.",
+ "properties": {
+ "amount": {
+ "maximum": 1000000000,
+ "minimum": 0.001,
+ "type": "number"
+ },
+ "unit": {
+ "enum": [
+ "g",
+ "kg",
+ "oz",
+ "lb"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "amount",
+ "unit"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / portionWeight / descriptionRemoved value: -"With weight: one portion. Needed then; if missing, the reply asks for it."Input schema / properties / portionWeight / propertiesRemoved value: -{
- "amount": {
- "maximum": 1000000000,
- "minimum": 0.001,
- "type": "number"
- },
- "unit": {
- "enum": [
- "g",
- "kg",
- "oz",
- "lb"
- ],
- "type": "string"
- }
-}Input schema / properties / portionWeight / requiredRemoved value: -[
- "amount",
- "unit"
-]Input schema / properties / portionWeight / typeRemoved value: -"object"restaurantdoctor_plate_cost45 fields changedInput schema / properties / extras / anyOfAdded value: +[
+ {
+ "description": "Optional, mode ingredients: small extras without a line of their own (salt, oil, garnish), % of the ingredients; often 5 to 10.",
+ "maximum": 100,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / extras / descriptionRemoved value: -"Optional, mode ingredients: small extras without a line of their own (salt, oil, garnish), % of the ingredients; often 5 to 10."Input schema / properties / extras / maximumRemoved value: -100Input schema / properties / extras / minimumRemoved value: -0Input schema / properties / extras / typeRemoved value: -"number"Input schema / properties / ingredients / anyOfAdded value: +[
+ {
+ "description": "With mode ingredients: each ingredient. A sauce or side already costed is one: its cost for a pack of 1 each, 1 each used.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "anyOf": [
+ {
+ "description": "Optional: what it is, as the owner calls it.",
+ "maxLength": 100,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "packSize": {
+ "anyOf": [
+ {
+ "description": "How much one pack holds, in packUnit: 5 for a 5 lb bag. A case of 6 cans is 6 each; a 4 × 5 lb case is 20 lb.",
+ "exclusiveMinimum": 0,
+ "maximum": 1000000000,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "packUnit": {
+ "description": "The pack's unit: floz and gal are US fluid ounces and gallons.",
+ "enum": [
+ "g",
+ "kg",
+ "oz",
+ "lb",
+ "ml",
+ "l",
+ "floz",
+ "gal",
+ "each"
+ ],
+ "type": "string"
+ },
+ "paid": {
+ "anyOf": [
+ {
+ "description": "What the owner paid for one pack, from their latest invoice, before any VAT or GST they claim back.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "usable": {
+ "anyOf": [
+ {
+ "description": "Optional: of what's bought, the % left after trimming or cooking: 85 for 1 kg that trims to 850 g. Left out, 100.",
+ "maximum": 100,
+ "minimum": 1,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "used": {
+ "anyOf": [
+ {
+ "description": "The amount that goes in the pot or on the plate, after trimming, for the plates in portions. Spoons or cups: weigh it once.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "usedUnit": {
+ "description": "The amount's unit, of the pack's kind: weight, volume and count don't convert into each other.",
+ "enum": [
+ "g",
+ "kg",
+ "oz",
+ "lb",
+ "ml",
+ "l",
+ "floz",
+ "gal",
+ "each"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "packUnit",
+ "usedUnit"
+ ],
+ "type": "object"
+ },
+ "maxItems": 30,
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / ingredients / descriptionRemoved value: -"With mode ingredients: each ingredient. A sauce or side already costed is one: its cost for a pack of 1 each, 1 each used."Input schema / properties / ingredients / itemsRemoved value: -{
- "additionalProperties": false,
- "properties": {
- "name": {
- "description": "Optional: what it is, as the owner calls it.",
- "maxLength": 100,
- "type": "string"
- },
- "packSize": {
- "description": "How much one pack holds, in packUnit: 5 for a 5 lb bag. A case of 6 cans is 6 each; a 4 × 5 lb case is 20 lb.",
- "exclusiveMinimum": 0,
- "maximum": 1000000000,
- "type": "number"
- },
- "packUnit": {
- "description": "The pack's unit: floz and gal are US fluid ounces and gallons.",
- "enum": [
- "g",
- "kg",
- "oz",
- "lb",
- "ml",
- "l",
- "floz",
- "gal",
- "each"
- ],
- "type": "string"
- },
- "paid": {
- "description": "What the owner paid for one pack, from their latest invoice, before any VAT or GST they claim back.",
- "maximum": 1000000000,
- "minimum": 0,
- "type": "number"
- },
- "usable": {
- "description": "Optional: of what's bought, the % left after trimming or cooking: 85 for 1 kg that trims to 850 g. Left out, 100.",
- "maximum": 100,
- "minimum": 1,
- "type": "number"
- },
- "used": {
- "description": "The amount that goes in the pot or on the plate, after trimming, for the plates in portions. Spoons or cups: weigh it once.",
- "maximum": 1000000000,
- "minimum": 0,
- "type": "number"
- },
- "usedUnit": {
- "description": "The amount's unit, of the pack's kind: weight, volume and count don't convert into each other.",
- "enum": [
- "g",
- "kg",
- "oz",
- "lb",
- "ml",
- "l",
- "floz",
- "gal",
- "each"
- ],
- "type": "string"
- }
- },
- "required": [
- "packUnit",
- "usedUnit"
- ],
- "type": "object"
-}Input schema / properties / ingredients / maxItemsRemoved value: -30Input schema / properties / ingredients / typeRemoved value: -"array"Input schema / properties / menuPrice / anyOfAdded value: +[
+ {
+ "description": "Optional: the dish's price on the menu. Left out, the result gives the prices to charge, as for a new dish.",
+ "exclusiveMinimum": 0,
+ "maximum": 1000000000,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / menuPrice / descriptionRemoved value: -"Optional: the dish's price on the menu. Left out, the result gives the prices to charge, as for a new dish."Input schema / properties / menuPrice / exclusiveMinimumRemoved value: -0Input schema / properties / menuPrice / maximumRemoved value: -1000000000Input schema / properties / menuPrice / typeRemoved value: -"number"Input schema / properties / plateCost / anyOfAdded value: +[
+ {
+ "description": "With mode known, needed: what the ingredients on one plate cost, from a recipe card or costing sheet, in the owner's own currency like every money figure here.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / plateCost / descriptionRemoved value: -"With mode known, needed: what the ingredients on one plate cost, from a recipe card or costing sheet, in the owner's own currency like every money figure here."Input schema / properties / plateCost / maximumRemoved value: -1000000000Input schema / properties / plateCost / minimumRemoved value: -0Input schema / properties / plateCost / typeRemoved value: -"number"Input schema / properties / portions / anyOfAdded value: +[
+ {
+ "description": "With mode ingredients, needed: how many plates the amounts make, 1 for a single plate.",
+ "exclusiveMinimum": 0,
+ "maximum": 1000000000,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / portions / descriptionRemoved value: -"With mode ingredients, needed: how many plates the amounts make, 1 for a single plate."Input schema / properties / portions / exclusiveMinimumRemoved value: -0Input schema / properties / portions / maximumRemoved value: -1000000000Input schema / properties / portions / typeRemoved value: -"number"Input schema / properties / sold / anyOfAdded value: +[
+ {
+ "description": "Optional: how many of this dish sold last month (POS item sales), for the figures a month.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / sold / descriptionRemoved value: -"Optional: how many of this dish sold last month (POS item sales), for the figures a month."Input schema / properties / sold / maximumRemoved value: -1000000000Input schema / properties / sold / minimumRemoved value: -0Input schema / properties / sold / typeRemoved value: -"integer"Input schema / properties / target / anyOfAdded value: +[
+ {
+ "description": "Optional: the owner's target food cost, %. Left out, the middle of the format's range (32 for full service); none for a bar.",
+ "maximum": 99,
+ "minimum": 1,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / target / descriptionRemoved value: -"Optional: the owner's target food cost, %. Left out, the middle of the format's range (32 for full service); none for a bar."Input schema / properties / target / maximumRemoved value: -99Input schema / properties / target / minimumRemoved value: -1Input schema / properties / target / typeRemoved value: -"number"Input schema / properties / taxIncluded / anyOfAdded value: +[
+ {
+ "description": "true when menu prices include VAT or GST (UK, EU, Australia, New Zealand); left out when tax is added at the till (US, Canada).",
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / taxIncluded / descriptionRemoved value: -"true when menu prices include VAT or GST (UK, EU, Australia, New Zealand); left out when tax is added at the till (US, Canada)."Input schema / properties / taxIncluded / typeRemoved value: -"boolean"Input schema / properties / taxRate / anyOfAdded value: +[
+ {
+ "description": "With taxIncluded, needed: the tax rate in this dish's price, %. Food and drinks can have different rates.",
+ "maximum": 50,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / taxRate / descriptionRemoved value: -"With taxIncluded, needed: the tax rate in this dish's price, %. Food and drinks can have different rates."Input schema / properties / taxRate / maximumRemoved value: -50Input schema / properties / taxRate / minimumRemoved value: -0Input schema / properties / taxRate / typeRemoved value: -"number"Output schema / properties / link / descriptionPrevious value: -"Opens the calculator on the website with these figures filled in."New value: +"Opens the calculator with these figures."Output schema / properties / workedOut / descriptionPrevious value: -"How it was worked out, with the figures in each step."New value: +"How it was worked out."restaurantdoctor_prime_cost35 fields changedInput schema / properties / closingStock / anyOfAdded value: +[
+ {
+ "description": "Optional: stock at cost at the end of the period, counted on the same items the invoices cover. Used only with openingStock.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / closingStock / descriptionRemoved value: -"Optional: stock at cost at the end of the period, counted on the same items the invoices cover. Used only with openingStock."Input schema / properties / closingStock / maximumRemoved value: -1000000000Input schema / properties / closingStock / minimumRemoved value: -0Input schema / properties / closingStock / typeRemoved value: -"number"Input schema / properties / openingStock / anyOfAdded value: +[
+ {
+ "description": "Optional: stock at cost at the start of the period. Used only with closingStock: food and drink then becomes what was used, opening + purchases - closing.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / openingStock / descriptionRemoved value: -"Optional: stock at cost at the start of the period. Used only with closingStock: food and drink then becomes what was used, opening + purchases - closing."Input schema / properties / openingStock / maximumRemoved value: -1000000000Input schema / properties / openingStock / minimumRemoved value: -0Input schema / properties / openingStock / typeRemoved value: -"number"Input schema / properties / ownerPay / anyOfAdded value: +[
+ {
+ "description": "Optional: when the owner works in the restaurant without a salary, what they'd pay someone to do their hours, plus the payroll taxes on it. It's a second figure; the main one stays as the books have it.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / ownerPay / descriptionRemoved value: -"Optional: when the owner works in the restaurant without a salary, what they'd pay someone to do their hours, plus the payroll taxes on it. It's a second figure; the main one stays as the books have it."Input schema / properties / ownerPay / maximumRemoved value: -1000000000Input schema / properties / ownerPay / minimumRemoved value: -0Input schema / properties / ownerPay / typeRemoved value: -"number"Input schema / properties / payrollCosts / anyOfAdded value: +[
+ {
+ "description": "Optional: the employer's payroll taxes and benefits for the period, such as health insurance or a pension, when the wages figure leaves them out.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / payrollCosts / descriptionRemoved value: -"Optional: the employer's payroll taxes and benefits for the period, such as health insurance or a pension, when the wages figure leaves them out."Input schema / properties / payrollCosts / maximumRemoved value: -1000000000Input schema / properties / payrollCosts / minimumRemoved value: -0Input schema / properties / payrollCosts / typeRemoved value: -"number"Input schema / properties / purchases / anyOfAdded value: +[
+ {
+ "description": "Food and drink supplier invoices for the same dates, added up by delivery date, minus credits. No packaging. Needed for a result; if missing, the reply asks for it.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / purchases / descriptionRemoved value: -"Food and drink supplier invoices for the same dates, added up by delivery date, minus credits. No packaging. Needed for a result; if missing, the reply asks for it."Input schema / properties / purchases / maximumRemoved value: -1000000000Input schema / properties / purchases / minimumRemoved value: -0Input schema / properties / purchases / typeRemoved value: -"number"Input schema / properties / sales / anyOfAdded value: +[
+ {
+ "description": "Net sales for the period, in the owner's own currency like every figure here, from the POS sales summary: after discounts and comps, before tax and tips, with any service charge paid out to staff added back. Needed for a result, and more than 0; if missing, the reply asks for it.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / sales / descriptionRemoved value: -"Net sales for the period, in the owner's own currency like every figure here, from the POS sales summary: after discounts and comps, before tax and tips, with any service charge paid out to staff added back. Needed for a result, and more than 0; if missing, the reply asks for it."Input schema / properties / sales / maximumRemoved value: -1000000000Input schema / properties / sales / minimumRemoved value: -0Input schema / properties / sales / typeRemoved value: -"number"Input schema / properties / wages / anyOfAdded value: +[
+ {
+ "description": "Every wage and salary for the same dates, from payroll, managers included (a salary counts as a 52nd of a year for a week, a 12th for a month). No tips, but a service charge paid to staff stays in. Needed for a result; if missing, the reply asks for it.",
+ "maximum": 1000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / wages / descriptionRemoved value: -"Every wage and salary for the same dates, from payroll, managers included (a salary counts as a 52nd of a year for a week, a 12th for a month). No tips, but a service charge paid to staff stays in. Needed for a result; if missing, the reply asks for it."Input schema / properties / wages / maximumRemoved value: -1000000000Input schema / properties / wages / minimumRemoved value: -0Input schema / properties / wages / typeRemoved value: -"number"restaurantdoctor_break_even5 fields changedInput schema / properties / fixedBills / descriptionPrevious value: -"A month of the bills that stay the same however busy it is: rent and utilities, salaries with their payroll taxes and benefits, insurance, software, marketing, loan and lease payments in full, and the owner's own pay if it isn't on payroll (left out, break-even assumes they work for free). No depreciation. Yearly bills ÷ 12. Required."New value: +"A month of the bills that stay the same however busy it is: rent and utilities, salaries with their payroll taxes and benefits, insurance, software, marketing, loan and lease payments in full, and the owner's own pay if it isn't on payroll (left out, break-even assumes they work for free). No depreciation. Yearly bills ÷ 12. Needed for a result; if missing, the reply asks for it."Input schema / properties / hourlyPay / descriptionPrevious value: -"That month's hourly wages from payroll, plus the employer's payroll taxes and benefits on them; no tips. Paid every two weeks: one pay run × 26 ÷ 12. Required: 0 with no hourly staff."New value: +"That month's hourly wages from payroll, plus the employer's payroll taxes and benefits on them; no tips. Paid every two weeks: one pay run × 26 ÷ 12. Needed for a result (0 with no hourly staff); if missing, the reply asks for it."Input schema / properties / otherVariable / descriptionPrevious value: -"That month's other costs that rise with every sale: card fees, delivery app commissions (app sales minus payouts, both without tax and tips), to-go packaging, any percentage rent, royalties or ad fund fees. Nothing already in the food and drink invoices. Required: 0 if none."New value: +"That month's other costs that rise with every sale: card fees, delivery app commissions (app sales minus payouts, both without tax and tips), to-go packaging, any percentage rent, royalties or ad fund fees. Nothing already in the food and drink invoices. Needed for a result (0 if none); if missing, the reply asks for it."Input schema / properties / purchases / descriptionPrevious value: -"That month's food and drink supplier invoices, added up by delivery date. Required."New value: +"That month's food and drink supplier invoices, added up by delivery date. Needed for a result; if missing, the reply asks for it."Input schema / properties / sales / descriptionPrevious value: -"Net sales for one typical month, in the owner's own currency like every figure here: the POS sales summary, before tax and tips, delivery app orders at menu price. Not a holiday rush or a one-off: every figure is for that same month. Required, and more than 0."New value: +"Net sales for one typical month, in the owner's own currency like every figure here: the POS sales summary, before tax and tips, delivery app orders at menu price. Not a holiday rush or a one-off: every figure is for that same month. Needed for a result, and more than 0; if missing, the reply asks for it."restaurantdoctor_check_website2 fields changedOutput schema / properties / phoneSpeedSkippedAdded value: +{
+ "description": "Google's phone speed test wasn't run, because phoneSpeed was false. It isn't in the score.",
+ "type": "boolean"
+}Output schema / requiredPrevious value: -[
- "website",
- "score",
- "grade",
- "checks",
- "fixFirst",
- "ordersOnlyThroughApps",
- "fullCheckUrl"
-]New value: +[
+ "website",
+ "score",
+ "grade",
+ "checks",
+ "fixFirst",
+ "phoneSpeedSkipped",
+ "ordersOnlyThroughApps",
+ "fullCheckUrl"
+]restaurantdoctor_deadlines3 fields changedInput schema / properties / months / descriptionPrevious value: -"How many months ahead to list, 1 to 15 (default 3). The calendar runs to the end of 2027."New value: +"How many months ahead to list, 1 to 15 (default 3). The calendar runs to the end of 2027. withinDays, when sent, sets the window instead."Input schema / properties / scopeAdded value: +{
+ "description": "Optional, to cut the list: federal (the IRS's and other federal dates only), state (the state's and the city's only) or all (the default). The rules for each hire are listed either way.",
+ "enum": [
+ "all",
+ "federal",
+ "state"
+ ],
+ "type": "string"
+}Input schema / properties / withinDaysAdded value: +{
+ "description": "Optional: only the dates in the next so many days, 1 to 460, from today in the state (7 for the coming week). Sent, it replaces months.",
+ "maximum": 460,
+ "minimum": 1,
+ "type": "integer"
+}restaurantdoctor_delivery_price2 fields changedInput schema / properties / price / descriptionPrevious value: -"The dish's price on the owner's own menu, as a dining room guest pays it, in the owner's own currency (14 or 18.5). Required, and more than 0."New value: +"The dish's price on the owner's own menu, as a dining room guest pays it, in the owner's own currency (14 or 18.5). Needed for a result, and more than 0; if missing, the reply asks for it."Input schema / properties / rate / descriptionPrevious value: -"One delivery app's real commission rate, as a percent: 30 for 30%, not 0.30. From a month of that app's payout statements: (menu sales before tax and tips − the app's payout without tax and tips) ÷ those menu sales × 100, so marketing fees, promotions the owner funds and refunds are in it; the rate in the app's plan leaves them out. Each app is worked out on its own. Required: 0, or from 1 to 89."New value: +"One delivery app's real commission rate, as a percent: 30 for 30%, not 0.30. From a month of that app's payout statements: (menu sales before tax and tips − the app's payout without tax and tips) ÷ those menu sales × 100, so marketing fees, promotions the owner funds and refunds are in it; the rate in the app's plan leaves them out. Each app is worked out on its own. Needed for a result: 0, or from 1 to 89; if missing, the reply asks for it."restaurantdoctor_list_knowledgerestaurantdoctor_menu_calories5 fields changedInput schema / properties / cookedWeight / descriptionPrevious value: -"With weight: the whole batch, weighed after cooking. Required then."New value: +"With weight: the whole batch, weighed after cooking. Needed then; if missing, the reply asks for it."Input schema / properties / ingredients / descriptionPrevious value: -"What goes into the dish or batch, one entry each. Required."New value: +"What goes into the dish or batch, one entry each. Needed for a result; if missing, the reply asks for it."Input schema / properties / ingredients / items / properties / amount / descriptionPrevious value: -"How much goes in, after trimming, in unit. Weighed if possible. Required."New value: +"How much goes in, after trimming, in unit. Weighed if possible. Needed for a result; if missing, the reply asks for it."Input schema / properties / plates / descriptionPrevious value: -"With plates: how many plates it makes, 1 for a single plate. Required then."New value: +"With plates: how many plates it makes, 1 for a single plate. Needed then; if missing, the reply asks for it."Input schema / properties / portionWeight / descriptionPrevious value: -"With weight: one portion. Required then."New value: +"With weight: one portion. Needed then; if missing, the reply asks for it."restaurantdoctor_plate_cost3 fields changedInput schema / properties / plateCost / descriptionPrevious value: -"With mode known, required: what the ingredients on one plate cost, from a recipe card or costing sheet, in the owner's own currency like every money figure here."New value: +"With mode known, needed: what the ingredients on one plate cost, from a recipe card or costing sheet, in the owner's own currency like every money figure here."Input schema / properties / portions / descriptionPrevious value: -"With mode ingredients, required: how many plates the amounts make, 1 for a single plate."New value: +"With mode ingredients, needed: how many plates the amounts make, 1 for a single plate."Input schema / properties / taxRate / descriptionPrevious value: -"With taxIncluded, required: the tax rate in this dish's price, %. Food and drinks can have different rates."New value: +"With taxIncluded, needed: the tax rate in this dish's price, %. Food and drinks can have different rates."restaurantdoctor_prime_cost3 fields changedInput schema / properties / purchases / descriptionPrevious value: -"Food and drink supplier invoices for the same dates, added up by delivery date, minus credits. No packaging. Required."New value: +"Food and drink supplier invoices for the same dates, added up by delivery date, minus credits. No packaging. Needed for a result; if missing, the reply asks for it."Input schema / properties / sales / descriptionPrevious value: -"Net sales for the period, in the owner's own currency like every figure here, from the POS sales summary: after discounts and comps, before tax and tips, with any service charge paid out to staff added back. Required, and more than 0."New value: +"Net sales for the period, in the owner's own currency like every figure here, from the POS sales summary: after discounts and comps, before tax and tips, with any service charge paid out to staff added back. Needed for a result, and more than 0; if missing, the reply asks for it."Input schema / properties / wages / descriptionPrevious value: -"Every wage and salary for the same dates, from payroll, managers included (a salary counts as a 52nd of a year for a week, a 12th for a month). No tips, but a service charge paid to staff stays in. Required."New value: +"Every wage and salary for the same dates, from payroll, managers included (a salary counts as a 52nd of a year for a week, a 12th for a month). No tips, but a service charge paid to staff stays in. Needed for a result; if missing, the reply asks for it."restaurantdoctor_read_knowledgerestaurantdoctor_run_free_check6 fields changedInput schema / properties / monthlyRevenue / descriptionPrevious value: -"About how much do you sell in a typical month? Amounts are in US dollars, or in the local currency where that's the euro, pound sterling, Swiss franc, or Canadian, Australian or New Zealand dollar; restaurantdoctor_get_questions shows the exact ranges for a country. under_25k = Under $25,000 (Under $300K a year); 25k_60k = $25,000 – $60,000 ($300K – $720K a year); 60k_120k = $60,000 – $120,000 ($720K – $1.44M a year); over_120k = Over $120,000 (Over $1.44M a year)."New value: +"About how much do you sell in a typical month? Amounts are in US dollars, or in the local currency where that's the euro, pound sterling, Swiss franc, or Canadian, Australian or New Zealand dollar; restaurantdoctor_get_questions shows the exact ranges for a country. under_25k = Under $25,000 (Under $300K a year); 25k_60k = $25,000 – $60,000 ($300K – $720K a year); 60k_120k = $60,000 – $120,000 ($720K – $1.44M a year); 120k_200k = $120,000 – $200,000 ($1.44M – $2.4M a year); over_200k = Over $200,000 (Over $2.4M a year)."Input schema / properties / monthlyRevenue / enumPrevious value: -[
- "under_25k",
- "25k_60k",
- "60k_120k",
- "over_120k"
-]New value: +[
+ "under_25k",
+ "25k_60k",
+ "60k_120k",
+ "120k_200k",
+ "over_200k"
+]Output schema / properties / monthlyLeakAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "currency": {
+ "type": "string"
+ },
+ "high": {
+ "type": "number"
+ },
+ "low": {
+ "type": "number"
+ },
+ "text": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "low",
+ "high",
+ "currency",
+ "text"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "The total of all the leaks a month, as the website leads with it. null when no major leak was found."
+}Output schema / properties / primePointAdded value: +{
+ "description": "What one point of prime cost (1% of sales) is worth a month, at the working figure for the sales range.",
+ "type": "string"
+}Output schema / properties / yearlyLeak / descriptionPrevious value: -"null when no major leak was found."New value: +"The same total a year. null when no major leak was found."Output schema / requiredPrevious value: -[
- "country",
- "countryName",
- "grade",
- "risk",
- "needsAttention",
- "needsAttentionText",
- "areas",
- "areasNote",
- "yearlyLeak",
- "leakText",
- "biggest",
- "notes",
- "dayOneFix",
- "link",
- "fullReport",
- "fullReportAdds",
- "disclaimer"
-]New value: +[
+ "country",
+ "countryName",
+ "grade",
+ "risk",
+ "needsAttention",
+ "needsAttentionText",
+ "areas",
+ "areasNote",
+ "monthlyLeak",
+ "yearlyLeak",
+ "leakText",
+ "biggest",
+ "primePoint",
+ "notes",
+ "dayOneFix",
+ "link",
+ "fullReport",
+ "fullReportAdds",
+ "disclaimer"
+]restaurantdoctor_search_knowledgerestaurantdoctor_deadlinesrestaurantdoctor_check_websiterestaurantdoctor_break_even1 field changedInput schema / properties / otherVariable / descriptionPrevious value: -"That month's other costs that rise with every sale: card fees, delivery app commissions (app sales minus payouts), to-go packaging, any percentage rent, royalties or ad fund fees. Nothing already in the food and drink invoices. Required: 0 if none."New value: +"That month's other costs that rise with every sale: card fees, delivery app commissions (app sales minus payouts, both without tax and tips), to-go packaging, any percentage rent, royalties or ad fund fees. Nothing already in the food and drink invoices. Required: 0 if none."restaurantdoctor_delivery_price1 field changedInput schema / properties / rate / descriptionPrevious value: -"One delivery app's real commission rate, as a percent: 30 for 30%, not 0.30. From a month of that app's payout statements: (menu sales before tax and tips − the app's payout) ÷ those menu sales × 100, so marketing fees, promotions the owner funds and refunds are in it; the rate in the app's plan leaves them out. Each app is worked out on its own. Required: 0, or from 1 to 89."New value: +"One delivery app's real commission rate, as a percent: 30 for 30%, not 0.30. From a month of that app's payout statements: (menu sales before tax and tips − the app's payout without tax and tips) ÷ those menu sales × 100, so marketing fees, promotions the owner funds and refunds are in it; the rate in the app's plan leaves them out. Each app is worked out on its own. Required: 0, or from 1 to 89."restaurantdoctor_run_free_check1 field changedOutput schema / properties / biggest / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "kind": {
- "enum": [
- "leak",
- "opportunity"
- ],
- "type": "string"
- },
- "title": {
- "type": "string"
- }
- },
- "required": [
- "kind",
- "title"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "kind": {
+ "enum": [
+ "leak",
+ "opportunity"
+ ],
+ "type": "string"
+ },
+ "monthly": {
+ "additionalProperties": false,
+ "description": "Its estimated money a month, as the website shows it big: lost for a leak, added sales for an opportunity.",
+ "properties": {
+ "currency": {
+ "type": "string"
+ },
+ "high": {
+ "type": "number"
+ },
+ "low": {
+ "type": "number"
+ },
+ "text": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "low",
+ "high",
+ "currency",
+ "text"
+ ],
+ "type": "object"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "title",
+ "monthly"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]restaurantdoctor_break_evenrestaurantdoctor_delivery_pricerestaurantdoctor_labor_costrestaurantdoctor_menu_caloriesrestaurantdoctor_plate_costrestaurantdoctor_prime_costRead-only kitchen costing, recipe scaling, UK GP, starter menus, and prep lists for chefs.
Money, tax & business calculators kept current with 2026 rules — plus operator insights.
The brain for restaurant costs, pricing, and true profit (read/edit menu, recipes, costs).
Free profit check-up for Etsy, Shopify and Amazon sellers: fees, sales, ads, shipping, plans, rates.
Add one secure layer between your agents and this server.
