Free restaurant profit check: 12 multiple-choice questions, a grade, and the biggest money leak.
Scored across 2 tools
The two tools have clearly distinct purposes: one retrieves the questionnaire, the other scores answers and returns results. There is no overlap in function, so an agent can easily choose the right tool for each step.
Both tools use a consistent snake_case naming pattern with the same `restaurantdoctor_` prefix followed by verb_noun forms (`get_questions`, `run_free_check`). The convention is predictable and readable.
Two tools is slightly below the typical 3–15 range, but the server has a very narrow purpose: exposing a single free profit check. Each tool is essential and there is no redundancy, so the count is appropriate for the scope even if minimal.
The tools cover the complete free-check workflow: fetching questions and submitting answers to get a scored result. A minor gap is the lack of a tool to retrieve or interact with the paid full report, but the result links to the website, so agents can work around it.
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 declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds real context beyond them: the fixed count of 12 questions, that each question exposes its accepted answer values, and that money ranges, delivery apps and review sites are localized to the restaurant's country.
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 sentences, zero filler, front-loaded with what the tool returns before the localization caveat. Nothing repeats the title or schema verbatim for its own sake.
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-format explanation is unnecessary, and the description still usefully previews the payload (12 questions plus accepted values). Combined with a single optional, fully documented parameter and read-only annotations, an agent has everything needed to call it correctly; only an explicit link to the sibling workflow 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. The description nonetheless adds meaning the schema does not: it enumerates which parts of the content localize (money ranges, delivery apps, review sites) rather than just saying 'currency and local wording', which clarifies the practical effect of the country parameter.
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 (lists) and a precise resource (the 12 multiple-choice questions of the free restaurant profit check), and even states what each item contains (accepted answer values). The scope is clearly a read/retrieval operation, which implicitly separates it from the sibling restaurantdoctor_run_free_check, though that sibling is never named.
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 is the step that fetches the question set (likely before submitting answers via run_free_check). There is no explicit when-to-use statement, no when-not-to-use, and no mention of the alternative tool, so the routing decision 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.
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.
| 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). |
| 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 |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
restaurantdoctor_get_questionsrestaurantdoctor_run_free_checkThe brain for restaurant costs, pricing, and true profit (read/edit menu, recipes, costs).
8-dimension business diagnosis with Revenue Leak Score and triple-option recommendations
Run your restaurant from an AI client: orders, menu, reports, refunds, payouts and staff.
Match a restaurant to a MyShop solution and send a real, signable $89/month quote by email.
Add one secure layer between your agents and this server.
