RestaurantDoctorAI Profit Check

Run the free profit check

restaurantdoctor_run_free_check

Read-onlyIdempotent

Scores a restaurant's 12 answers against industry benchmarks for its type of restaurant and returns the free result the website shows: an overall grade, grades by area, the estimated yearly profit leak, the biggest leak or opportunity and the first fix. Includes a link that opens the same result on restaurantdoctorai.com. The result also notes the paid full report on the website, its price and what it adds. Takes only the 12 answers and the country; restaurantdoctor_get_questions gives the wording of each answer value. The answers aren't stored; only an anonymous daily count of checks is kept.

Input Schema

TableJSON Schema

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).
`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; 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).
`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).

Output Schema

TableJSON Schema

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
`areasNote`	Yes
`dayOneFix`	Yes
`disclaimer`	Yes
`fullReport`	Yes
`yearlyLeak`	Yes	null when no major leak was found.
`countryName`	Yes
`fullReportAdds`	Yes	What the paid full report adds.
`needsAttention`	Yes
`needsAttentionText`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 1, 2026

TDQS

A4.2/5.0

Behavior4/5

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, so the safety profile is clear. The description adds important behavioral context beyond those annotations: answers are not stored, only an anonymous daily count is kept, and the returned result includes a website link plus a note about the paid full report. It does not cover rate limits or error behavior, but for a read-only scoring tool this is solid additional disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action and remains readable despite being dense. It includes some return-value detail that overlaps with the existing output schema, such as listing the overall grade, area grades, profit leak, first fix, and website link. That small redundancy keeps it from being maximally concise, but every sentence still contributes useful routing or behavioral context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is complex with 13 parameters, 12 required enums, an output schema, and annotations. The description covers the input contract, the sibling tool for answer wording, the anonymity/storage behavior, and the shape of the returned free result. Given that an output schema exists, the description need not explain return values, yet it still provides enough summary for an agent to know what to expect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and every parameter, including all 12 enums, is documented in the schema itself. The description adds little parameter-level meaning beyond stating that the tool takes the 12 answers and country, and it defers answer wording to restaurantdoctor_get_questions. With the schema doing all the heavy lifting, a baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

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 scores 12 restaurant answers against benchmarks and returns a free result. It also distinguishes itself from the sibling by explicitly assigning wording lookup to restaurantdoctor_get_questions. An agent can tell exactly what this tool does and how it differs from the only sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clarifies the input scope ('takes only the 12 answers and the country') and names the sibling for answer wording, which implies when to use each tool. However, it does not give an explicit when-not-to-use rule or a clear ordering requirement such as 'call get_questions first if answer values are unknown.' The context is strong but lacks full explicit routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All RestaurantDoctorAI Profit Check tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?