RecipeScale

Cost per serving

cost_per_serving

Read-onlyIdempotent

Total the cost of a recipe's ingredients and work out the cost per serving and per 10 servings. Use when budgeting a dish, pricing meal prep or comparing recipes on cost. Do NOT use to resize the recipe (use scale_recipe first, then price the scaled amounts here).

Input Schema

Name	Required	Description
`currency`	No	Currency code for display only, e.g. 'EUR'; default USD
`servings`	Yes	How many servings the recipe makes, positive, e.g. 4
`ingredients`	Yes	Priced ingredients, e.g. [{"item":"chicken","cost":8.5},{"item":"rice","cost":1.2}]

Output Schema

Name	Required	Description
`note`	Yes	Plain-language cost summary
`currency`	Yes	Currency code used in the results (upper case)
`servings`	Yes	Servings the recipe makes
`total_cost`	Yes	Sum of all ingredient costs
`per_serving`	Yes	Cost per serving, rounded to cents
`per_ten_servings`	Yes	Cost for 10 servings, rounded to cents

Schema Changelog

Changes observed during successful MCP inspections.

Changed16 schema fields changedOct 10, 2026

changedInput schema / properties / currency / description

Previous value: -"Currency code for display, default USD"New value: +"Currency code for display only, e.g. 'EUR'; default USD"

changedInput schema / properties / ingredients / description

Previous value: -"Priced ingredients"New value: +"Priced ingredients, e.g. [{\"item\":\"chicken\",\"cost\":8.5},{\"item\":\"rice\",\"cost\":1.2}]"

changedInput schema / properties / ingredients / items / properties / cost / description

Previous value: -"Cost of the amount used in the recipe"New value: +"Cost of the amount used in the recipe, 0 or more, in the given currency"

addedInput schema / properties / ingredients / items / properties / cost / minimum
```
Added value: +0
```
addedInput schema / properties / ingredients / minItems
```
Added value: +1
```

changedInput schema / properties / servings / description

Previous value: -"How many servings the recipe makes"New value: +"How many servings the recipe makes, positive, e.g. 4"

addedInput schema / properties / servings / exclusiveMinimum
```
Added value: +0
```

removedOutput schema / properties / cost_for_10_servings

Removed value: -{
-  "description": "The cost for 10 servings in the specified currency",
-  "type": "number"
-}

removedOutput schema / properties / cost_per_serving

Removed value: -{
-  "description": "The cost per serving in the specified currency",
-  "type": "number"
-}

changedOutput schema / properties / currency / description

Previous value: -"The currency code used for the cost calculations"New value: +"Currency code used in the results (upper case)"

addedOutput schema / properties / note

Added value: +{
+  "description": "Plain-language cost summary",
+  "type": "string"
+}

addedOutput schema / properties / per_serving

Added value: +{
+  "description": "Cost per serving, rounded to cents",
+  "type": "number"
+}

addedOutput schema / properties / per_ten_servings

Added value: +{
+  "description": "Cost for 10 servings, rounded to cents",
+  "type": "number"
+}

addedOutput schema / properties / servings

Added value: +{
+  "description": "Servings the recipe makes",
+  "type": "number"
+}

addedOutput schema / properties / total_cost

Added value: +{
+  "description": "Sum of all ingredient costs",
+  "type": "number"
+}

changedOutput schema / required

Previous value: -[
-  "cost_per_serving",
-  "cost_for_10_servings",
-  "currency"
-]New value: +[
+  "currency",
+  "total_cost",
+  "servings",
+  "per_serving",
+  "per_ten_servings",
+  "note"
+]

Changed1 schema field changedOct 6, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "cost_for_10_servings": {
+      "description": "The cost for 10 servings in the specified currency",
+      "type": "number"
+    },
+    "cost_per_serving": {
+      "description": "The cost per serving in the specified currency",
+      "type": "number"
+    },
+    "currency": {
+      "description": "The currency code used for the cost calculations",
+      "type": "string"
+    }
+  },
+  "required": [
+    "cost_per_serving",
+    "cost_for_10_servings",
+    "currency"
+  ],
+  "type": "object"
+}

First observedOct 4, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is low. The description adds useful behavioral context beyond them: it discloses the two derived outputs (per serving and per 10 servings) and the workflow dependency that scaling must happen beforehand. It does not discuss error behavior or how missing/invalid costs are handled, keeping it short of a 5.

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?

Three tight sentences: purpose first, then usage contexts, then the exclusion/ordering rule. No filler and the most decision-relevant information is front-loaded.

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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. The description supplies the remaining decision-critical context (when to use, the scaling prerequisite) for a three-parameter tool, leaving nothing an agent needs for correct invocation.

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%, so currency, servings and the ingredients array are already fully documented in the schema. The description adds no syntax, format or default information beyond that, which is the expected baseline when the schema does the heavy lifting.

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?

Specific verb and resource: totals ingredient costs and derives cost per serving and per 10 servings. It is clearly distinguishable from siblings such as scale_recipe and merge_shopping_list, and even names the relevant sibling by name.

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

Usage Guidelines5/5

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

Explicitly states when to use it (budgeting a dish, pricing meal prep, comparing recipes on cost) and when not to (resizing), naming the alternative 'scale_recipe' plus the correct ordering: scale first, then price the scaled amounts here.

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

All RecipeScale 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.