レシピの原価計算とメニュー価格設定を行うMCPアプリ — モデルが自ら計算する代わりに開くインタラクティブな計算機です。
Claudeに「私のナシゴレンの価格設定を手伝って」と頼むと、動作するスプレッドシートが得られます。材料の行、購入価格、廃棄率、歩留まり、マージンスライダー。数字を変えると、すべてが再計算されます。これらの数字を使うを押すと、モデルは自分がでっち上げた数字ではなく、あなたが入力した数字で会話を続けます。
MCP Apps（ext-apps）上に構築されています。
ext-appsのbasic-hostリファレンスホストで実行中 — Claudeではありません。モデルがレシピを提案し、ウィジェットがそれを読み込み、「これらの数字を使う」が修正された数字を会話に送り返しました。
原価計算は探索であり、質問ではありません。分量を動かしてマージンが動くのを見るまで、欲しい答えはわかりません。チャットはそのためのインターフェースとしては不向きで、モデルが頭の中で計算するのはさらに悪い — LLMは多段階の数値計算には信頼できず、確信を持っているように聞こえることには完全に信頼できます。
つまり分担はこうです：ウィジェットが入力を取得し、サーバーが計算を行い、モデルが会話をします。
Related MCP server: ScenarioSim MCP
MCP Appsには未解決のギャップがあります — ext-apps#746：ウィジェットからのtools/callとモデルが行うことを決定したものは、サーバーでは区別できません。ほとんどのツールではそれは問題になりません。原価計算ツールでは、それが計算をしているのか、推測を偽装しているのかを決定します。
mcp-app-attestがそれを解決します — このリポジトリから抽出され、最初の利用者です。サーバーはアプリリソースを提供するたびに短命のトークンを発行し、ドキュメントに置き換えます。ウィジェットは毎回の呼び出しで_metaにそれをエコーバックします。モデルはリソース本文を見ることはないので、トークンを生成できません。呼び出しはどちらにせよ応答されます — 応答はどちらが取得したかを示します：
{ "perPortion": 3300, "inputsFrom": "model" }そして数字がモデルから来た場合、テキスト返信はその旨を述べます：
注：これらの数字は計算機ではなくモデルから来たものです。それらに依存する前に、購入価格をユーザーに確認してください。
リファレンスホストに対してエンドツーエンドで検証済みで、単体テストだけではありません：
[provenance] inputsFrom=model reason=missing meta=null
[provenance] inputsFrom=app meta={..."io.platecost/app-attestation":"XfqGVAiP…"}これは何ではないか。 認証でもなく、人間が何かを入力した証拠でもありません。コードパスを区別するものであり、アイデンティティではありません。ホストがリソーステキストをモデルコンテキストにコピーした場合、モデルはトークンを読むことができます — ここではそれを防ぐものは何もなく、それはホストが守るべき契約です。侵害されたウィジェットは好きなものを送信できます。「私のフォームに入力された」と「言語モデルによって生成された」の違いとして扱ってください。それはまさに#746が求めているものです。
その後、mcp-app-attestに抽出され、保存トークンではなく署名付きトークンに切り替わりました — その理由は下の「うまくいかなかったこと」の注を参照してください。
両方ともsrc/costing.tsにあり、両方ともテストがあります。
廃棄はより多く使うのではなく、より多く買うことを意味します。 コストはused / (1 - wastePct)であり、used * (1 + wastePct)ではありません。廃棄率50%では、1.5倍ではなく2倍を買います。単純なバージョンは、あなたが所有するすべてのトリミングされた材料を過小評価します。
マージンとマークアップは異なる数字です。 マージンは(price - cost) / price、マークアップは(price - cost) / costです。60%のマークアップは37.5%のマージンであり、60%のマージンには150%のマークアップが必要です。priceForMarginはマージンを受け取ります — それはキッチンで「65%が欲しい」という意味です — そして両方を返すので、ギャップが想定ではなく見えるようになります。
また処理されるもの：質量と体積のファミリー内の単位変換、それらをまたぐ場合の拒否（kg → lには密度が必要ですが、それは与えられていません）、材料ごとのコスト配分、およびバッチごとではなくポーションごとに適用される間接費。
npm install
npm run build # bundles the widget to a single inlined HTML
npm test # 21 tests
npm run dev # widget standalone in a browser, no hostMCPクライアントをserver.tsに向けてください。ホストの外ではアテステーションプレースホルダーは置き換えられないため、呼び出しはmodelとラベル付けされます — それが正直な答えです。
ステートレスなHTTPトランスポート。 最初のバージョンはリクエストごとに新しいサーバーを構築しました。これはステートレスなツールには問題ありませんが、このツールを静かに壊します：アテステーションはウィジェットがコールバックした時点で存在しなくなったサーバーインスタンスによって発行されたため、すべてのウィジェット呼び出しがunknownとして拒否されました。インメモリテストではそれを見ることができませんでした — それらは1つのインスタンスを共有しています。実際のホストに対して実行したときだけ、それが明らかになりました。
SDKのせいにすること。 上記を見つける前に、明白な容疑者は_metaが転送中に削除されることでした。そうではありません：リファレンスホストはサンドボックスプロキシを通してそれを完全に転送します。知っておく価値があります。なぜなら、メカニズム全体がホストがそうすることを依存しており、仕様はそれを要求していないからです。
v0。2つのツール（cost-recipe、price-portion）、1つのウィジェット、21のテスト。
未構築：会話間の永続化、複数レシピの比較、および#753 / #745の名前空間問題に触れるもの — callServerToolは裸のツール名を使用するため、これはアグリゲーターの背後で壊れます。それは次に解決する価値があるものであり、ここでは解決されていません。
MIT。
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.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| ingredients | Yes | ||
| yieldPortions | Yes | ||
| overheadPerPortion | No |
| Name | Required | Description |
|---|---|---|
| perBatch | Yes | |
| breakdown | Yes | |
| inputsFrom | Yes | |
| perPortion | Yes | |
| overheadPerPortion | Yes | |
| ingredientCostPerPortion | Yes |
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.
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| cost | Yes | ||
| price | No | ||
| targetMarginPct | No |
| Name | Required | Description |
|---|---|---|
| cost | Yes | |
| price | Yes | |
| profit | Yes | |
| marginPct | Yes | |
| markupPct | Yes | |
| foodCostPct | Yes |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0cost-recipeprice-portionScored across 2 tools
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.
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.
Two tools is thin for a costing/pricing domain; it may be intentionally narrow, but it is borderline for useful coverage.
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.
The brain for restaurant costs, pricing, and true profit (read/edit menu, recipes, costs).
Read-only kitchen costing, recipe scaling, UK GP, starter menus, and prep lists for chefs.
Auditable construction takeoffs with locked waste and conservative purchase rounding.
Read recipes, nutrition and inventory, manage ingredients and costs, and render ReciPal labels.
