ask.recipes

Get a recipe in full

get_recipe

Read-onlyIdempotent

Get one recipe in full: ingredients, step-by-step instructions, times, yield, nutrition, rating (source ratings and ask.recipes stars averaged, with the user's own as my_rating) and its source link. For when the user picks a recipe from a search or asks how to make it. Pass servings to scale the ingredient quantities, e.g. for meal prep or a crowd; nutrition_for says whether the nutrition numbers are per serving or for the whole yield. Amounts come back in the units saved on the profile: metric turns cups and ounces into grams and millilitres (dry goods by weight, liquids by volume, spoons stay spoons) and oven temperatures and pan sizes in the steps into Celsius and centimetres; us does the reverse; units in the result says which applied, empty means as the source wrote it. Pass units to override for one call.

Input Schema

Name	Required	Description
`id`	Yes	recipe id from a previous search
`units`	No	metric or us; converts the ingredient amounts and the temperatures and pan sizes in the steps; defaults to the units saved on the profile, leave empty unless the user asks for the other system this once
`servings`	No	scale ingredient quantities to this many servings; when the recipe's yield does not state servings the recipe comes back unscaled with scale_note saying so, nutrition stays per serving

Output Schema

Name	Required	Description	Default
`id`	Yes
`name`	Yes
`diets`	No
`fat_g`	No
`units`	No
`yield`	No
`rating`	No
`carbs_g`	No
`fiber_g`	No
`sugar_g`	No
`calories`	No
`saved_in`	No
`servings`	No
`image_url`	No
`my_rating`	No
`nutrition`	No
`protein_g`	No
`scale_note`	No
`source_url`	Yes
`attribution`	Yes
`description`	No
`ingredients`	Yes
`scale_class`	No
`source_site`	Yes
`cook_minutes`	No
`instructions`	Yes
`main_protein`	No
`prep_minutes`	No
`rating_count`	Yes
`nutrition_for`	No
`total_minutes`	No
`askrecipes_ratings`	No
`scaled_from_servings`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 5, 2026

addedOutput schema / properties / saved_in

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": [
+    "null",
+    "array"
+  ]
+}

Changed2 schema fields changedOct 30, 2026

addedInput schema / properties / units

Added value: +{
+  "description": "metric or us; converts the ingredient amounts and the temperatures and pan sizes in the steps; defaults to the units saved on the profile, leave empty unless the user asks for the other system this once",
+  "type": "string"
+}

addedOutput schema / properties / units
```
Added value: +{
+  "type": "string"
+}
```

Changed2 schema fields changedOct 29, 2026

addedOutput schema / properties / askrecipes_ratings
```
Added value: +{
+  "type": "integer"
+}
```

addedOutput schema / properties / my_rating

Added value: +{
+  "properties": {
+    "note": {
+      "type": "string"
+    },
+    "stars": {
+      "type": "integer"
+    }
+  },
+  "required": [
+    "stars"
+  ],
+  "type": [
+    "null",
+    "object"
+  ]
+}

Changed1 schema field changedOct 25, 2026
- addedOutput schema / properties / main_protein
```
Added value: +{
+  "type": "string"
+}
```

Changed2 schema fields changedOct 25, 2026

changedInput schema / properties / servings / description

Previous value: -"scale ingredient quantities to this many servings; only works when the recipe's yield states servings, nutrition stays per serving"New value: +"scale ingredient quantities to this many servings; when the recipe's yield does not state servings the recipe comes back unscaled with scale_note saying so, nutrition stays per serving"

addedOutput schema / properties / scale_note
```
Added value: +{
+  "type": "string"
+}
```

Changed1 schema field changedOct 25, 2026
- removedOutput schema / additionalProperties
```
Removed value: -false
```
Changed1 schema field changedOct 24, 2026
- addedOutput schema / properties / scale_class
```
Added value: +{
+  "type": "string"
+}
```

Changed2 schema fields changedOct 19, 2026

addedOutput schema / properties / diets

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": [
+    "null",
+    "array"
+  ]
+}

addedOutput schema / properties / image_url
```
Added value: +{
+  "type": "string"
+}
```

Changed4 schema fields changedOct 18, 2026

addedInput schema / properties / servings

Added value: +{
+  "description": "scale ingredient quantities to this many servings; only works when the recipe's yield states servings, nutrition stays per serving",
+  "type": "integer"
+}

addedOutput schema / properties / nutrition_for
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / scaled_from_servings

Added value: +{
+  "type": [
+    "null",
+    "integer"
+  ]
+}

addedOutput schema / properties / servings

Added value: +{
+  "type": [
+    "null",
+    "integer"
+  ]
+}

First observedOct 15, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial behavior beyond them: how ratings are composed (source ratings averaged with ask.recipes stars, user's own surfaced as my_rating), that nutrition_for indicates per-serving vs whole-yield, and that scaling is skipped with a scale_note when yield doesn't state servings. The units paragraph discloses conversion rules (dry goods by weight, liquids by volume, spoons unchanged, oven temps and pan sizes converted) and that an empty units field in the result means source-as-written.

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?

Purpose and use case are front-loaded, then scaling, then units — a logical order. The units block is long and packs output semantics (what 'units in the result' means) into a parameter discussion, and it partly restates the schema's units description, costing it a point on tightness.

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-value documentation is not required, yet the description still flags the non-obvious fields (nutrition_for, my_rating, scale_note, units). For a three-parameter read tool with edge cases around scaling and unit conversion, nothing an agent needs to call it correctly is missing.

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

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description genuinely adds meaning: it explains the intent of servings (meal prep, a crowd), the concrete metric/us conversion effects, and the fallback behavior (scale_note, nutrition stays per serving). The units explanation overlaps the schema's own units description, so the marginal gain is real but partly duplicated.

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?

States a specific verb and resource ('Get one recipe in full') and immediately enumerates the payload: ingredients, instructions, times, yield, nutrition, rating, source link. An agent can distinguish this from search_recipes or list_saved without opening the schema, since this is the single-item full-fetch.

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

Usage Guidelines4/5

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

Gives a clear trigger condition: 'when the user picks a recipe from a search or asks how to make it,' and the id parameter is described as coming from a previous search, which implies the prerequisite lookup flow. It does not explicitly name the sibling to use instead when the user has not yet picked a recipe (search_recipes/list_saved), so it stops short of full when-not guidance.

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

All ask.recipes tools Inspect

Try in Browser

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.