Skip to main content
Glama
deenesjakoruzh
rephol

plate-cost

by rephol
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

plate-cost

An MCP App that costs recipes and prices menu items — an interactive calculator the model opens instead of doing the arithmetic itself.

Ask Claude "help me price my nasi goreng" and you get a working spreadsheet: ingredient rows, purchase prices, waste percentages, portion yield, a margin slider. Change a number, everything recalculates. Press Use these numbers and the model continues the conversation with figures you entered rather than figures it invented.

Built on MCP Apps (ext-apps).

plate-cost running in the ext-apps reference host

Running in the basic-host reference host from ext-apps — not Claude. The model proposed the recipe, the widget loaded it, and "Use these numbers" sent the corrected figures back into the conversation.

Why this is an app and not a tool

Costing is exploration, not a question. You do not know the answer you want until you have moved the portion size and watched the margin move. Chat is a bad interface for that, and a model doing the arithmetic in its head is worse — LLMs are unreliable at multi-step numeric work and completely reliable at sounding certain about it.

So the split is: the widget captures inputs, the server does the maths, the model does the talking.

Related MCP server: TradingCalc MCP Server

The interesting part: knowing where the numbers came from

MCP Apps has an open gap — ext-apps#746: a tools/call from a widget and one the model decided to make are indistinguishable at the server. For most tools that does not matter. For a costing tool it decides whether you are doing arithmetic or laundering a guess.

mcp-app-attest closes it — extracted from this repo, which is its first consumer. The server mints a short-lived token each time it serves the app resource and substitutes it into the document; the widget echoes it back in _meta on every call. The model never sees the resource body, so it cannot produce the token. Calls are answered either way — the response says which it got:

{ "perPortion": 3300, "inputsFrom": "model" }

and when the numbers came from the model, the text reply says so:

Note: these figures came from the model, not from the calculator. Confirm the purchase prices with the user before relying on them.

Verified end to end against the reference host, not just in unit tests:

[provenance] inputsFrom=model  reason=missing  meta=null
[provenance] inputsFrom=app    meta={..."io.platecost/app-attestation":"XfqGVAiP…"}

What this is not. Not authorisation, and not proof a human typed anything. It distinguishes code paths, not identities. If a host copies the resource text into model context, the model can read the token — nothing here prevents that, it is the host's contract to keep. A compromised widget can send whatever it likes. Treat it as the difference between "typed into my form" and "produced by a language model", which is exactly what #746 asks for.

It has since been extracted into mcp-app-attest, which switched to signed tokens rather than stored ones — see the "what didn't work" note below for why.

Two things the domain gets wrong

Both are in src/costing.ts, both have tests.

Waste means buying more, not using more. Cost is used / (1 - wastePct), not used * (1 + wastePct). At 50% waste you buy double, not one and a half times. The naive version understates every trimmed ingredient you own.

Margin and markup are different numbers. Margin is (price - cost) / price; markup is (price - cost) / cost. A 60% markup is a 37.5% margin, and a 60% margin needs a 150% markup. priceForMargin takes margin — that is what "we want 65%" means in a kitchen — and returns both, so the gap is visible rather than assumed.

Also handled: unit conversion within mass and volume families, with a refusal across them (kg → l needs a density you have not given), per-ingredient cost share, and overhead applied per portion rather than per batch.

Try it

npm install    # pulls mcp-app-attest from npm
npm run build      # bundles the widget to a single inlined HTML
npm test           # 21 tests
npm run dev        # widget standalone in a browser, no host

In Claude Desktop

Build first, then add to claude_desktop_config.json:

{
  "mcpServers": {
    "plate-cost": {
      "command": "node",
      "args": ["--experimental-strip-types", "/absolute/path/to/plate-cost/bin/stdio.ts"]
    }
  }
}

npm start runs the same thing directly. Requires Node 22+ for type stripping.

Against an MCP Apps host over HTTP

npm run serve      # http://localhost:3001/mcp

Used with the basic-host example from ext-apps to produce the screenshot above.

Outside any host the attestation placeholder is never substituted, so calls are labelled model — which is the honest answer.

What didn't work

  • A stateless HTTP transport. The first version built a fresh server per request, which is fine for stateless tools and silently breaks this one: the attestation was minted by a server instance that no longer existed when the widget called back, so every widget call was rejected as unknown. The in-memory tests could not see it — they share one instance. Only running against a real host exposed it.

  • Blaming the SDK. Before finding the above, the obvious suspect was _meta being stripped in transit. It is not: the reference host forwards it intact through the sandbox proxy. Worth knowing, because the whole mechanism depends on hosts doing so and the spec does not require it.

Status

v0. Two tools (cost-recipe, price-portion), one widget, 21 tests.

Not built: persistence between conversations, multi-recipe comparison, and anything touching the namespacing problem in #753 / #745 — callServerTool uses bare tool names, so this will break behind an aggregator. That is the next thing worth solving and it is not solved here.

MIT.

Available Tools

2 tools
cost-recipeCost a recipeB

