measure-mcp

kitchen_scale_recipe

Scale a recipe from one pan or vessel to another, converting ingredients to kitchen-friendly amounts and flagging unscaled lines.

Instructions

Scale a recipe written for one pan to another vessel, with kitchen-friendly amounts.

ingredients: ONE text block, an ingredient per line (paste the list as is), or a list of strings ("2 1/4 cups flour", "3 eggs", "1/2 cup (115 g) butter, melted") or {"amount", "unit", "name"} objects. A line with no number stays unscaled and is listed in warnings. source_vessel: the pan the recipe was written for; target_vessel: the pan to use now. Each is a vessel object from kitchen_measure_vessel or kitchen_vessel_from_dimensions, or just a name ("9x13", "8 inch round", "half sheet"); vessels_resolved says which preset each name became: check it with the user. recipe_kind: batter_heavy (cakes, quick breads; fill <= 2/3), sponge (<= 1/2), bars_brownies, bread_loaf, casserole, soup_stew, sauce (these two scale by volume); words like brownies, cake, soup work. Omitted: it is inferred from the recipe text when obvious, else batter_heavy; recipe_kind.used / source / why say which. mode auto|area|volume: auto uses the AREA ratio (same batter thickness) unless the target is clearly shallower or it is a soup (then VOLUME). original_bake_minutes, original_temp_f: optional, for the bake note. fill_fraction: how full the original fills the source pan (0.05-1.0), else a typical value is assumed. rounding: kitchen (1/8 cup, 1/4 tsp steps) | exact. detail: summary (default, lean lines) | full (adds original and exact amounts per ingredient). Returns summary (quote it), scale_factor (+/-), basis and why, ingredients_scaled (original, scaled, display), fill (height, limit, ok), bake notes, recipe_kind, vessels_resolved, warnings. Eggs scale to whole, half or measured beaten egg. Fill height and bake notes are guidance, not measurements: go by doneness. Factors outside 0.5-2.0 and Bundt/angel-food/cheesecake pans carry warnings.

Input Schema

TableJSON Schema

Name	Required	Default
`mode`	No	auto
`detail`	No	summary
`rounding`	No	kitchen
`ingredients`	Yes
`recipe_kind`	No
`fill_fraction`	No
`source_vessel`	Yes
`target_vessel`	Yes
`original_temp_f`	No
`original_bake_minutes`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 16, 2026

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so well: unnumbered lines stay unscaled and surface in warnings, eggs scale to whole/half/measured, factors outside 0.5-2.0 and Bundt/angel-food/cheesecake pans trigger warnings, and fill height/bake notes are explicitly flagged as guidance rather than measurements.

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 goal is front-loaded in the first sentence and every sentence carries information, but the parameter documentation is packed into a single dense block without visual separation, which slightly hurts scannability. No filler content is present.

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?

For a 10-parameter tool with 0% schema coverage and no annotations, the description is complete: it covers inputs, defaults, inference rules, warnings, and even summarizes the return payload despite an output schema existing. An agent has everything needed to invoke it correctly.

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

Parameters5/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 define all 10 parameters, and it effectively does: input formats for ingredients, accepted vessel forms, the recipe_kind vocabulary, mode semantics, fill_fraction range (0.05-1.0), rounding steps, detail levels, and the purpose of the original bake/temp fields.

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?

The opening sentence gives a specific verb and resource: 'Scale a recipe written for one pan to another vessel, with kitchen-friendly amounts.' It is clearly distinguishable from siblings like kitchen_measure_vessel and kitchen_vessel_from_dimensions, which it explicitly identifies as sources of vessel objects rather than scaling tools.

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?

It names alternatives for obtaining vessel objects (kitchen_measure_vessel, kitchen_vessel_from_dimensions) and lays out conditions that select behavior: mode auto uses AREA unless the target is shallower or the recipe is a soup (then VOLUME), recipe_kind is inferred when omitted else defaults to batter_heavy, and vessels_resolved should be checked with the user. Guidance on when each option applies is explicit.

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