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., "@Vegetable Yield Percentage MCP how much broccoli do I buy to get 500 g of florets?"
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.
Vegetable and fruit yield percentage for AI assistants: how much of what you buy is edible after peeling, coring and trimming, and how much to buy for a recipe, from USDA refuse data.
This is a Model Context Protocol (MCP) server. It covers 305 raw vegetables and fruits from the USDA National Nutrient Database for Standard Reference (SR28), each with its USDA refuse percent, what the refuse is, and USDA household weights such as 1 medium onion or 1 cup chopped. It needs no API key.
Tool | What it returns |
| Edible yield percent, refuse percent and what the refuse is (skin, seeds, core, crown), USDA household weights, and the edible and as-bought weight of one whole item. |
| Edible weight and trim waste from a purchased weight, for example 5 lb of pineapple. |
| How much to buy for a recipe amount given in g, kg, oz, lb or a USDA measure such as "cup chopped", "medium" or "clove", as purchased weight and whole-item count. |
| All 305 items by name, lowest yield or highest yield, filtered to fruit or vegetable. |
Every result has structured JSON, a one-paragraph summary, as_of, source and more (the vegetable yield percentage calculator on ingredientcalculator.com).
Related MCP server: FreshTrack MCP Server
The USDA trim loss for each item, and what it is. Corn on the cob is 36% edible (35% husk, silk and trimmings, 29% cob). Pineapple is 51% (8% core, 16% crown, 26% parings). Cauliflower is 39%, leeks 44%, asparagus 53%, bananas 64%, onions 90%, cucumbers 97%.
USDA household weights for the edible part. A medium onion (2-1/2 inch) is 110 g and a cup of chopped onion is 160 g, so 2 cups chopped needs about 3 medium onions and 356 g as bought.
The difference between as purchased and edible portion. Recipe costing, food cost and portion planning need both. The tools return both, plus the waste.
Paste this URL. No token, no sign-up.
https://vegetable-yield-percentage-mcp.lipmichal.workers.dev/mcpclaude mcp add --transport http vegetable-yield https://vegetable-yield-percentage-mcp.lipmichal.workers.dev/mcpOr run it locally over stdio:
claude mcp add vegetable-yield -- npx -y github:theluckystrike/vegetable-yield-percentage-mcpAdd to claude_desktop_config.json:
{
"mcpServers": {
"vegetable-yield": { "command": "npx", "args": ["-y", "github:theluckystrike/vegetable-yield-percentage-mcp"] }
}
}Add to ~/.cursor/mcp.json:
{
"mcpServers": {
"vegetable-yield": { "url": "https://vegetable-yield-percentage-mcp.lipmichal.workers.dev/mcp" }
}
}Add to .vscode/mcp.json:
{
"servers": {
"vegetable-yield": { "type": "http", "url": "https://vegetable-yield-percentage-mcp.lipmichal.workers.dev/mcp" }
}
}Node 20 or newer is needed for the local stdio version.
"What is the yield percentage of a pineapple?"
"I bought 3 lb of butternut squash. How much will I have after peeling and seeding?"
"A recipe needs 2 cups of chopped onion. How many onions do I buy?"
"How much broccoli do I buy to serve 500 g of florets?"
"Which fruits waste the most weight when you prep them?"
Full list with fetch dates and checksums in DATA_SOURCES.md.
USDA Agricultural Research Service, Nutrient Data Laboratory. National Nutrient Database for Standard Reference, Release 28 (September 2015), ASCII files: refuse percent and refuse description from FOOD_DES.txt, household weights from WEIGHT.txt. scripts/build_data.py rebuilds data/produce-yields.json from them.
Definitions from the SR28 documentation: refuse is a percent of the item as purchased, and household weights are for the edible part without refuse.
Pound and ounce from NIST SP 811 (1 lb = 453.59237 g exactly).
USDA refuse is an average for typical produce and trimming. Size, ripeness, variety and how hard you trim move your result.
Only raw items with a USDA refuse value are covered: 191 vegetables and 114 fruits. Herbs listed under spices (parsley, basil), nuts and coconut are not included.
Some items have no USDA whole-item weight (butternut squash, asparagus); the tools then answer by weight and cups only.
SR28 (2015) is the final Standard Reference release, so values for newer varieties are not included.
The vegetable yield percentage calculator, cups to grams and recipe scaling tools are on ingredientcalculator.com.
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 <dir with FOOD_DES.txt and WEIGHT.txt> data/produce-yields.json
python3 scripts/gen_ts.py data/produce-yields.json src/data.ts
npx wrangler deploy # Cloudflare Worker, Streamable HTTP at /mcpMIT
How much of a raw vegetable or fruit to buy for a recipe amount. Give the prepared amount in g, kg, oz or lb, or as a USDA household measure such as "cup chopped", "cup sliced", "medium" or "clove". Returns the edible weight needed, the as-purchased weight to buy at the USDA edible yield, and the number of whole items (for example medium onions) to buy.
| Name | Required | Description | Default |
|---|---|---|---|
| food | Yes | Raw vegetable or fruit in plain words, for example "onion", "red bell pepper", "pineapple", "butternut squash", "broccoli", "avocado". | |
| amount | Yes | Prepared amount, for example 3 (cups) or 500 (grams). | |
| measure | No | g, kg, oz, lb, or a household measure such as "cup chopped", "cup sliced", "tbsp", "medium", "large", "clove". Default g. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (read-only, idempotent, closed-world), and the description goes beyond them by disclosing the three return values: edible weight, as-purchased weight at the USDA edible yield, and whole-item count. That assumption about USDA edible yield is meaningful behavioral context since there is no output schema. Minor gap: it does not say what happens if the food name is not recognized.
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, front-loaded with the core purpose, then input format, then outputs. No filler. The example measures are somewhat repetitive of the schema but serve as quick orientation, so the cost is low.
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?
Because there is no output schema, the description must explain results, and it does so explicitly, which is the main completeness requirement here. For a three-parameter read-only lookup with full schema coverage, the only remaining gap is error/unknown-food behavior and boundary guidance against the weight-only siblings.
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%, so the schema already documents all three parameters. The description reinforces the measure formats and the distinction between 'prepared amount' and as-purchased weight, which is a useful semantic contrast, but it adds no grammar or validity detail beyond the schema's own examples and default of g.
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 states a specific verb and resource: computing how much raw produce to buy for a given prepared recipe amount. It is unambiguous about the input (prepared amount) and output (purchase quantity), but it never names the siblings calculate_edible_weight, get_vegetable_yield or list_vegetable_yields, so the agent must infer the boundary from the title and schema.
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 by the phrase 'for a recipe amount' and the enumeration of acceptable measures, which tells the agent this is the tool for converting a prepared quantity into a shopping quantity. However, there is no explicit when-to-use versus calculate_edible_weight, no statement of prerequisites (e.g. food must be a known USDA item), and no exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edible weight and trim waste from a purchased (as purchased, untrimmed) weight of a raw vegetable or fruit, using the USDA edible yield percent.
| Name | Required | Description | Default |
|---|---|---|---|
| food | Yes | Raw vegetable or fruit in plain words, for example "onion", "red bell pepper", "pineapple", "butternut squash", "broccoli", "avocado". | |
| unit | No | g, kg, oz or lb. Default g. | |
| purchased_weight | Yes | Weight as bought, for example 5. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the description's main contribution is disclosing the data source (USDA edible yield percent) and the as-purchased starting point. It stays silent on failure behavior for unrecognized foods and on precision/rounding of the returned weights.
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?
It is one compact sentence with the key qualifier ('as purchased, untrimmed') front-loaded and no filler. The sentence is a fragment without an explicit verb, which is a minor readability flaw, but nothing is wasted.
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 three-parameter, read-only calculation, the description covers inputs and the two outputs adequately, and there is no output schema to defer to. It is still missing edge-case behavior (unknown food, mismatched unit assumptions) that an agent would want before calling.
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 covers all three parameters, including unit defaults and examples. The description adds only a modest gloss: that purchased_weight means untrimmed as-bought weight and that food maps to a USDA yield value. That is the baseline for a fully documented 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 the two outputs (edible weight and trim waste) and the required input (as-purchased untrimmed weight) plus the method (USDA edible yield percent), so the operation is unmistakable. It does not, however, distinguish itself from the siblings calculate_amount_to_buy, get_vegetable_yield, or list_vegetable_yields, which is the difference between a 4 and a 5.
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: the phrase 'from a purchased (as purchased, untrimmed) weight' signals that this is the forward direction, as opposed to calculate_amount_to_buy. There is no explicit statement of when to choose this tool over its siblings, and no note about what it does when the food name is unknown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
USDA edible yield percent for a raw vegetable or fruit (the share left after removing peel, seeds, core, stems and trimmings), the refuse percent and what the refuse is, plus USDA household weights (1 medium, 1 cup chopped, 1 clove) and the as-purchased weight of one whole item. From USDA SR28 refuse data.
| Name | Required | Description | Default |
|---|---|---|---|
| food | Yes | Raw vegetable or fruit in plain words, for example "onion", "red bell pepper", "pineapple", "butternut squash", "broccoli", "avocado". |
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 description's job is to add data context — and it does: it discloses the data source and vintage (USDA SR28 refuse data) and precisely what the returned figures represent, including the definition of edible yield. It omits behavior for an unmatched or ambiguous food name, which is the main residual gap.
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?
One dense sentence that front-loads the primary value (edible yield percent) and then adds secondary outputs in descending importance. Every clause carries distinct information — parenthetical definitions, refuse details, household weights, source — with no repetition of the title or annotations.
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 must carry the return-value burden, and it does so thoroughly by naming each returned figure. For a one-parameter read-only lookup this is nearly complete; only the failure mode for unrecognized foods is unaddressed.
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 the schema itself supplies format guidance and five example values, so the schema does the heavy lifting. The description reinforces the 'raw' constraint on the input, but adds no matching or normalization rules beyond what the schema already says. Baseline 3 is appropriate for a single fully documented parameter.
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 states a specific resource (USDA edible yield percent for a raw vegetable/fruit) and enumerates the exact outputs: refuse percent, refuse description, household weights, and as-purchased weight. It is far more specific than the title alone. It does not, however, distinguish itself from siblings such as calculate_edible_weight or list_vegetable_yields, leaving an agent to infer which of the three yield-related tools to call.
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?
There is no explicit when-to-use or when-not-to-use guidance, and no sibling is named. The closest thing to guidance is the implicit framing that this is a per-food reference lookup rather than a calculation, but that distinction from calculate_edible_weight is never stated. An agent must guess between four closely related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List raw vegetables and fruits with their USDA edible yield percent, filtered to fruit or vegetable and sorted by name, lowest yield or highest yield.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | name (default), yield_low or yield_high. | |
| limit | No | Rows to return, default 50. | |
| category | No | fruit or vegetable. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so safety is fully covered structurally. The description adds domain context ("raw", "USDA edible yield percent"), but it does not mention that results are capped at 400 rows or describe the ordering behavior when ties occur. Given annotation coverage, a 3 is appropriate.
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 front-loaded sentence covering resource, data, filter, and sort dimensions, with no filler. It is dense but readable; splitting the sort options into a short second clause would have improved scanability slightly.
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?
This is a simple read-only listing tool with three optional, fully documented parameters and complete annotations, so not much is required. The only real gap is the absence of any pointer to the single-item sibling for looking up one vegetable, which an agent would need to choose correctly.
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%, with both enums documented inline, including the default "name" and default limit of 50. The description's mention of filtering and sorting mirrors the schema rather than extending it, so the baseline of 3 applies.
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 states a specific verb and resource ("List raw vegetables and fruits") and identifies the payload (USDA edible yield percent), which is exactly what a listing tool should do. It never names the sibling get_vegetable_yield or explains that this is the plural counterpart, so the differentiation is inferable from "List" versus the siblings' "calculate" verbs rather than stated.
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 by the filtering and sorting language: pick a category and a sort order to browse the dataset. There is no explicit when-to-use-this-versus-get_vegetable_yield or calculate_edible_weight guidance, and no note that omitting all parameters returns the default top 50 by name.
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_amount_to_buycalculate_edible_weightget_vegetable_yieldlist_vegetable_yieldsScored across 4 tools
Each tool has a distinct role: one lookup of yield data, one list/search, and two calculations in opposite directions (trimming a purchased weight vs. scaling up from a recipe amount). The two calculate_ tools do touch the same edible-yield concept, which could cause occasional misselection, but the descriptions make the direction of each clear.
All four tools use a consistent snake_case verb_noun pattern (get_, calculate_, calculate_, list_) with clear object naming. No mixing of conventions or casing styles.
Four tools is well-scoped for a narrow, focused domain (USDA vegetable yield lookup and yield-based calculations). Each tool earns its place with no obvious redundancy.
The surface covers per-item lookup, enumeration/filtering, trim calculation, and purchase-amount calculation, covering the core workflow end to end. Minor gaps exist (e.g. no bulk/multi-item calculations or cooked-yield handling), but agents can work around these with repeated calls.
Natural-language calorie lookup. Send '2 large eggs', get USDA-sourced nutrition data.
Raw to cooked weight of meat and poultry by cut and cooking method from USDA cooking yields.
Search structured recipes, scale servings, match pantry ingredients, and build shopping lists.
Cups to grams for 271 ingredients with USDA and King Arthur densities, recipe scaling, oven temps.