Cost one batch of a recipe and one portion of it, given ingredient purchase prices, quantities used, waste percentages and portion yield. Opens an interactive calculator. Do not compute food costs yourself — call this.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYes
ingredientsYes
yieldPortionsYes
overheadPerPortionNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
perBatchYes
breakdownYes
inputsFromYes
perPortionYes
overheadPerPortionYes
ingredientCostPerPortionYes

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries the full burden, but it does disclose a meaningful behavioral trait: the tool 'opens an interactive calculator' rather than silently returning a number, and it warns against self-computation. It omits any note on side effects, permissions, or whether the interactive session blocks, and an output schema covers the return payload.

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?

Three short sentences, front-loaded with the core action and ending on the key directive. Every sentence carries content, though the fragments 'given…' and the calculator note could be tightened.

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

Completeness3/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 no explanation, and the description covers the main input concepts. It still leaves overheadPerPortion undocumented and provides no basis for choosing between this tool and price-portion, which is a real gap for a 4-parameter tool with an undocumented optional field.

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 0%, so the description must compensate. It does name the ingredient-side concepts (purchase prices, quantities used, waste percentages, portion yield), mapping to four of the parameters, but the optional overheadPerPortion parameter is never mentioned and no unit/format semantics are clarified.

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+resource ('cost one batch of a recipe and one portion') plus the key input categories, which is more than a restatement of the name. It does not, however, differentiate itself from the sibling price-portion, so an agent cannot tell the two apart from the description alone.

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?

Explicitly directs the agent to use this tool rather than computing food costs itself ('Do not compute food costs yourself — call this'), which is genuine usage guidance. It offers no condition for preferring this over the sibling price-portion, so routing between the two 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.

price-portionPrice a portionA

Turn a portion cost into a selling price at a target margin, and report margin, markup and food-cost percentage. Margin and markup are different numbers — call this rather than converting between them yourself.

ParametersJSON Schema
NameRequiredDescriptionDefault
costYes
priceNo
targetMarginPctNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
costYes
priceYes
profitYes
marginPctYes
markupPctYes
foodCostPctYes

TDQS

A4.2/5.0
Behavior3/5

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

No annotations, so the description carries the burden. It discloses the computed outputs (margin, markup, food-cost percentage) and warns about margin/markup confusion, but says nothing about required inputs, error behavior, or how cost/price/targetMarginPct interact (e.g., whether price overrides targetMarginPct).

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

Conciseness5/5

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

Two tight sentences, front-loaded with the core action and ending on the key disambiguation. No wasted words.

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?

Output schema exists, so return-value detail is unnecessary. The description covers the tool's purpose and usage warning but is thin on the input parameter interaction (price vs targetMarginPct) given 0% schema coverage.

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 coverage is 0%, so description must compensate. It clarifies the semantic dependency of the three fields implicitly (cost in, target margin or price out) and defines margin/markup, partially compensating. However, it doesn't explain the precedence between providing 'price' vs 'targetMarginPct'.

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?

States a specific verb (price) and resources (portion cost → selling price) and the exact computation (target margin, reporting margin/markup/food-cost %). Distinguishes from sibling cost-recipe by being about pricing rather than costing a recipe.

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?

Gives a clear conditional steer: 'call this rather than converting between them yourself' for margin vs markup conversion, implying when-to-use over manual math. No explicit exclusion vs cost-recipe, but context is clear.

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 observedcost-recipe
    • First observedprice-portion
Deploy Server
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

TDQS

A3.5/5.0

Scored across 2 tools

Disambiguation4/5

The two tools have distinct purposes: costing a recipe versus converting a cost into a selling price. There is minor thematic overlap around food-cost math, but each description clarifies the boundary.

Naming Consistency3/5

Both names use a noun_noun or verb_noun style ('cost-recipe', 'price-portion') with hyphenation, but the verb-first pattern is only loosely applied and not fully predictable.

Tool Count3/5

Two tools is thin for a costing/pricing domain; it may be intentionally narrow, but it is borderline for useful coverage.

Completeness3/5

The surface covers recipe costing and portion pricing, but lacks operations for managing ingredients, recipes, or price lists, creating notable gaps for a full workflow.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Calculator MCP Server

    mzdz
    F
    license
    Not graded
    quality
    D
    maintenance
    Provides basic arithmetic operations and advanced mathematical functions through the Model Context Protocol (MCP), with features like calculation history tracking and expression evaluation.
    1
    -

  • TradingCalc MCP Server

    SKalinin909
    A
    license
    Not graded
    quality
    A
    maintenance
    Provides deterministic trading calculations for PnL, risk, margin, and funding, enabling users to get exact numbers for trade planning and risk assessment via MCP or REST API.
    595 npm
    1
    MIT
  • Octura Solutions Site Tools by Octura-solutions

    Octura Solutions Site Toolsofficial

    Octura-solutions
    A
    license
    C
    quality
    B
    maintenance
    Deterministic Odoo ERP calculators: implementation, migration and upgrade cost, ROI and TCO, US/Canada/EU sales tax and VAT, Canadian payroll source deductions, and inventory maths (reorder point, safety stock, EOQ, landed cost, OEE). 24 tools, each a pure function, the numbers are arithmetic rather than a model's guess. Hosted remote server, no install and no API key; a stdio bridge is included
    24
    MIT

  • ScenarioSim MCP

    inity13
    A
    license
    A
    quality
    A
    maintenance
    A deterministic what-if scenario simulation MCP server that projects business metrics over time with exact decimal arithmetic, offering sensitivity analysis and break-even solving.
    6
    31 npm
    1
    MIT