Skip to main content
Glama
vikstas

Restaurant Ops MCP

by vikstas

Restaurant Ops MCP

Menu sales, food-cost analysis, and contribution rankings through a local CLI and the Model Context Protocol (MCP).

Turn a menu sales export and per-portion ingredient costs into a repeatable operating review. Run reports locally or connect the same calculations to an MCP-compatible assistant.

Tests

Created and maintained by the operator of Balboa Poke, Restaurant Ops MCP brings restaurant operating knowledge to open-source tooling. The project uses deterministic Python calculations, documented assumptions, and automated checks to make menu economics inspectable and repeatable.

Release: v0.2.0a1 · Python 3.10–3.14 tested · MIT licensed.

Engineering and verification

  • Shared calculation logic: the CLI and MCP tools use the same menu metrics.

  • 46 automated tests: arithmetic, CSV validation, command-line behavior, and an actual MCP client/server connection, including recovery after invalid input.

  • Compatibility checks: CI covers Python 3.10–3.14 and the minimum supported MCP SDK version.

  • Package verification: CI builds distribution archives, checks metadata, and tests an installed wheel.

  • Reviewable changes: feature branches, pull requests, and passing CI precede merges; release notes document supported behavior.

Related MCP server: mcp-csv-database

Why this exists

Restaurant operators often have useful data trapped in POS exports and spreadsheets, but turning that data into clear decisions usually requires manual analysis.

Restaurant Ops MCP exposes auditable tools that an MCP-compatible AI assistant can call to answer questions such as:

  • Which menu items contribute the most after ingredient costs?

  • What is the food-cost percentage for each item?

  • Which items sell well but have weak contribution margins?

Price-change scenarios and period comparisons are planned, not implemented yet.

Calculations run in Python, independently of the assistant, so operators and contributors can inspect and test how each result is produced.

Current tools

calculate_menu_item_metrics

Calculates:

  • food-cost percentage

  • contribution margin per unit

  • gross sales

  • total ingredient cost

  • total contribution margin

analyze_menu_csv

Accepts CSV text with these columns:

item,selling_price,ingredient_cost,units_sold

It returns a menu-level summary, item rankings by total contribution margin, and warnings for loss-making items or a period with no sales.

Synthetic example data is available in examples/menu.csv.

Review your week without an AI assistant

After installing, run:

restaurant-ops examples/menu.csv

The sample has sales of 8,152.50 across 615 units. The report shows theoretical ingredient cost, weighted food-cost percentage, and items ranked by contribution after ingredients. Amounts use the currency supplied in the CSV; do not mix currencies.

For machine-readable output:

restaurant-ops examples/menu.csv --json

See the weekly review guide for preparing your own data, interpreting results, and recording useful feedback. No AI account is needed for this local report.

Quick start

For a versioned source download, see GitHub releases. Extract the source archive, open its folder, and follow the virtual-environment and pip installation steps below (skip git clone when using an archive). This project is not published to PyPI; install from this repository or its releases.

Requirements

  • Python 3.10+

  • uv recommended, or any normal Python environment

  • Node.js/npm only if you want the optional browser-based MCP Inspector

Using uv

git clone https://github.com/vgdikyan-droid/restaurant-ops-mcp.git
cd restaurant-ops-mcp
uv sync --extra dev
uv run restaurant-ops examples/menu.csv

For the optional MCP Inspector, run uv run mcp dev src/restaurant_ops_mcp/server.py.

Using pip

git clone https://github.com/vgdikyan-droid/restaurant-ops-mcp.git
cd restaurant-ops-mcp
python -m venv .venv
source .venv/bin/activate
pip install -e ".[dev]"
restaurant-ops examples/menu.csv

On Windows, activate with .venv\Scripts\Activate.ps1 in PowerShell.

Connect an MCP client

This project uses the official MCP Python SDK v2 (mcp>=2.0,<3.0) and MCPServer. It is not the separate FastMCP package. See the official SDK documentation.

The installed restaurant-ops-mcp command runs the server over standard input/output (stdio). The client launches it when needed; it does not open a web port. Running it by itself waits quietly for protocol messages.

For clients that accept an mcpServers JSON configuration, use your installed environment's absolute executable path:

{
  "mcpServers": {
    "restaurant-ops": {
      "command": "/absolute/path/to/restaurant-ops-mcp/.venv/bin/restaurant-ops-mcp",
      "args": []
    }
  }
}

On Windows the executable is .venv\\Scripts\\restaurant-ops-mcp.exe. Configuration location varies by client. A client can also launch the virtual environment's Python with arguments -m restaurant_ops_mcp.server.

