Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@raw-to-cooked-weight-mcp I weighed 150 g of cooked chicken thigh. What was the raw weight?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Raw to cooked weight for meat and poultry, for AI assistants, by cut and cooking method, from the USDA Table of Cooking Yields for Meat and Poultry.
This is a Model Context Protocol (MCP) server. It converts raw weight to cooked weight and cooked weight back to raw weight with the cooking yields USDA measured for 173 cut and method pairs of beef, pork, chicken, turkey, lamb, veal, bison and game. It needs no API key.
Tool | What it returns |
| Cooked weight of a raw cut (chicken thigh, 80/20 ground beef, pork tenderloin, bacon) in g, oz, lb and kg, the range seen across USDA samples, the weight lost and the USDA row used. |
| Raw weight behind a cooked portion, for logging food against raw nutrition labels or scaling a recipe written in cooked weight. |
| How much raw meat to buy for a number of cooked servings (default 3 oz cooked). |
| USDA cooking yield percent, sample range, moisture change and fat change for a cut and method, with close alternatives and their |
| All rows of the USDA table by category (beef, pork, poultry, chicken, turkey, lamb, veal, game, sausage) and method. |
Every result has structured JSON, a one-paragraph summary, as_of, source and more (the raw to cooked weight calculator on recipetool.net).
Related MCP server: FreshTrack MCP Server
Yields differ by cut, fat level and method. A flat "meat loses 25%" rule is wrong for most cuts. USDA measured bacon at 29 to 32% of its raw weight, 80/20 ground beef crumbles at 67%, a grilled bone-in rib eye steak at 85.7% and a boneless cured ham at 94 to 96%.
The exact USDA number, its sample count and its range. Roast chicken thigh is 69%, but USDA samples ran from 58% to 79%. The tools return both.
Ground meat lean ratios. "80/20", "93% lean" and "73/27" map to the USDA low, medium and high fat classes for beef (under 12%, 12 to 22%, over 22% fat) and pork (under 10%, 10 to 27%, over 27%).
What is not covered. Fish, seafood, rice, pasta and vegetables are not in the USDA table. The tools say so instead of guessing.
Paste this URL. No token, no sign-up.
https://raw-to-cooked-weight-mcp.lipmichal.workers.dev/mcpclaude mcp add --transport http raw-to-cooked https://raw-to-cooked-weight-mcp.lipmichal.workers.dev/mcpOr run it locally over stdio:
claude mcp add raw-to-cooked -- npx -y github:theluckystrike/raw-to-cooked-weight-mcpAdd to claude_desktop_config.json:
{
"mcpServers": {
"raw-to-cooked": { "command": "npx", "args": ["-y", "github:theluckystrike/raw-to-cooked-weight-mcp"] }
}
}Add to ~/.cursor/mcp.json:
{
"mcpServers": {
"raw-to-cooked": { "url": "https://raw-to-cooked-weight-mcp.lipmichal.workers.dev/mcp" }
}
}Add to .vscode/mcp.json:
{
"servers": {
"raw-to-cooked": { "type": "http", "url": "https://raw-to-cooked-weight-mcp.lipmichal.workers.dev/mcp" }
}
}Node 20 or newer is needed for the local stdio version.
"I weighed 150 g of cooked chicken thigh. What was the raw weight for my macro log?"
"How much does 2 lb of raw 80/20 ground beef weigh after browning?"
"How much raw brisket do I buy to serve 12 people 4 oz cooked each?"
"What percent of its weight does bacon lose in the microwave?"
"Which pork cuts keep the most weight when grilled?"
Full list with fetch dates and checksums in DATA_SOURCES.md.
USDA Agricultural Research Service, Nutrient Data Laboratory. USDA Table of Cooking Yields for Meat and Poultry, Release 2, September 2014. PDF and Excel. The Excel file is in data/ and scripts/build_data.py rebuilds the table from it.
Pound and ounce from NIST SP 811 (1 lb = 453.59237 g exactly).
USDA yield is hot cooked weight over raw weight of the same piece, cooked to USDA research protocols. Doneness, trim, bone, brines and how much of the pan juice you keep move your result. The tools return the USDA range when there is one.
Rows with a 1975 release year come from USDA Agriculture Handbook 102. They have no sample count, moisture or fat change.
A bone-in cut keeps its bone in both weights. Boneless skinless chicken breast and grilled chicken breast are not in the table; the tools return the closest row and say so.
Fish, seafood, duck, eggs, rice, pasta and vegetables are not covered.
The raw to cooked weight calculator and recipe nutrition tools are on recipetool.net.
Part of the Zovo MCP collection: https://mcp.zovo.one
npm install
npm test # builds, then runs the fixture tests
node scripts/smoke-stdio.mjs # stdio check, one real call per tool
python3 scripts/build_data.py data/USDA_CookingYields_MeatPoultry02.xlsx data/cooking-yields.json
python3 scripts/gen_ts.py data/cooking-yields.json src/data.ts
npx wrangler deploy # Cloudflare Worker, Streamable HTTP at /mcpMIT
How much raw meat or poultry to buy for a number of cooked servings, from the USDA cooking yield for that cut and method. Default cooked serving is 3 oz (85 g).
| Name | Required | Description | Default |
|---|---|---|---|
| food | No | Cut and species in plain words, for example "chicken thigh", "80/20 ground beef patty", "ribeye steak", "pork tenderloin", "bacon", "turkey breast", "bison burger". | |
| unit | No | Unit of cooked_serving_size: g, kg, oz or lb. Default oz. | |
| method | No | Cooking method: roast, grill, braise, simmer, pan_fry, pan_broil, deep_fry, microwave. Plain words work too (grilled, baked, slow cooker, sauteed, boiled). | |
| servings | Yes | Number of servings, for example 8. | |
| yield_id | No | Exact row id from find_cooking_yield or list_cooking_yields. Overrides food and method. | |
| cooked_serving_size | No | Cooked weight per serving in the chosen unit. Default 3 oz or 85 g. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile needs no restating. The description adds genuine context by disclosing the USDA cooking-yield basis and the default 3 oz (85 g) serving, but it says nothing about fallback behavior when the cut or method is unrecognized, or about what the result contains.
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?
A single well-formed sentence that front-loads the core question being answered and tucks the default serving size at the end where it belongs. Nothing is wasted, though the one sentence carries the whole definition.
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?
With six parameters, no output schema, and a nontrivial yield-lookup concept, the description is adequate but thin: it does not say whether the response includes the yield used, the cut that was matched, or a confidence/fallback indicator. Schema coverage compensates for inputs, but the return side is entirely unexplained.
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 100%, so the baseline is 3; each parameter including yield_id's 'overrides food and method' note is already documented in the schema. The description only reinforces the default serving size, adding no new meaning about how food/method and yield_id interact.
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?
The description gives a specific verb-and-resource framing: it computes how much raw meat or poultry to buy to yield a given number of cooked servings, keyed to the USDA cooking yield for the cut and method. That is concrete enough to distinguish it from a plain unit conversion, but it never names or contrasts the siblings (convert_cooked_to_raw, find_cooking_yield) that an agent will be choosing between.
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?
Usage is implied rather than stated: the wording makes clear this is the tool for 'how much do I buy' planning, but there is no explicit when-to-use, when-not-to-use, or pointer to convert_cooked_to_raw / find_cooking_yield as alternatives. An agent must infer the routing from the purpose sentence alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Raw weight that a cooked portion of meat or poultry came from, using the USDA measured cooking yield. Use it to log a cooked portion against raw nutrition data (labels and most databases list raw meat) or to scale a recipe written in cooked weight. Returns raw weight in g, oz, lb and kg, and the raw weight if the yield was at the USDA high or low end.
| Name | Required | Description | Default |
|---|---|---|---|
| food | No | Cut and species in plain words, for example "chicken thigh", "80/20 ground beef patty", "ribeye steak", "pork tenderloin", "bacon", "turkey breast", "bison burger". | |
| unit | No | Weight unit: g, kg, oz or lb. Default g. | |
| method | No | Cooking method: roast, grill, braise, simmer, pan_fry, pan_broil, deep_fry, microwave. Plain words work too (grilled, baked, slow cooker, sauteed, boiled). | |
| yield_id | No | Exact row id from find_cooking_yield or list_cooking_yields. Overrides food and method. | |
| cooked_weight | Yes | Cooked weight, for example 150. |
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 marginal bar is what behavior is added. The description contributes the data source (USDA measured cooking yield) and discloses that uncertainty is exposed via USDA high/low end values, which is genuinely useful. It does not say what happens when the food or method is unrecognized, nor which method is assumed if omitted.
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 sentences ordered purpose, then usage, then return values, all of which earn their place. The first sentence is a noun-phrase fragment rather than a verb-led statement, a minor stylistic inefficiency but not a comprehension problem.
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?
With five parameters, a single required input, and no output schema, the description correctly takes on the return-value burden by naming the four units and the high/low yield bounds. The remaining gap is failure and fallback behavior for unknown or mismatched food/method combinations, which matters for a lookup-driven conversion.
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 100% and every parameter including the yield_id override is fully documented in the schema, so the baseline of 3 applies. The description adds no parameter-level detail such as default unit handling or how food/method interact when both are supplied.
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?
The opening clause names the concrete transformation (raw weight a cooked portion came from) and the domain (meat or poultry), so the direction is unambiguous against the sibling convert_raw_to_cooked. It never names that sibling explicitly, so an agent must infer the inverse relationship from the verb alone rather than from stated contrast.
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?
Two concrete usage contexts are given: logging a cooked portion against raw nutrition data, and scaling a recipe written in cooked weight. That is real when-to-use guidance rather than implied usage. What is missing is any exclusion or pointer to alternatives, e.g. when to use convert_raw_to_cooked instead or when to bypass food/method in favor of yield_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cooked weight of raw meat or poultry using the USDA measured cooking yield for that cut and cooking method (USDA Table of Cooking Yields for Meat and Poultry). Returns the expected cooked weight in g, oz, lb and kg, the range seen across USDA samples, the weight lost, and the USDA row used. Understands ground beef lean ratios such as 80/20 or 93% lean.
| Name | Required | Description | Default |
|---|---|---|---|
| food | No | Cut and species in plain words, for example "chicken thigh", "80/20 ground beef patty", "ribeye steak", "pork tenderloin", "bacon", "turkey breast", "bison burger". | |
| unit | No | Weight unit: g, kg, oz or lb. Default g. | |
| method | No | Cooking method: roast, grill, braise, simmer, pan_fry, pan_broil, deep_fry, microwave. Plain words work too (grilled, baked, slow cooker, sauteed, boiled). | |
| yield_id | No | Exact row id from find_cooking_yield or list_cooking_yields. Overrides food and method. | |
| raw_weight | Yes | Raw weight, for example 1.5 or 500. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds real context beyond that: it discloses the returned payload (g, oz, lb, kg, USDA sample range, weight lost, and the USDA row used), which is valuable given there is no output schema. It does not cover failure behavior for unmatched cuts or the precision/rounding of results.
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 sentences, front-loaded with the core transformation and data source, followed by a return-value sentence that earns its place because no output schema exists. Dense but not padded; the lean-ratio note is the only slightly tacked-on clause.
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?
For a 5-parameter, read-only, no-output-schema tool, the description covers the transformation, source data, discretization of food/method, and the full return shape. The remaining gap is edge-case behavior (unknown cut or method, out-of-range handling) and how to chain to find_cooking_yield when yields are missing.
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 100%, including examples for food and method, so the baseline is 3. The description adds the notable semantic that food accepts ground-beef lean ratios like 80/20 or 93% lean, but otherwise restates what the schema already documents (yield_id overriding food and method is already in the schema).
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?
The description names a specific transformation (raw weight -> cooked weight) with a concrete data source (USDA Table of Cooking Yields) and domain scope (meat and poultry, including ground-beef lean ratios). It is clearly distinguishable from find_cooking_yield/list_cooking_yields because it is the conversion step, but it never names the reverse sibling convert_cooked_to_raw, so an agent must infer the direction split from the name 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?
Usage is implied rather than stated: an agent can infer 'call this when you have a raw weight and want cooked weight', and the yield_id note points at find_cooking_yield/list_cooking_yields as upstream sources. There is no explicit when-not guidance (e.g. use convert_cooked_to_raw for the inverse) and no statement of what happens for an unrecognized food or method.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up the USDA cooking yield percent for a cut of meat or poultry and a cooking method, with the yield range, sample count, moisture change and fat change measured by USDA, plus up to 4 close alternative rows with their yield_id.
| Name | Required | Description | Default |
|---|---|---|---|
| food | Yes | Cut and species in plain words, for example "chicken thigh", "80/20 ground beef patty", "ribeye steak", "pork tenderloin", "bacon", "turkey breast", "bison burger". | |
| limit | No | Rows to return, default 5. | |
| method | No | Cooking method: roast, grill, braise, simmer, pan_fry, pan_broil, deep_fry, microwave. Plain words work too (grilled, baked, slow cooker, sauteed, boiled). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, and the description still adds real substance: the response payload contents (yield range, sample count, moisture and fat change) and the presence of alternative rows carrying yield_id. What it omits is matching behavior — whether the food/method lookup is fuzzy, and what happens on zero matches.
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?
A single dense sentence, front-loaded on the primary lookup and then the returned fields, with no filler clauses. It is packed rather than padded, though splitting the return-content portion into its own sentence would improve scanability.
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?
With no output schema, the description carries the burden of describing results and does so adequately by listing every returned field and the alternative rows. The remaining gap is the resolution story — how closely the supplied food/method must match and what a miss looks like.
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 100%, so the schema already documents food, method (with example values) and limit; the description adds nothing about syntax or accepted forms. The only extra signal is the reference to alternative rows and yield_id, which weakly justifies the limit parameter but doesn't explain its trade-offs.
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?
The description gives a specific verb ('look up') and resource ('USDA cooking yield percent') scoped to a cut plus a cooking method, and enumerates what comes back (range, sample count, moisture/fat change, alternatives). It is clearly a targeted lookup rather than the bulk enumeration implied by list_cooking_yields, though it never names the siblings to sharpen that boundary.
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?
Usage is only implied: an agent can infer this is the tool to use when it has a specific food + method and wants the USDA yield figure, and the mention of 'up to 4 close alternative rows' hints at disambiguation. There is no explicit when-to-use statement, no exclusion of the conversion/calculation siblings, and no guidance on what to do when the food or method doesn't match.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List rows of the USDA Table of Cooking Yields for Meat and Poultry, filtered by category (beef, pork, poultry, chicken, turkey, lamb, veal, game, sausage) and cooking method.
| Name | Required | Description | Default |
|---|---|---|---|
| method | No | Cooking method: roast, grill, braise, simmer, pan_fry, pan_broil, deep_fry, microwave. Plain words work too (grilled, baked, slow cooker, sauteed, boiled). | |
| category | No | beef, pork, poultry, chicken, turkey, lamb, veal, game or sausage. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior, so the description does not need to restate safety. It adds useful source context (USDA table) and filtering scope but does not describe return row structure, pagination, or how missing filters behave.
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?
A single, well-structured sentence that front-loads the action and resource. Every clause contributes to identifying the filtered USDA cooking-yield table.
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?
For a simple two-optional-parameter reference-listing tool with rich annotations, the description gives enough context to understand what is being listed and how it can be filtered. It could be slightly more complete by noting that both filters are optional and that rows contain yield values, but no output schema exists and no critical usage detail is missing.
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 100%, and both parameters are fully documented in the schema, including accepted cooking-method terms and category values. The description restates the filter categories and method but adds no syntax or matching semantics beyond the schema.
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?
The description uses a specific verb (List) and resource (rows of the USDA Table of Cooking Yields) and names the filtering dimensions. It distinguishes itself from sibling calculation/conversion tools by framing this as a table-listing operation, though it does not explicitly mention alternatives like find_cooking_yield.
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?
Usage is implied: browse or list cooking-yield rows filtered by category and cooking method. However, there is no explicit guidance on when to use this versus find_cooking_yield or the conversion/calculation siblings.
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.
v1.0.0calculate_raw_weight_to_buyconvert_cooked_to_rawconvert_raw_to_cookedfind_cooking_yieldlist_cooking_yieldsScored across 5 tools
The direction-based converters (raw→cooked vs cooked→raw) are clearly distinguished by name and description, and find vs list have distinct intents (single precise lookup with yield_id alternatives vs filtered browsing). The only mild overlap is between calculate_raw_weight_to_buy and convert_cooked_to_raw, since both produce a raw weight for cooked amounts, but the servings-scaling framing mostly separates them.
All names are snake_case, verb-first, and descriptive (convert_*, calculate_*, find_*, list_*). The pattern is predictable, though the two converts embed a directional argument (raw_to_cooked) rather than a pure verb_noun object, which is a minor deviation.
Five tools is well-scoped for a focused weight-conversion domain, with no filler. Each tool covers a distinct step: two directions of conversion, a batch/purchase calculator, a precise yield lookup, and a browse/list operation.
Coverage of the core lifecycle (raw→cooked, cooked→raw, servings→purchase amount, yield lookup and browsing) is solid and closes most workflows. Minor gaps remain: no inverse of calculate_raw_weight_to_buy (cooked weight → number of servings) and no way to scale nutrition per portion, but agents can work around these with the existing converters.
Recipe search, ingredient matching, nutrition filters and a private cookbook for any AI agent.
Everyday calculators and converters for AI assistants: units, dates, percentages, text, JSON.
Cups to grams for 271 ingredients with USDA and King Arthur densities, recipe scaling, oven temps.
Vegetable and fruit yield percentage, trim waste and how much produce to buy, from USDA refuse data.
