mcp-bbc-goodfood
mcp-bbc-goodfood
一个在 BBC Good Food 上读取食谱的 MCP 服务器。 只读,无需 API 密钥,无需账户。
为什么存在
BBC Good Food 接受搜索筛选器上的任何值,并对它不认识的值以总数零作答。请求 glutenfree 而不是 gluten-free,网站会说没有匹配项,其确信程度与它说 48 个食谱匹配正确拼写时相同。猜测拼写的模型会得到一个自信的缺失,而不是一个拒绝。
这个服务器发布词汇表,以便问题可以被正确地提出。
Related MCP server: mcp-cookbook
工具
list_filters
列出食谱搜索可以沿其收窄的轴,以及每个轴所取的值和携带这些值的食谱数量。
参数 | 类型 | 含义 |
| 字符串,可选 | 在此搜索内测量计数。省略它以获取网站的完整列表。 |
网站对搜索返回的行进行筛选器计数,因此两者回答不同的问题。在 chicken 内,diet 报告 gluten-free 48。在整个列表中,它报告 gluten-free 2810。两者互不可比,答案会说明它测量的是哪个范围。
{
"query": "chicken",
"filters": [
{
"name": "diet",
"label": "Diets",
"options": [{ "value": "gluten-free", "label": "Gluten-free", "count": 48 }],
"option_count": 10
}
],
"filter_count": 9,
"total_available": 363,
"total_is_ceiling": false,
"rows_seen": 30,
"matched_rows": 30,
"source": "BBC Good Food",
"notes": ["…"]
}答案拒绝夸大什么
发布的值是一个候选清单。 网站显示一个轴上的十个最频繁值,并接受它从未列出的其他值:cuisine=mexican 将搜索收窄到 306 个食谱,却没有出现在十个之中。答案说该列表是一个摘录,而不是称其为接受值的集合,因为这样称呼的服务器会拒绝有效的值。
总数可能是一个下限。 网站一次搜索最多提供 10 000 行,然后就此打住。恰好落在这个数字上的总数是被截断的,因此它陈述的是一个下限而不是计数,total_is_ceiling 说明了这一点。
网站未发布任何内容的计数是 null,绝不是 0。 在从零开始的尺度上,两者将无法区分。
网站对没有内容的词条用完全相同的行来回答。 搜索 foobar 返回七个食谱——其中包括一个大黄汽水和一块烙饼条——按片段匹配,没有任何标记表明答案是未命中。因此每个答案都报告 rows_seen 和 matched_rows:网站提供了多少行,以及其中有多少行带有搜索词。当第二个为零而第一个不为零时,注释说明该计数描述的是网站提供的内容,而不是匹配的内容。
两个计数而不是一个裁决。合法的搜索可能不出现在任何标题中,读者看到 30 中的 2 比一个替他们判断的标记判断得更好。
安装
npx mcp-bbc-goodfoodClaude Code
claude mcp add bbc-goodfood -- npx -y mcp-bbc-goodfood任何 MCP 客户端
{
"mcpServers": {
"bbc-goodfood": {
"command": "npx",
"args": ["-y", "mcp-bbc-goodfood"]
}
}
}容器
docker build -t mcp-bbc-goodfood .
docker run -i --rm mcp-bbc-goodfood容器需要能够访问 www.bbcgoodfood.com,仅此而已。它不需要任何凭据,因为没有任何凭据可取。
设置
每个设置都是一个环境变量,并且都不是必需的。超出范围的值会被拒绝,并在 stderr 上输出一行,默认值保持不变:无法生效的设置会说明这一点,而不是被静默地限制。
变量 | 默认值 | 范围 |
| — | 您自己的标识符。此项目的标识符会保持附加,以便网站可以联系到人。 |
| 1500 | 1000 到 60000 |
| 20000 | 1000 到 120000 |
| 3 | 0 到 8 |
| 900000 | 0 到 86400000,0 关闭存储 |
| 200 | 1 到 5000 |
|
|
|
节奏下限不能从外部降低。该网站可免费阅读,且未发布爬取延迟,这是要小心的理由,而不是可以加快速度的许可。
作为库
读取层单独发布,带有其节奏、存储和错误词汇表,不附加任何协议:
import { GoodFoodClient } from "mcp-bbc-goodfood/client";错误
六个代码,仅此而已。调用者根据打开消息的代码进行分支。
代码 | 含义 |
| 该地址下网站没有任何内容 |
| 参数无法产生请求 |
| 网站要求此客户端放慢速度。它没有说明是否有任何内容匹配 |
| 答案以该服务器无法读取的形式到达 |
| 请求无法完成 |
| 在截止时间内没有答案到达 |
署名
食谱、标题和计数属于 BBC Good Food。每个答案都带有来源,向读者展示的列表应注明网站并链接到页面。
贡献
参见 CONTRIBUTING.md。测试优先,覆盖率下限为 100%,所有内容遵循的规则是服务器绝不说数据未携带的任何内容。
根据 MIT 许可。
mcp-bbc-goodfood (français)
Un serveur MCP qui lit les recettes de BBC Good Food. En lecture seule, sans clé d'API et sans compte.
Pourquoi il existe
BBC Good Food accepte n'importe quelle valeur sur une facette de recherche, et
répond à une valeur qu'il ne connaît pas par un total de zéro. Demandez
glutenfree au lieu de gluten-free et le site répond que rien ne correspond,
avec l'assurance qu'il met à dire que 48 recettes correspondent à la bonne
orthographe. Un modèle qui devine une orthographe reçoit une absence confiante
plutôt qu'un refus.
Ce serveur publie le vocabulaire, pour que la question soit posable.
L'outil
list_filters
Liste les axes le long desquels une recherche de recettes peut être restreinte, avec les valeurs que chacun prend et le nombre de recettes qui les portent.
Argument | Type | Sens |
| chaîne, optionnel | Mesure les comptes à l'intérieur de cette recherche. Sans lui, ils portent sur le listing entier du site. |
Le site compte ses facettes sur les lignes qu'une recherche rend, donc les deux
répondent à des questions différentes. Dans chicken, diet annonce
gluten-free 48. Sur le listing entier, il annonce gluten-free 2810. Aucun des
deux n'est comparable à l'autre, et la réponse dit quelle portée elle a mesurée.
Ce que les réponses refusent d'affirmer
Les valeurs publiées sont un extrait. Le site montre les dix valeurs les plus
fréquentes d'un axe et en accepte d'autres qu'il ne liste jamais :
cuisine=mexican restreint une recherche à 306 recettes sans figurer parmi les
dix. La réponse dit que la liste est un extrait au lieu de l'appeler l'ensemble
des valeurs acceptées, parce qu'un serveur qui l'appellerait ainsi refuserait des
valeurs qui marchent.
Un total peut être un plancher. Le site sert au plus 10 000 lignes pour une
recherche et s'arrête là. Un total qui tombe exactement sur ce nombre a été
coupé, donc il énonce un plancher plutôt qu'un compte, et total_is_ceiling le
dit.
Un compte que le site n'a pas publié vaut null, jamais 0. Sur une échelle
qui commence à zéro, les deux seraient indiscernables.
Le site répond quand même à un terme dont il n'a rien. Chercher foobar rend
sept recettes, dont un cocktail à la rhubarbe et une barre de flapjack,
rapprochées par fragments, sans que rien ne marque la réponse comme un échec.
Chaque réponse rend donc rows_seen et matched_rows : combien de lignes le
site a servies, et combien d'entre elles portent un mot de la recherche. Quand la
seconde vaut zéro et la première non, une note dit que le compte décrit ce que le
site a proposé plutôt que ce qui correspond.
Deux comptes plutôt qu'un verdict. Une recherche légitime peut n'apparaître dans
aucun titre, et un lecteur qui voit 2 sur 30 juge mieux qu'un drapeau qui
jugerait pour lui.
Installation
npx mcp-bbc-goodfoodClaude Code
claude mcp add bbc-goodfood -- npx -y mcp-bbc-goodfoodN'importe quel client MCP
{
"mcpServers": {
"bbc-goodfood": {
"command": "npx",
"args": ["-y", "mcp-bbc-goodfood"]
}
}
}Conteneur
docker build -t mcp-bbc-goodfood .
docker run -i --rm mcp-bbc-goodfoodLe conteneur doit joindre www.bbcgoodfood.com et rien d'autre. Il ne prend
aucun identifiant, puisqu'il n'y en a aucun à prendre.
Réglages
Chaque réglage est une variable d'environnement, et aucune n'est obligatoire. Une valeur hors bornes est refusée par une ligne sur stderr et le défaut tient : un réglage qui ne peut pas prendre effet le dit, plutôt que d'être borné en silence.
Variable | Défaut | Bornes |
| — | Votre identifiant. Celui du projet reste ajouté, pour que le site puisse joindre une personne. |
| 1500 | 1000 à 60000 |
| 20000 | 1000 à 120000 |
| 3 | 0 à 8 |
| 900000 | 0 à 86400000, 0 éteint le stockage |
| 200 | 1 à 5000 |
|
|
|
Le plancher du rythme ne peut pas être abaissé de l'extérieur. Le site est gratuit à lire et ne publie aucun délai d'exploration, ce qui est une raison d'être prudent plutôt qu'une licence d'aller vite.
Comme bibliothèque
La couche de lecture est publiée seule, avec son rythme, son stockage et sa taxonomie d'erreurs, sans protocole attaché :
import { GoodFoodClient } from "mcp-bbc-goodfood/client";Erreurs
Six codes et pas un de plus. Un appelant branche sur le code qui ouvre le message.
Code | 含义 |
| 该地址下网站没有任何内容 |
| 参数无法生成请求 |
| 网站要求放慢速度。这并不能说明匹配情况 |
| 响应以该服务器无法读取的形式到达 |
| 请求未能完成 |
| 在时限内没有收到任何响应 |
署名
食谱、标题和账户归 BBC Good Food 所有。每个响应都带有来源,向读者展示的列表必须注明网站并链接到页面。
贡献
参见 CONTRIBUTING.md。测试优先,覆盖率下限为 100%,以及统辖一切的规则:服务器绝不会说出数据未承载的内容。
根据 MIT 许可发布。
Available Tools
4 toolsget_recipeRead a recipeARead-onlyIdempotent
Read one recipe on BBC Good Food: its ingredients, its steps, its times, its rating and its nutrition. Pass the 'id' a search_recipes row carries, which is the page's own path. A recipe behind the site's subscription comes back with everything except its ingredients and steps, and says so: its page on the site is where a subscriber reads it. The site writes many of its recipes twice, once for its own readers and once restated for readers in the United States, and 'unit_system' chooses which of the two to read.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The page's own path, as a search_recipes row carries it. | |
| servings | No | Put the ingredients to this many people. Quantities are then recomputed by this server, not published by the site, and each line says so under 'scaling'. | |
| unit_system | No | Which of the site's own two renditions to read: 'metric' as it writes for its own readers, 'us' as it restates for readers in the United States. Both are the site's words. A recipe it restated nowhere comes back as it published it, said in 'unit_system' and in the notes. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | The page. Show this when citing the recipe. |
| diets | Yes | |
| notes | Yes | |
| steps | Yes | Empty when the recipe sits behind the site's subscription. |
| title | Yes | |
| yield | Yes | What the ingredients were put to, and what they were put from. |
| author | Yes | |
| rating | Yes | 1 to 5. Null when nobody has rated it. |
| source | Yes | |
| premium | Yes | True when the recipe sits behind the site's subscription. |
| nutrition | Yes | |
| difficulty | Yes | |
| yield_text | Yes | The site's own wording, such as 'Serves 4 - 6'. |
| description | Yes | |
| ingredients | Yes | Empty when the recipe sits behind the site's subscription. |
| unit_system | Yes | Which of the site's two renditions this answer carries. |
| yield_count | Yes | The first whole number of that wording. |
| cook_minutes | Yes | |
| prep_minutes | Yes | |
| rating_count | Yes | |
| nutrition_per | Yes | The site's own wording for the serving. |
| total_minutes | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description reveals that subscription recipes omit ingredients and steps but explicitly say so, and that many recipes exist in two regional renditions selected by unit_system. This is meaningful behavioral context that annotations alone don't provide.
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, all informative, with the core purpose front-loaded. No redundant filler; each clause earns its place, including the paywall caveat and regional variant explanation.
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 single-recipe read operation with a full output schema and strong annotations, the description covers the key edge cases (paywall, regional variants) and the id provenance. Nothing essential for calling it correctly 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?
The schema already documents all three parameters in detail (100% coverage), including id's source and unit_system's meaning. The description adds no new parameter-level detail beyond restating id's origin and unit_system's role, so a baseline 3 is appropriate.
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?
States a specific verb ('Read') and resource ('one recipe on BBC Good Food') and enumerates the data fields returned (ingredients, steps, times, rating, nutrition). It clearly differentiates from siblings by focusing on a single recipe rather than searching, filtering, or scaling.
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?
Explicitly tells the agent to pass the 'id' that a search_recipes row carries, anchoring this tool to the search workflow. It also explains the subscription edge case and the unit_system choice, giving context for when these options matter, though it doesn't list explicit exclusions vs siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_filtersList the ways a search can be narrowedARead-onlyIdempotent
List the axes a recipe search can be narrowed along on BBC Good Food, with the values each one takes and how many recipes carry them. Pass 'query' to measure the counts inside one search, or leave it out for the site's whole listing. Read this before narrowing a search: the site accepts any value on a facet and answers one it does not know with a total of zero, so a guessed spelling comes back as a confident absence. The values listed are an excerpt of the most frequent ones, and the site accepts others that are not shown.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | A search to measure the counts inside. The site counts its facets over the rows a search returns, so a count without a query describes the whole listing instead. |
Output Schema
| Name | Required | Description |
|---|---|---|
| notes | Yes | |
| query | Yes | The search the counts were measured in, trimmed. |
| source | Yes | |
| filters | Yes | |
| filter_count | Yes | |
| total_available | Yes | Recipes the site says this scope holds. Null when it published no figure. |
| total_is_ceiling | Yes | True when the total sits on the largest number of rows one search will serve, so it states a floor rather than a count. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, and the description adds meaningful behavioral detail beyond that: the site returns zero for any unknown facet value, so a guessed spelling looks like a confident absence. It also discloses that the listed values are only an excerpt and other values are accepted, which is important practical information.
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?
The description is four sentences, front-loaded with the core behavior and followed by the important open-world caveat and excerpt warning. Every sentence earns its place, and there is no filler or repeated schema content.
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 one optional parameter, a rich schema description, an output schema, and annotations, the description covers what an agent needs: how to scope the counts, the fact that counts are measured over search results, and the open-world behavior. There are no obvious gaps that would prevent correct invocation.
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 for the single query parameter is 100%, so the schema already explains that counts without a query describe the whole listing. The description restates this idea but does not add much meaning beyond the schema, so a baseline 3 is appropriate.
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 action and resource: listing the axes a recipe search can be narrowed along on BBC Good Food, including values and recipe counts. This clearly distinguishes it from the sibling tools such as search_recipes because it is about enumerating facets rather than performing a search or fetching a recipe.
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?
The description gives clear context by saying to read this before narrowing a search, and it explains how to get counts for a specific query versus the whole listing. It does not explicitly name search_recipes as the execution alternative, but the sequencing guidance and facet-counting behavior make the intended use obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scale_ingredientsScale a list of ingredientsARead-onlyIdempotent
Put a list of ingredient lines to a different number of people. Pass 'factor', or else the pair 'from_servings' and 'to_servings'. Quantities are recomputed by this server and not by the site, and every line says under 'scaling' whether the arithmetic landed exactly, whether the figure was moved to stay usable in a kitchen, or whether the line carried nothing to multiply.
| Name | Required | Description | Default |
|---|---|---|---|
| factor | No | What to multiply every quantity by. Pass this or the servings pair, never both. | |
| ingredients | Yes | The lines to scale, as a recipe writes them, such as '200g plain flour'. | |
| to_servings | No | How many people it should feed. | |
| from_servings | No | How many people the list feeds as written. |
Output Schema
| Name | Required | Description |
|---|---|---|
| notes | Yes | |
| factor | Yes | What every quantity was multiplied by. |
| source | Yes | |
| ingredients | Yes | |
| scaled_count | Yes | Lines whose arithmetic landed exactly. |
| rounded_count | Yes | Lines whose figure was moved. |
| unscaled_count | Yes | Lines that carried no quantity to multiply. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by revealing that quantities are recomputed server-side, not by the website, and explains what each ingredient line will state under 'scaling'. This tells the caller what to expect and that the operation is non-destructive and idempotent. This aligns with the readOnly/idempotent annotations without contradicting them.
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?
The description is relatively brief and field-oriented. It leads with the primary purpose, covers the parameter modes, and includes the useful scaling behavior. The sentence about scaling statuses is a bit long, but it earns its place because it describes what to expect in the output.
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?
The description is sufficient for an agent to know when to use the tool, which keys to pass, and what the output will say about each line. Combined with an output schema, full parameter schema coverage, and annotations, no critical behavioral details are missing for safe and correct invocation.
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?
The schema already provides descriptions for all 4 parameters, so the baseline is adequate. The description adds value by explaining the mutually exclusive relationship between 'factor' and the servings pair, something the schema alone does not emphasize. It also gives semantic meaning to the scaling status output without repeating schema details.
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 strong verb and resource: it scales a list of ingredient lines to a different number of people. It also distinguishes the tool's operation from the siblings (search, listing, fetching) by naming the computation mode. The added detail about 'factor' or 'servings pair' makes the purpose precise.
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?
The description explains exactly how the tool should be invoked: pass 'factor' or the 'from_servings'/'to_servings' pair. It clearly communicates the mutually exclusive parameter use. It does not explicitly discuss when to use this tool versus the siblings, but the tool's purpose is sufficiently distinct for an agent to select it without deep inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_recipesSearch recipesARead-onlyIdempotent
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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
| 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. |
TDQS
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.
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.
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.
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.
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.
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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
4 tool updates
v1.1.0- Changed
get_recipe23 fields changed- removed
Output schema / properties / author / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / author / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / description / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / description / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / difficulty / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / difficulty / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / ingredients / items / properties / heading / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / ingredients / items / properties / heading / typeAdded value: +[ + "string", + "null" +] - changed
Output schema / properties / ingredients / items / properties / ingredients / items / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "amount": { - "anyOf": [ - { - "type": "number" - }, - { - "type": "null" - } - ], - "description": "Null when the site states no quantity." - }, - "item": { - "description": "What goes in, without its quantity.", - "type": "string" - }, - "note": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "description": "What to do to it beforehand, such as 'thinly sliced'." - }, - "term": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "description": "The site's own normalised name for it." - }, - "text": { - "description": "The line as the site composes it.", - "type": "string" - }, - "unit": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - } - }, - "required": [ - "text", - "amount", - "unit", - "item", - "note", - "term" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "amount": { - "anyOf": [ - { - "type": "number" - }, - { - "type": "null" - } - ] - }, - "amount_max": { - "anyOf": [ - { - "type": "number" - }, - { - "type": "null" - } - ] - }, - "original": { - "description": "The line as the site composes it.", - "type": "string" - }, - "scaling": { - "description": "'scaled': the arithmetic landed exactly. 'rounded': the figure moved to stay usable in a kitchen. 'unscaled': the line carried no quantity.", - "enum": [ - "scaled", - "rounded", - "unscaled" - ], - "type": "string" - }, - "text": { - "description": "The line as it now reads.", - "type": "string" - }, - "unit": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ] - } - }, - "required": [ - "text", - "original", - "scaling", - "amount", - "amount_max", - "unit" - ], - "type": "object" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "amount": { + "description": "Null when the site states no quantity.", + "type": [ + "number", + "null" + ] + }, + "item": { + "description": "What goes in, without its quantity.", + "type": "string" + }, + "note": { + "description": "What to do to it beforehand, such as 'thinly sliced'.", + "type": [ + "string", + "null" + ] + }, + "term": { + "description": "The site's own normalised name for it.", + "type": [ + "string", + "null" + ] + }, + "text": { + "description": "The line as the site composes it.", + "type": "string" + }, + "unit": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "text", + "amount", + "unit", + "item", + "note", + "term" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "amount": { + "type": [ + "number", + "null" + ] + }, + "amount_max": { + "type": [ + "number", + "null" + ] + }, + "original": { + "description": "The line as the site composes it.", + "type": "string" + }, + "scaling": { + "description": "'scaled': the arithmetic landed exactly. 'rounded': the figure moved to stay usable in a kitchen. 'unscaled': the line carried no quantity.", + "enum": [ + "scaled", + "rounded", + "unscaled" + ], + "type": "string" + }, + "text": { + "description": "The line as it now reads.", + "type": "string" + }, + "unit": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "text", + "original", + "scaling", + "amount", + "amount_max", + "unit" + ], + "type": "object" + } +] - removed
Output schema / properties / nutrition / items / properties / value / anyOfRemoved value: -[ - { - "type": "number" - }, - { - "type": "null" - } -] - added
Output schema / properties / nutrition / items / properties / value / typeAdded value: +[ + "number", + "null" +] - removed
Output schema / properties / nutrition_per / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / nutrition_per / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / rating / anyOfRemoved value: -[ - { - "type": "number" - }, - { - "type": "null" - } -] - added
Output schema / properties / rating / typeAdded value: +[ + "number", + "null" +] - removed
Output schema / properties / yield / properties / factor / anyOfRemoved value: -[ - { - "type": "number" - }, - { - "type": "null" - } -] - added
Output schema / properties / yield / properties / factor / typeAdded value: +[ + "number", + "null" +] - removed
Output schema / properties / yield / properties / original_text / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / yield / properties / original_text / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / yield / properties / unit / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / yield / properties / unit / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / yield_text / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / yield_text / typeAdded value: +[ + "string", + "null" +]
- Changed
list_filters4 fields changed- removed
Output schema / properties / filters / items / properties / argument / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / filters / items / properties / argument / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / query / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / query / typeAdded value: +[ + "string", + "null" +]
- Changed
scale_ingredients6 fields changed- removed
Output schema / properties / ingredients / items / properties / amount / anyOfRemoved value: -[ - { - "type": "number" - }, - { - "type": "null" - } -] - added
Output schema / properties / ingredients / items / properties / amount / typeAdded value: +[ + "number", + "null" +] - removed
Output schema / properties / ingredients / items / properties / amount_max / anyOfRemoved value: -[ - { - "type": "number" - }, - { - "type": "null" - } -] - added
Output schema / properties / ingredients / items / properties / amount_max / typeAdded value: +[ + "number", + "null" +] - removed
Output schema / properties / ingredients / items / properties / unit / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / ingredients / items / properties / unit / typeAdded value: +[ + "string", + "null" +]
- Changed
search_recipes8 fields changed- removed
Output schema / properties / results / items / properties / author / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / results / items / properties / author / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / results / items / properties / difficulty / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / results / items / properties / difficulty / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / results / items / properties / image_url / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / results / items / properties / image_url / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / results / items / properties / rating / anyOfRemoved value: -[ - { - "type": "number" - }, - { - "type": "null" - } -] - added
Output schema / properties / results / items / properties / rating / typeAdded value: +[ + "number", + "null" +]
4 tool updates
- Added
get_recipe - Changed
list_filters4 fields changed- added
Output schema / properties / filters / items / properties / argumentAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "The search_recipes argument that restricts this axis. Null where a search takes none. A value listed here is in the site's units and may need converting before it is passed." +} - changed
Output schema / properties / filters / items / properties / name / descriptionPrevious value: -"The argument name a search takes for this axis."New value: +"The site's own name for the axis." - changed
Output schema / properties / filters / items / properties / options / items / properties / value / descriptionPrevious value: -"Pass this back to narrow a search along this axis."New value: +"The value as the site publishes it, in the site's own units." - changed
Output schema / properties / filters / items / requiredPrevious value: -[ - "name", - "label", - "options", - "option_count" -]New value: +[ + "name", + "label", + "argument", + "options", + "option_count" +]
- Added
scale_ingredients - Changed
search_recipes4 fields changed- removed
Output schema / properties / restrictions_droppedRemoved value: -{ - "description": "Restrictions the site could not answer, dropped so the search could run.", - "items": { - "type": "string" - }, - "type": "array" -} - added
Output schema / properties / restrictions_liftedAdded value: +{ + "description": "Restrictions let go of so the search could run again after the restricted one returned nothing.", + "items": { + "type": "string" + }, + "type": "array" +} - changed
Output schema / properties / results / items / properties / id / descriptionPrevious 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." - changed
Output schema / requiredPrevious 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" +]
2 tool updates
v0.1.0- First observed
list_filters - First observed
search_recipes
TDQS
Scored across 4 tools
Each tool serves a distinct function: list_filters discovers search axes, search_recipes performs the actual search, get_recipe retrieves details, and scale_ingredients transforms ingredient quantities. There is no overlap in purpose; the dependency between list_filters and search_recipes is clear and complementary.
All tool names follow a consistent verb_noun pattern in snake_case (list_filters, search_recipes, get_recipe, scale_ingredients). The verbs and nouns are specific and predictable, matching the domain perfectly.
Four tools are appropriate for a recipe-focused server. They cover the essential operations without redundancy or bloat, and the scope is well-defined for browsing, searching, and retrieving recipe content.
The tool surface covers the full user workflow for a read-only recipe service: discovering available filters, searching, viewing a recipe, and scaling ingredients. No critical operations are missing for the stated purpose, and the added scaling feature enhances usability without leaving gaps.
Maintenance
Related MCP Connectors
Search structured recipes, scale servings, match pantry ingredients, and build shopping lists.
1Search and compare attributed recipe records through a public read-only remote MCP endpoint.
Read-only kitchen costing, recipe scaling, UK GP, starter menus, and prep lists for chefs.
61
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceProvides access to the Spoonacular food API for recipes, nutrition, ingredients, and meal plans.53 npmMIT
- FlicenseNot gradedqualityDmaintenanceEnables browsing recipes, searching by category, and viewing detailed recipe information from the Gousto cookbook API via natural language.-
- AlicenseNot gradedqualityBmaintenanceEnables querying Open Food Facts product database by barcode, full-text search, category, brand, or country.30 npmMIT

MealCP MCPofficial
AlicenseAqualityAmaintenanceEnables searching grocery product catalogs with faceted filters and retrieving price history statistics via the MealCP grocery price API.2MIT