Try: “Use the restaurant tools to calculate a menu item with selling price 20, ingredient cost 6, and 10 units sold.” Expected total contribution: 140. The CSV tool accepts CSV text, not a filename, and does not read arbitrary files. If you use an AI client, CSV content and results may be sent to that client's provider. The standalone CSV report runs locally.

What these numbers mean

  • Ingredient cost is the recipe cost per portion; units sold cover one period.

  • Food-cost percentage = ingredient cost / selling price × 100.

  • Weighted food-cost percentage = total ingredient cost / total sales × 100.

  • Contribution = sales minus ingredients. It excludes labor, rent, payment and delivery fees, waste, and other costs, so it is not net profit.

  • These are theoretical food costs, not actual inventory usage or purchase totals.

  • Amounts are rounded to two decimal places for display; this is an operating estimate, not an accounting ledger.

  • The JSON field gross_sales is price × units. Use realized prices after discounts and before tax/tips to approximate your POS sales consistently.

  • With no units sold, the text report shows food cost as N/A. The JSON field weighted_food_cost_pct retains 0.0 for compatibility, alongside a warning.

Example CSV

item,selling_price,ingredient_cost,units_sold
Salmon Bowl,18.50,6.40,120
Chicken Bowl,15.00,4.10,180
Spicy Tuna Roll,13.50,4.70,95

Project principles

  1. Useful before clever — tools should answer real operating questions.

  2. Auditable math — calculations should be easy to inspect and test.

  3. Portable data — start with CSV and simple schemas instead of locking users into one POS vendor.

  4. AI as an interface, not the source of truth — the model can reason over results, but the underlying calculations stay deterministic.

Roadmap

  • Menu-item margin calculator

  • CSV menu analysis

  • Automated tests

  • Local CSV report for weekly reviews

  • MCP connection test and CSV validation

  • Compare periods (week vs. week / month vs. month)

  • Ingredient price-change scenarios

  • Menu engineering quadrants

  • Inventory variance analysis

  • POS-specific import adapters

  • Example Claude Desktop / Claude Code configuration

Contributing

Contributions are welcome, especially from restaurant operators, hospitality technologists, and developers interested in practical MCP tooling.

See CONTRIBUTING.md.

To try a real workflow, follow the pilot checklist. Report a reproducible bug or operator feedback using the GitHub issue templates.

License

MIT

Available Tools

2 tools
analyze_menu_csvA

Analyze menu economics from CSV text.

The CSV must include these columns: item,selling_price,ingredient_cost,units_sold

Returns menu-level totals and items ranked by total contribution margin. Costs are theoretical recipe costs, not measured purchases or inventory usage. Contribution excludes labor, rent, fees, waste, and other operating costs.

ParametersJSON Schema
NameRequiredDescriptionDefault
csv_textYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden and does so well: it clarifies that costs are theoretical recipe costs rather than measured purchases, and that contribution excludes labor, rent, fees, waste and other operating costs. This scoping is exactly the kind of context an agent needs to interpret results correctly; only rate limits/error behavior are absent.

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?

Front-loaded purpose sentence followed by a compact required-columns block and two clarifying caveats; every sentence earns its place. The 'these columns' phrasing wraps an inline list rather than a markdown list, a minor formatting nit.

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

Completeness4/5

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

For a single-parameter analysis tool with an output schema present, the description need not explain return values, yet it adds a useful summary of the return shape plus caveats on cost basis and contribution scope. Complete enough to invoke correctly; only sibling disambiguation and error/limit behavior are missing.

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

Parameters4/5

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

Schema description coverage is 0% and the single parameter has no schema-level description, so the description must compensate. It does: it specifies the exact required columns (item, selling_price, ingredient_cost, units_sold) for csv_text, giving concrete meaning the schema lacks.

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

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Analyze menu economics from CSV text') and names the required input format, so the agent knows exactly what the tool consumes and produces. It does not differentiate from the sibling calculate_menu_item_metrics, which keeps it from a 5.

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

Usage Guidelines3/5

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

The description effectively defines the precondition for use by listing the exact required CSV columns, which tells the agent when this tool is applicable. However, it never states when to prefer it over calculate_menu_item_metrics or any exclusion criteria, leaving the sibling choice to inference.

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

calculate_menu_item_metricsB

Calculate food cost and contribution margin for one menu item.

Args: selling_price: Realized selling price per unit, excluding tax and tips. ingredient_cost: Direct ingredient cost for one unit. units_sold: Number of units sold in the period being analyzed.

