mcp-bbc-goodfood

Search recipes

search_recipes

Read-onlyIdempotent

Search BBC Good Food recipes by dish, ingredient, or technique. Filter by diet, cuisine, meal type, difficulty, time, rating, calories, servings to find matching recipe pages.

Instructions

Search recipes on BBC Good Food and return a listing. Narrow it with 'diet', 'cuisine', 'meal_type', 'difficulty' or a bound such as 'max_total_minutes'; call list_filters first for the values each one takes, since the site answers a value it does not know with a count of zero. The site ranks rather than filters: it answers a term it holds nothing for with rows all the same, so read the titles rather than trusting the count. Each row carries the page to read the recipe on.

Input Schema

TableJSON Schema

Name	Required	Description
`diet`	No	A value list_filters publishes.
`page`	No	Which page of rows. Default 1.
`sort`	No	How the site orders the rows. Default 'relevant'.
`limit`	No	Rows to return. Default 30.
`query`	Yes	A dish, an ingredient, a technique.
`cuisine`	No	A value list_filters publishes.
`meal_type`	No	A value list_filters publishes.
`difficulty`	No	A value list_filters publishes.
`min_rating`	No	At least this many stars, 1 to 5.
`max_calories`	No	Per serving.
`min_servings`	No	At least this many servings.
`exclude_premium`	No	Drop the rows that sit behind the site's subscription. The site offers no such restriction, so the rows are removed from the page after it arrives: a page comes back shorter than the limit asked for, and a short page is not the end of the results.
`max_total_minutes`	No	Whole recipe, minutes.

Output Schema

TableJSON Schema

Name	Required	Description
`notes`	Yes
`query`	Yes
`source`	Yes
`results`	Yes
`rows_seen`	Yes	Rows the site served, before anything was set aside.
`result_count`	Yes	Rows rendered, after anything unreadable was set aside.
`premium_dropped`	Yes	Rows removed from this page for sitting behind the site's subscription.
`total_available`	Yes	Recipes the site says the search holds.
`total_is_ceiling`	Yes	True when the total sits on the most rows one search will serve, so it states a floor.
`restrictions_lifted`	Yes	Restrictions let go of so the search could run again after the restricted one returned nothing.

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedv1.1.0Sep 10, 2026
- removedOutput schema / properties / results / items / properties / author / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / results / items / properties / author / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / results / items / properties / difficulty / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / results / items / properties / difficulty / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / results / items / properties / image_url / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / results / items / properties / image_url / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / results / items / properties / rating / anyOf
```
Removed value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / results / items / properties / rating / type
```
Added value: +[
+  "number",
+  "null"
+]
```

Changed4 schema fields changedAug 29, 2026

removedOutput schema / properties / restrictions_dropped

Removed value: -{
-  "description": "Restrictions the site could not answer, dropped so the search could run.",
-  "items": {
-    "type": "string"
-  },
-  "type": "array"
-}

addedOutput schema / properties / restrictions_lifted

Added value: +{
+  "description": "Restrictions let go of so the search could run again after the restricted one returned nothing.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

changedOutput schema / properties / results / items / properties / id / description

Previous value: -"Opaque to a caller. The site's own identifier for the recipe."New value: +"The page's own path. Pass it to get_recipe to read the recipe."

changedOutput schema / required

Previous value: -[
-  "query",
-  "results",
-  "result_count",
-  "total_available",
-  "total_is_ceiling",
-  "rows_seen",
-  "restrictions_dropped",
-  "premium_dropped",
-  "source",
-  "notes"
-]New value: +[
+  "query",
+  "results",
+  "result_count",
+  "total_available",
+  "total_is_ceiling",
+  "rows_seen",
+  "restrictions_lifted",
+  "premium_dropped",
+  "source",
+  "notes"
+]

First observedv0.1.0Aug 27, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, it discloses that the site ranks rather than filters, that unknown terms produce identical rows rather than reliable counts, and that each row carries the page to read the recipe on. These are non-obvious behaviors an agent needs to interpret results correctly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but every sentence contributes: scope, filtering guidance, result-interpretation warning, and page-link follow-up. It is front-loaded with the core purpose and wastes no words.

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?

With an output schema present and annotations covering read-only, idempotent, and non-destructive behavior, the description covers the remaining operational caveats: filter-value lookup, ranking semantics, and the meaning of rows. Nothing needed to call the tool correctly is missing.

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

Parameters3/5

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. The description adds little parameter-level meaning beyond pointing to list_filters for filter values and highlighting max_total_minutes as a bound, both of which the schema already covers.

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 description opens with a specific verb and resource: 'Search recipes on BBC Good Food and return a listing.' It distinguishes itself from list_filters by explicitly instructing to call list_filters first, and from get_recipe by framing the output as a listing whose rows carry the page for reading the recipe.

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?

It gives explicit usage guidance: call list_filters first for filter values and warns that unknown values return zero counts. It does not explicitly name get_recipe as the alternative for reading a single recipe, though the closing sentence implies that follow-up.

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

Deploy Server