Vegetable and fruit yield percentage, trim waste and how much produce to buy, from USDA refuse data.
Scored across 4 tools
Each tool has a clearly distinct role: lookup one yield, list yields, convert purchased weight to edible weight, or convert a recipe amount to as-purchased weight. The two calculation tools could sound similar, but their inputs and outputs are explicitly different.
All names use consistent snake_case verb_noun structure with predictable verbs: calculate_*, get_*, and list_*. The vocabulary stays within the same domain and is easy to scan.
Four tools is well-scoped for a focused vegetable-yield reference and calculation server. Each tool earns its place, with no redundant or trivial additions.
The surface covers the core lifecycle: listing yields, looking up a specific item, and converting in both directions between purchased weight and prepared edible amount. Minor gaps exist around batch/multi-item calculations and cooked rather than raw yield scenarios, but they are unlikely to block typical use.
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.
calculate_amount_to_buycalculate_edible_weightget_vegetable_yieldlist_vegetable_yieldsRaw to cooked weight of meat and poultry by cut and cooking method from USDA cooking yields.
Cups to grams for 271 ingredients with USDA and King Arthur densities, recipe scaling, oven temps.
USDA FoodData Central nutrition data: search foods, compare macros, and analyze meals.
Nutrition for more than 1,100 plant foods from 30 national tables, plus GB/EU & US claim checking
Add one secure layer between your agents and this server.