ParametersJSON Schema
NameRequiredDescriptionDefault
units_soldNo
selling_priceYes
ingredient_costYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden. It never states that this is a side-effect-free computation, whether it is deterministic, or — most importantly for a metrics tool — how contribution margin is derived (e.g., selling_price - ingredient_cost) or how units_sold affects the outputs. The behavioral contract of the calculation is undisclosed.

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 purpose is front-loaded in a single tight sentence, followed by a compact Args list where each line earns its place. No redundancy or filler; the only nit is the Python-docstring formatting, which is slightly off-register for a tool description.

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

Completeness4/5

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 described, and all three parameters are documented despite 0% schema coverage. What remains missing is the contribution-margin formula and how the optional units_sold default of 1 shapes the result.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must compensate, and it does: it defines selling_price as realized price excluding tax and tips, ingredient_cost as direct cost for one unit, and units_sold as units in the analyzed period. It adds real meaning beyond the bare titles, though it omits units/currency and how units_sold is used.

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

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence names a specific verb (calculate) and the exact outputs (food cost and contribution margin) scoped to a single menu item, so the resource is unambiguous. It does not distinguish itself from the sibling analyze_menu_csv, but the single-item vs. CSV scope difference is inferable from the text.

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

Usage Guidelines2/5

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

Nothing states when to reach for this tool versus analyze_menu_csv, nor any prerequisites or context about the period being analyzed. The agent is left to infer usage entirely from the name and one-line purpose.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv0.1.0
    • First observedanalyze_menu_csv
    • First observedcalculate_menu_item_metrics

TDQS

A3.6/5.0

Scored across 2 tools

Disambiguation4/5

The two tools operate at different granularities: one calculates metrics for a single item, while the other parses and analyzes a full menu CSV. There is minor conceptual overlap because both compute contribution margin, but the input format and output scope are sufficiently distinct.

Naming Consistency5/5

Both names use snake_case and follow a verb_noun pattern (calculate_menu_item_metrics, analyze_menu_csv). The convention is consistent and readable throughout.

Tool Count3/5

The server name implies broader restaurant operations, but only two narrow menu-economics tools are provided. While the pair covers single-item and batch analysis, the surface feels thin for the stated scope.

Completeness4/5

For menu economics, item-level and menu-level contribution analysis covers the core workflow. Minor gaps exist around period comparisons, pricing scenarios, or export/reporting, but agents can work around them.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive

Related MCP Connectors

  • MerchantFlow is a hosted, read-only ecommerce analytics MCP server for Shopify and WooCommerce. It gives AI assistants tenant-scoped access to revenue, profit and loss, product and SKU profitability, COGS coverage, fulfillment costs, advertising spend, ROAS, marketing performance, cohorts, LTV, and business valuation across connected commerce and marketing platforms. Connect with OAuth over Streamable HTTP. No local server installation is required.

  • Connect your ads, shop, analytics, social, CRM and finance platforms once, then let Claude, ChatGPT, Cursor or any MCP client read, join and explain your numbers. Public statistics from the World Bank, IMF, Eurostat, OECD, WHO and SEC filings come as context, searchable and chartable from the same tools. Read-only by design, every number carries its source.

  • Query your warehouse or a CSV with Claude/ChatGPT over MCP, governed by table-level ACL + audit.

  • Connects Amazon Seller Central and Amazon Advertising to any MCP client. Settlement-accurate P&L - every fee, refund and reimbursement as Amazon posted it - plus contribution margin and breakeven per product, per marketplace, per day. Full Sponsored Products, Brands and Display management: search terms, placements, keyword and competitor research, dayparting, automation rules. 110 tools: 78 read-only (P&L, PPC at every grain, SQP/Brand Analytics, inventory, forecasting), 28 staged writes (every change is a proposal you review and confirm before it reaches Amazon - there is no autonomous-write mode), and 4 confirmation & support tools. 4 additional AI Workforce tools appear once a client is connected.

Related MCP Servers

  • A
    license
    A
    quality
    Not graded
    maintenance
    An MCP server that enables AI assistants to load, query, and analyze local CSV files using tools for filtering, aggregation, and grouping. It provides capabilities to describe schemas, calculate statistics, and sample data directly from CSV files.
    6
    -
  • F
    license
    Not graded
    quality
    D
    maintenance
    A local MCP server for analyzing CSV files from your filesystem, particularly suited for chatbot conversation logs. Allows listing, reading, filtering, merging, and statistical analysis of CSV data via natural language.
    -