F
licenseC
qualityD
maintenanceEnables management of culinary recipes through web scraping from sites like Marmiton.org, recipe generation, ingredient management, and querying a MongoDB database of recipes, comments, users, and utensils.
18
-
mcp-supertoinette
by smeet666
This server connects a chat client to the French cooking site Supertoinette, letting you search, read, and scale recipes, browse categories, and get wine pairings—no API key or account needed.
Search recipes by dish or ingredient in French, with pagination and category filters.
Read one recipe in full, rescaling ingredients to any number of servings.
List recipe categories used by the site.
Browse a category page by page to see its recipes.
Get wine pairings for a dish, either by dish ID or by browsing the alphabetical dish index.
Scale any ingredient list offline by a factor or from one serving count to another.
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., "@mcp-supertoinetteGet recipe 4210 and scale it to 4 servings"
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.
mcp-supertoinette
Supertoinette is a French cooking site, one of the oldest still standing. Its recipes give their ingredients, their steps, their preparation, cooking and resting times, the number of people they feed and the photographs of the dish. Beside the recipes it keeps a set of pages of its own on what to drink with a dish, matching a wine to it and saying which style it belongs to.
This server connects a chat client to that site. You can search its recipes, read one with its ingredients rescaled to the number of people at your table, walk its categories, read a category page by page, and look up what it suggests drinking with a dish. It needs no API key and no account.
Install
One-click install
Claude Code
claude mcp add supertoinette -- npx -y mcp-supertoinetteClaude Desktop, Cursor, and any client using the standard config format
{
"mcpServers": {
"supertoinette": {
"command": "npx",
"args": ["-y", "mcp-supertoinette"]
}
}
}Node 24 or later is required, and no environment variable has to be set.
With Docker
{
"mcpServers": {
"supertoinette": {
"command": "docker",
"args": ["run", "-i", "--rm", "ghcr.io/smeet666/mcp-supertoinette:1.1.0"]
}
}
}-i keeps stdin open, which is where the protocol travels, and -t is left out
because a TTY rewrites the stream. The container needs outbound HTTPS to
www.supertoinette.com, and nothing else: no volume, no port, no credential.
Bundle, without npm
Download mcp-supertoinette-1.1.0.mcpb from
the latest release
and open it. A client that supports MCP bundles installs it on its own, with no
npm and no configuration file to edit. The bundle carries its dependencies, so
nothing is fetched at install time.
Related MCP server: mcp-marmiton
What you can ask
« Trouve-moi une recette de blanquette de veau. »
"Read me that recipe for ten people."
"What categories does the site file its recipes under?"
"What wine goes with a beef bourguignon?"
"Scale this ingredient list from my grandmother's notebook by three."
Supertoinette is a French site, so its recipes are found in French. The ordinary
path runs from a search to a recipe: a row carries an id, and get_recipe
takes that id.
Tools
Tool | What it does |
| Reads one recipe, rescaled to a number of servings on request. |
| Finds recipes by dish or by ingredient. |
| Reads the categories the site files its recipes under. |
| Reads one category, page by page. |
| Reads what the site suggests drinking with a dish. |
| Rescales any ingredient list, with no request to the site. |
get_recipe
Reads one recipe in full, and rescales its ingredients when a number of servings is given.
Argument | Type | Required | What it does |
| string, 1 to 10 characters | yes | The number in a recipe's address, as a row carries it. |
| integer, 1 to 1000 | no | Rescale the ingredients to this many servings. |
In return: title with the pictogram the site opens it with taken off, and
title_as_published exactly as the site wrote it; url; description;
published_at; intro, the prose printed above the method; steps;
prep_minutes, cook_minutes, rest_minutes and total_minutes; category;
author; and rating, each null where the page states nothing. yield says
what the recipe was written for and what it was rescaled to. ingredients
carries the lines with the headings the page groups them under, which is what
ingredient_count counts, and each line's scaling reads scaled, rounded or
unscaled.
search_recipes
Searches the recipes for a dish or an ingredient, one page at a time.
Argument | Type | Required | What it does |
| string, 1 to 120 characters | yes | A dish or an ingredient, in French. |
| integer, 1 to 39 | no | Rows to serve. |
| integer, 1 to 1000 | no | Which page of results to read, the first by default. |
| string, 1 to 60 characters | no | One category, spelled as a previous answer's |
In return: rows carrying id, which get_recipe takes, title,
title_as_published and url. Alongside come page, last_page for the
highest page the site links to from this one, result_count, rows_published
for the rows the page held before any were rendered, total_available and
facets, which publishes the category wordings a further search takes. Never
build a category wording by hand: the site answers one it does not know with a
page that reads as an absence.
list_categories
Reads the categories the site files its recipes under. It takes no argument.
In return: categories, with category_count for the entries the site's two
lists hold, and the url they were read from. Pass a category on to
browse_recipes.
browse_recipes
Reads one category, page by page.
Argument | Type | Required | What it does |
| string, 1 to 80 characters | yes | A category, as |
| integer, 1 to 30 | no | Rows to serve. |
| integer, 1 to 1000 | no | Which page to read, the first by default. |
In return: the rows and the envelope search_recipes returns, with
last_page saying how far the listing runs.
get_wine_pairings
Reads what the site suggests drinking with a dish, from the pages it wrote on the subject.
Argument | Type | Required | What it does |
| string, 1 to 10 characters | one of two | The number in a dish's address. |
| integer, 1 to 100 | one of two | A page of the site's own listing of dishes. |
In return: entries carrying the id, the dish under the site's own name
for it, and style, the style of wine the page opens with, which is null where
it wrote none.
scale_ingredients
Applies the same arithmetic to any list of French ingredient lines, with no request to the site.
Argument | Type | Required | What it does |
| array of 1 to 200 strings, 1 to 300 characters | yes | The lines to rescale, as the recipe wrote them. |
| number, above 0 and up to 100 | one of two | What to multiply the quantities by. |
| integer, 1 to 1000 | one of two | How many the list was written for. |
| integer, 1 to 1000 | one of two | How many it should feed. |
Pass factor, or the from_servings and to_servings pair.
In return: the rescaled lines in the shape get_recipe returns, each with
its scaling.
Rescaling the quantities
A quantity is stated in the unit that suits it, so a line can come back in a
different unit from the one the recipe used: 200 g multiplied by twenty reads
4 kg.
How finely an ingredient can be divided depends on what it is. A baguette can be
cut in two, in three or in four; an egg cannot be shared out. A quantity landing
between the two is rounded, and the rescaled recipe then departs a little from
the proportions of the original. The line carries rounded, and its note says
what was done.
The figures are this server's arithmetic, so say they were recomputed when you show them. A recipe whose page states no number of servings cannot be put to a number of people, and the answer says so.
Configuration
Every variable is optional. Set them in the env block of your client config.
Variable | Default | What it does |
| the project identity | Names your application to the site, with an address where a person can be reached. |
|
| Gap between two requests, from 3000 to 60000. |
|
| Deadline for one request, from 1000 to 120000. |
|
| Attempts after a transient failure, from 0 to 8. |
|
| How long a page stays in memory, from 0 to 86400000. |
|
| Pages held in memory at once, from 1 to 5000. |
|
| Largest page this reads, in bytes, from 100000 to 64000000. |
|
|
|
A value outside its range falls back to the default, and the reason is written to stderr.
Errors
Every failure carries one of six codes, a message, and where it helps a hint naming the next move.
Code | What happened | What to do |
| The site answered, and holds no such recipe or page. | Check the id with |
| The arguments were refused before any request went out. | Read the message, which names the argument. |
| The site asked this client to slow down. | Wait the number of seconds the hint names and call again with the same arguments. The recipe is still there. |
| The page loaded and the expected content was absent. | Report it at the issue tracker. |
| The request did not complete. | Try again shortly. |
| The request passed its deadline. | Raise |
As a library
The layer reading the site is published on its own, with its pacing, its cache and its errors, and with no protocol attached.
import { SupertoinetteClient } from "mcp-supertoinette/client";
const client = new SupertoinetteClient();
const { data, cached } = await client.getRecipe({ id: "10" });
console.log(data.title, data.ingredients.length, cached);searchRecipes, browseRecipes, getRecipe and getPairings each answer
{ data, cached }, and throw an error carrying one of the six codes. The
three-second floor between two requests holds here as well.
Pacing and attribution
Requests go out one at a time with at least three seconds between them, and that
floor holds however the server is configured. The User-Agent always ends with
the project identity and an address where a person can be reached.
Every result carries the address of the page it was read from, and source names
the site. Recipes, titles and photographs belong to Supertoinette.
This MCP server is an unofficial project, with no affiliation to Supertoinette.
Privacy
This server collects nothing about you and sends nothing to its author. It runs
on your machine, contacts www.supertoinette.com and nothing else, holds its answers in memory
while it runs, and writes nothing to disk.
PRIVACY.md states what a request carries and which settings change
any of it.
Development
npm install
npm run build:fixtures
npm test
npm run checkTests run against generated fixtures and make no network request. The live suite,
npm run test:live, makes one request per route and runs nightly against the
site itself.
Contributing
Bugs, questions and ideas belong in the issue tracker. Pull requests are welcome; opening an issue first helps agree on the shape of the change. See CONTRIBUTING.md.
License
MIT, see LICENSE. The recipes belong to Supertoinette and to their authors.
mcp-supertoinette (français)
Supertoinette est un site de cuisine français, l'un des plus anciens encore debout. Ses recettes donnent leurs ingrédients, leurs étapes, leurs temps de préparation, de cuisson et de repos, le nombre de convives qu'elles nourrissent et les photographies du plat. À côté des recettes, il tient un ensemble de pages sur ce qu'on boit avec un plat, qui lui associent un vin et disent de quel style il relève.
Ce serveur relie un client de conversation à ce site. On peut y chercher des recettes, en lire une avec ses ingrédients adaptés au nombre de convives, parcourir ses catégories, lire une catégorie page par page, et consulter ce qu'il propose de boire avec un plat. Aucune clé d'API, aucun compte.
Installation
Installation en un clic
Claude Code
claude mcp add supertoinette -- npx -y mcp-supertoinetteClaude Desktop, Cursor, et tout client au format de configuration standard
{
"mcpServers": {
"supertoinette": {
"command": "npx",
"args": ["-y", "mcp-supertoinette"]
}
}
}Node 24 ou plus récent est nécessaire, et aucune variable d'environnement n'est à renseigner.
Avec Docker
{
"mcpServers": {
"supertoinette": {
"command": "docker",
"args": ["run", "-i", "--rm", "ghcr.io/smeet666/mcp-supertoinette:1.1.0"]
}
}
}-i garde l'entrée standard ouverte, qui est le canal du protocole, et -t est
omis parce qu'un TTY réécrit le flux. Le conteneur a besoin d'un accès HTTPS
sortant vers www.supertoinette.com, et de rien d'autre : aucun volume, aucun
port, aucun identifiant.
Bundle, sans npm
Téléchargez mcp-supertoinette-1.1.0.mcpb depuis
la dernière publication
et ouvrez-le. Un client qui gère les bundles MCP l'installe seul, sans npm et
sans fichier de configuration à modifier. Le bundle emporte ses dépendances, donc
rien n'est téléchargé à l'installation.
Ce qu'on peut demander
« Trouve-moi une recette de blanquette de veau. »
« Lis-moi cette recette pour dix personnes. »
« Sous quelles catégories le site classe-t-il ses recettes ? »
« Quel vin avec un boeuf bourguignon ? »
« Multiplie par trois cette liste d'ingrédients du carnet de ma grand-mère. »
Supertoinette est un site français, donc ses recettes se trouvent en français. Le
chemin ordinaire va d'une recherche à une recette : une ligne porte un id, et
get_recipe reprend cet identifiant.
Les outils
Outil | Ce qu'il fait |
| Lit une recette, adaptée à un nombre de parts sur demande. |
| Trouve des recettes par plat ou par ingrédient. |
| Lit les catégories sous lesquelles le site classe ses recettes. |
| Lit une catégorie, page par page. |
| Lit ce que le site propose de boire avec un plat. |
| Adapte n'importe quelle liste d'ingrédients, sans requête au site. |
get_recipe
Lit une recette en entier, et adapte ses ingrédients quand un nombre de parts est donné.
Argument | Type | Requis | Ce qu'il fait |
| chaîne, 1 à 10 caractères | oui | Le numéro dans l'adresse d'une recette, porté par une ligne. |
| entier, 1 à 1000 | non | Adapte les ingrédients à ce nombre de parts. |
En retour : title sans le pictogramme par lequel le site l'ouvre, et
title_as_published exactement comme le site l'a écrit ; url ; description ;
published_at ; intro, la prose imprimée au-dessus de la méthode ; steps ;
prep_minutes, cook_minutes, rest_minutes et total_minutes ; category ;
author ; et rating, chacun null là où la page n'indique rien. yield dit
pour quoi la recette est écrite et vers quoi elle a été adaptée. ingredients
porte les lignes avec les intertitres sous lesquels la page les groupe, ce que
compte ingredient_count, et le scaling de chaque ligne vaut scaled,
rounded ou unscaled.
search_recipes
Cherche des recettes par plat ou par ingrédient, une page à la fois.
Argument | Type | Requis | Ce qu'il fait |
| chaîne, 1 à 120 caractères | oui | Un plat ou un ingrédient, en français. |
| entier, 1 à 39 | non | Lignes à servir. |
| entier, 1 à 1000 | non | La page de résultats à lire, la première par défaut. |
| chaîne, 1 à 60 caractères | non | Une catégorie, orthographiée comme les |
En retour : des lignes portant id, que get_recipe reprend, title,
title_as_published et url. Viennent aussi page, last_page pour la page la
plus lointaine que le site relie depuis celle-ci, result_count,
rows_published pour les lignes que la page contenait avant tout rendu,
total_available et facets, qui publie les formulations de catégorie qu'une
recherche suivante reprend. Ne construisez jamais une formulation à la main : le
site répond à celle qu'il ne connaît pas par une page qui se lit comme une
absence.
list_categories
Lit les catégories sous lesquelles le site classe ses recettes. Il ne prend aucun argument.
En retour : categories, avec category_count pour les entrées que les deux
listes du site contiennent, et l'url d'où elles ont été lues. Une catégorie se
redonne à browse_recipes.
browse_recipes
Lit une catégorie, page par page.
Argument | Type | Requis | Ce qu'il fait |
| chaîne, 1 à 80 caractères | oui | Une catégorie, publiée par |
| entier, 1 à 30 | non | Lignes à servir. |
| entier, 1 à 1000 | non | La page à lire, la première par défaut. |
En retour : les lignes et l'enveloppe que rend search_recipes, avec
last_page qui dit jusqu'où va la liste.
get_wine_pairings
Lit ce que le site propose de boire avec un plat, d'après les pages qu'il a écrites sur le sujet.
Argument | Type | Requis | Ce qu'il fait |
| chaîne, 1 à 10 caractères | l'un des deux | Le numéro dans l'adresse d'un plat. |
| entier, 1 à 100 | l'un des deux | Une page de la liste de plats du site. |
En retour : des entrées portant l'id, le dish sous le nom que le site lui
donne, et style, le style de vin par lequel la page s'ouvre, null là où elle
n'en a écrit aucun.
scale_ingredients
Applique la même arithmétique à n'importe quelle liste d'ingrédients en français, sans requête au site.
Argument | Type | Requis | Ce qu'il fait |
| tableau de 1 à 200 chaînes, 1 à 300 caractères | oui | Les lignes à adapter, comme la recette les a écrites. |
| nombre, au-delà de 0 jusqu'à 100 | l'un des deux | Ce par quoi multiplier les quantités. |
| entier, 1 à 1000 | l'un des deux | Le nombre de convives de la liste d'origine. |
| entier, 1 à 1000 | l'un des deux | Le nombre de convives voulu. |
Passez factor, ou le couple from_servings et to_servings.
En retour : les lignes adaptées dans la forme que rend get_recipe, chacune
avec son scaling.
L'adaptation des quantités
Une quantité est exprimée dans l'unité qui lui convient. Après adaptation, une
ligne peut donc apparaître dans une autre unité que celle de la recette : 200 g
multipliés par vingt donnent 4 kg.
La finesse à laquelle un ingrédient se coupe dépend de sa nature. Une baguette se
coupe en deux, en trois ou en quatre ; un oeuf ne se partage pas. Une quantité
qui tombe entre les deux est donc arrondie, et la recette adaptée s'écarte alors
un peu des proportions de l'originale. La ligne porte rounded, et sa note dit
ce qui a été fait.
Les chiffres sont l'arithmétique de ce serveur, donc dites qu'ils ont été recalculés quand vous les montrez. Une recette dont la page n'indique aucun nombre de parts ne peut pas être portée à un nombre de convives, et la réponse le dit.
Configuration
Chaque variable est facultative. Elles se posent dans le bloc env de la
configuration du client.
Variable | Défaut | Ce qu'elle fait |
| l'identité du projet | Nomme votre application auprès du site, avec une adresse où joindre une personne. |
|
| Écart entre deux requêtes, de 3000 à 60000. |
|
| Délai d'une requête, de 1000 à 120000. |
|
| Tentatives après un échec passager, de 0 à 8. |
|
| Durée pendant laquelle une page reste en mémoire, de 0 à 86400000. |
|
| Pages gardées en mémoire à la fois, de 1 à 5000. |
|
| Plus grande page lue, en octets, de 100000 à 64000000. |
|
|
|
Une valeur hors de sa plage retombe sur le défaut, et la raison est écrite sur la sortie d'erreur.
Erreurs
Chaque échec porte un des six codes, un message, et quand cela aide une indication du geste suivant.
Code | Ce qui s'est passé | Que faire |
| Le site a répondu, et n'a ni cette recette ni cette page. | Vérifiez l'identifiant avec |
| Les arguments ont été refusés avant toute requête. | Lisez le message, qui nomme l'argument. |
| Le site demande à ce client de ralentir. | Attendez les secondes indiquées et rappelez avec les mêmes arguments. La recette est toujours là. |
| La page a chargé et le contenu attendu est absent. | Signalez-le sur le suivi d'incidents. |
| La requête n'a pas abouti. | Réessayez sous peu. |
| La requête a dépassé son délai. | Augmentez |
Comme bibliothèque
La couche qui lit le site est publiée seule, avec son rythme, son cache et ses erreurs, sans protocole attaché.
import { SupertoinetteClient } from "mcp-supertoinette/client";
const client = new SupertoinetteClient();
const { data, cached } = await client.getRecipe({ id: "10" });
console.log(data.title, data.ingredients.length, cached);searchRecipes, browseRecipes, getRecipe et getPairings répondent chacun
{ data, cached }, et lèvent une erreur portant un des six codes. Le plancher de
trois secondes entre deux requêtes tient également ici.
Rythme et attribution
Les requêtes partent une à une avec au moins trois secondes entre elles, et ce
plancher tient quelle que soit la configuration. Le User-Agent se termine
toujours par l'identité du projet et une adresse où joindre une personne.
Chaque résultat porte l'adresse de la page d'où il a été lu, et source nomme le
site. Les recettes, les titres et les photographies appartiennent à
Supertoinette.
Ce MCP est un projet non officiel, sans affiliation à Supertoinette.
Confidentialité
Ce serveur ne collecte rien sur vous et n'envoie rien à son auteur. Il tourne sur
votre machine, ne joint que www.supertoinette.com, garde ses réponses en mémoire le temps qu'il
tourne, et n'écrit rien sur le disque. PRIVACY.md dit ce qu'une
requête emporte et quels réglages changent cela.
Développement
npm install
npm run build:fixtures
npm test
npm run checkLes tests s'exécutent sur des fixtures engendrées et n'émettent aucune requête.
La suite en direct, npm run test:live, émet une requête par route et tourne
chaque nuit contre le site lui-même.
Contribuer
Les anomalies, les questions et les idées ont leur place dans le suivi d'incidents. Les propositions de modification sont bienvenues ; ouvrir un ticket d'abord aide à s'accorder sur la forme du changement. Voir CONTRIBUTING.md.
Licence
MIT, voir LICENSE. Les recettes appartiennent à Supertoinette et à leurs auteurs.
Available Tools
6 toolsbrowse_recipesRead one category's recipesARead-onlyIdempotent
Read the recipes of one Supertoinette category, page by page. The category is a number and a name together, taken from list_categories or from the 'tags' of a recipe, and never assembled by hand. Each row carries the identifier get_recipe reads a recipe with, plus the difficulty and the total time the site prints beside it. The site publishes no total, so 'last_page' says how far the listing runs.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Which page to read, 1 by default. 'last_page' says how far the listing runs. | |
| limit | No | Rows to render, 20 by default. The site serves at most 30 to a page, and 'rows_published' always states what the page held. | |
| category | Yes | The category to read, as a number and a name together, such as '107/recettes-desserts'. Take one from list_categories or from a recipe's tags. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | The page these rows were read from. |
| page | Yes | The page these rows were read from. |
| notes | Yes | |
| title | Yes | The site's own heading for the category. |
| source | Yes | |
| results | Yes | |
| category | Yes | The category that was read. |
| last_page | Yes | The highest page the site links to from this one. |
| result_count | Yes | Rows rendered here. |
| rows_published | Yes | Rows the page held, before any were rendered. |
| total_available | Yes | Supertoinette prints no total on a category page, so there is none to report. |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering safety and idempotency. The description adds a meaningful behavioral detail the annotations lack: the site publishes no total, so 'last_page' indicates listing depth. This goes beyond the schema and helps the agent understand pagination and output expectations without contradicting the annotations.
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?
Three sentences, front-loaded with the core action, then necessary context about category sourcing and pagination. Every sentence provides distinct value; no filler or repetition. The length is appropriate for the tool's moderate complexity.
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?
Given the output schema exists, the input schema is fully described, and annotations cover safety and idempotency, the description completes the picture: how to obtain a valid category, that pagination is bounded by a last_page indicator, and that each row links to get_recipe. Nothing essential an agent needs to invoke 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 baseline is 3. The description does not introduce semantics beyond the schema for page and limit; it only reinforces the category format already described in the schema ('as a number and a name together'). It adds minor context about 'rows_published' and 'last_page', but these refer to output fields, not parameter meaning. No material enhancement over the schema.
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 clear verb+resource: 'Read the recipes of one Supertoinette category, page by page.' It specifies the resource as a category and differentiates from siblings by referencing list_categories for the identifier and get_recipe for individual recipe reads. The purpose is unmistakable and distinct from search_recipes.
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 practical guidance on sourcing the category ('taken from list_categories or from the 'tags' of a recipe, and never assembled by hand') and implies the pagination workflow via 'last_page'. While it mentions get_recipe as the tool that reads individual rows, it does not explicitly contrast with search_recipes or state when browsing by category is preferred over searching. Still, the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_recipeRead one recipeARead-onlyIdempotent
Read one recipe on Supertoinette by its identifier, which is the number in its address: 4210 in /recette/4210/veloute-de-gaverole.html. Returns the ingredients, the steps, the times, the difficulty and the cost the site publishes. A time the site does not publish comes back as null rather than as zero. Pass 'servings' to rescale the quantities: each line then says whether the arithmetic landed exactly, or had to move to stay an amount a kitchen can measure out.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The number in the recipe's address, such as '4210'. Search for a dish when you do not have one. | |
| servings | No | Rescale the quantities to this many. Left out, they come back as the site published them. It is refused when the site's own wording carries no number to scale from. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| faq | Yes | |
| url | Yes | The public page. Show this when citing the recipe. |
| tags | Yes | |
| intro | Yes | The prose the page prints above the steps. |
| notes | Yes | |
| steps | Yes | |
| title | Yes | The title with the pictogram the site opens it with taken off. |
| yield | Yes | How many the recipe was written for, and how many were asked for. |
| author | Yes | |
| images | Yes | |
| rating | Yes | |
| source | Yes | |
| category | Yes | |
| nutrition | Yes | Supertoinette publishes none. |
| cost_level | Yes | The site's own wording, with the scale it draws the symbols on. |
| difficulty | Yes | The site's own wording. It publishes no scale for this, so none is stated. |
| description | Yes | |
| ingredients | Yes | |
| cook_minutes | Yes | Null when the site publishes no cooking time. |
| prep_minutes | Yes | Null when the site publishes no preparation time. |
| published_at | Yes | |
| rest_minutes | Yes | Resting time, which the page prints as 'Pause'. |
| total_minutes | Yes | |
| ingredient_count | Yes | Lines rendered, headings included. |
| ingredient_sheets | Yes | |
| title_as_published | Yes | The title exactly as the site wrote it. |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotent annotations, the description discloses specific behaviors: missing times return null instead of zero, and rescaling reports whether arithmetic landed exactly or required rounding to measurable amounts. These details add genuine value beyond what annotations convey, with no contradiction.
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 two sentences, front-loaded with purpose and identifier format, then packed with behavioral notes. No filler—every sentence and clause contributes actionable information.
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 a detailed output schema present and annotations covering safety, the description adequately covers what an agent needs to call the tool: identifier extraction, handling of missing data, and optional rescaling behavior. No critical gaps remain.
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 description coverage is 100%, so parameters are already well-documented. The description adds extra nuance for 'servings' (rounding behavior, refusal condition) and clarifies id format with a concrete example. This enriches the schema but is not essential, hence slightly above the baseline of 3.
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 states 'Read one recipe on Supertoinette by its identifier' with a concrete example of the address format. It clearly differentiates from siblings like search or browse by focusing on single-recipe retrieval and enumerates returned fields (ingredients, steps, times, difficulty, cost).
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?
The description gives clear context: use the id from the URL and optionally pass 'servings' to rescale. It also notes when servings is refused (no scaling number in site wording) and suggests 'Search for a dish when you do not have one' in the parameter schema, acting as an alternative pointer. However, it does not explicitly list exclusions or compare to each sibling, leaving room for slight ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_wine_pairingsRead the wines ranked for a dishARead-onlyIdempotent
Read the wines Supertoinette ranks for one dish, given the number in its address as 'id'. Each wine comes with the site's own wording for how well it goes, from 'Bon accord' to 'Accord parfait'. Called with 'page' instead, it reads one page of the alphabetical index of dishes, which is where the identifiers come from: the index runs alphabetically, so a dish beginning with a late letter sits on a late page.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | The number in a dish's address, such as '10'. Give this or 'page'. | |
| page | No | Read one page of the alphabetical index of dishes instead of one dish. Give this or 'id'. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| dish | Yes | The wines ranked for one dish, when 'id' was given. |
| kind | Yes | Which of the two answers arrived. The other field is null. |
| index | Yes | One page of the index of dishes, when 'page' was given. |
| notes | Yes | |
| source | Yes |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds valuable context beyond annotations: the rating wording scale ('Bon accord' to 'Accord parfait'), the alphabetical ordering of the index, and the mechanism for locating dish identifiers. This goes beyond minimal disclosure.
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?
The description is three sentences, each contributing information: purpose, rating scale, and the page/index relationship. It is front-loaded with the primary action and avoids fluff. Slightly long but every sentence is relevant, so it earns a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two modes and an output schema, so the description covers the necessary usage context: how to get ids, the index ordering, and the rating scale. It does not explain output format, but the presence of an output schema makes that unnecessary. Missing error-handling details are minor for a read-only tool.
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 both parameters are already documented. The description adds meaning by explaining 'id' as 'the number in a dish's address' and 'page' as reading the index, plus clarifying the mutual exclusivity ('Give this or 'page''). This enriches the schema's baseline.
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 states a specific verb ('Read') and resource ('the wines Supertoinette ranks for one dish'), and clearly distinguishes the tool from siblings like get_recipe or search_recipes by focusing on wine pairings. It also explains the two invocation modes (by dish id or by index page), making the tool's purpose unambiguous.
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?
The description explains when to use each parameter (id vs. page) and how they relate (the index provides identifiers). It does not explicitly compare this tool to alternatives, but the distinct purpose and sibling names make the selection clear. Since there is no explicit 'when not to use' guidance, it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_categoriesList the categories recipes are browsed byARead-onlyIdempotent
List the categories Supertoinette browses its recipes by. Each entry carries the token that opens its listing with browse_recipes, and 'listed_in' says where the site printed it: its footer holds the kinds of dish, its menu holds the ways of cooking and the seasons. Never build a token by hand, because the site answers a number paired with the wrong name with a page it does not hold. These two lists are not every category the site files recipes under: a recipe's own tags open onto hundreds more that neither list publishes.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | The page these categories were read from. |
| notes | Yes | |
| source | Yes | |
| categories | Yes | |
| category_count | Yes | Entries the two lists hold. |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only, idempotent, and non-destructive; the description adds valuable behavior beyond that: entries carry browse_recipes tokens, 'listed_in' reflects site placement, malformed tokens yield pages the site does not hold, and the list is not exhaustive. This is rich, relevant behavioral disclosure with no contradiction.
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 opens with a crisp purpose statement, then each subsequent sentence adds essential information: token usage, placement semantics, the warning against hand-built tokens, and coverage limitations. There is no filler or repetition.
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 the safety profile, the description supplies the missing piece: what the entries mean, how to use them with browse_recipes, and how far the categories list extends. An agent has everything needed to invoke and interpret the tool correctly.
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?
The tool has zero parameters, so the baseline is 4 as per the rubric. The input schema is empty and fully described by its 100% coverage, and the description correctly focuses on output semantics rather than inventing parameter guidance.
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 uses a specific verb ('List') and a clear resource ('categories Supertoinette browses its recipes by'), immediately distinguishing it from sibling tools like get_recipe or search_recipes. It also names browse_recipes as the downstream consumer of the returned tokens, further clarifying its role.
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?
The description gives clear context: use this tool to obtain category tokens for browse_recipes, and warns not to hand-construct tokens. It also notes the tool's coverage limitation—tag-based categories are not included—but it does not explicitly name an alternative tool for those cases, leaving some routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scale_ingredientsRescale a list of ingredientsARead-onlyIdempotent
Rescale a list of French ingredient lines, offline. Give either 'factor', or 'from_servings' and 'to_servings' together. Each line comes back with what was done to it: 'scaled' when the arithmetic landed exactly, 'rounded' when the value had to move to stay something a kitchen can measure out, and 'unscaled' when the line carries no quantity at all. Nothing is converted between unit systems, and an approximate measure such as a pincée keeps its own size.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| factor | No | What to multiply the quantities by. Give this, or the two servings counts. | |
| ingredients | Yes | The lines to rescale, as the recipe wrote them. | |
| to_servings | No | How many it should serve. | |
| from_servings | No | How many the list was written for. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| notes | Yes | |
| factor | Yes | What the quantities were multiplied by. |
| ingredients | Yes | |
| scaled_count | Yes | Lines whose arithmetic landed exactly. |
| rounded_count | Yes | Lines whose value had to move. |
| unscaled_count | Yes | Lines carrying no quantity. |
TDQS
A4.2/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly, idempotent, and non-destructive annotations, the description discloses meaningful behavior: per-line outcome statuses ('scaled', 'rounded', 'unscaled'), the fact that no unit-system conversion happens, and that approximate measures keep their own size. This gives the agent a clear model of what the tool will and will not do.
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 compact and front-loaded: the main action is stated first, followed by essential parameter constraints and behavioral outcomes. Each sentence contributes information that is not already visible in the schema or annotations.
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?
For a pure transformation tool with rich annotations age and an output schema, the description covers the essential contextual pieces: input mode selection, result statuses, unit handling, and offline behavior. Nothing critical is missing for an agent to call it correctly.
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?
The input schema already describes each parameter, so the description does not need to compensate for coverage gaps. It adds real value by explaining the mutual-exclusion relationship between 'factor' and the two servings counts, and clarifies that servings must be supplied together.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (French ingredient lines) and a precise operation (rescale), plus the offline qualifier, which clearly sets it apart from the retrieval-oriented sibling tools. It does not explicitly name a competing sibling, so it stops short of the strongest possible sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives solid within-tool usage guidance by requiring either 'factor' or the servings-count pair, and it explains what will happen as a result. However, it provides no explicit guidance on when to choose this tool over the listed sibling tools, leaving tool-selection context implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_recipesSearch the recipesARead-onlyIdempotent
Search Supertoinette by a dish or an ingredient. Each row carries the identifier to read the recipe with get_recipe. The site publishes no total, so 'total_available' is null and 'last_page' says how far the results run. The categories it counts beside a search are returned as 'facets': pass one back as 'category' to narrow the search, spelled exactly as the site spells it. A category the site does not know is answered like a search that matched nothing, so a filter that finds nothing is dropped and the answer says so.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Which page of results to read, 1 by default. 'last_page' says how far they run. | |
| limit | No | Rows to render, 20 by default. The site serves at most 39 to a page, and 'rows_published' always states what the page held. | |
| query | Yes | A dish or an ingredient to look for, in French. | |
| category | No | Narrow the search to one category, taken from the 'facets' of a previous answer and spelled exactly as the site spells it. Never build one by hand: the site answers a wording it does not know with a page that reads as an absence. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | The page these rows were read from. |
| page | Yes | The page these rows were read from. |
| notes | Yes | |
| query | Yes | |
| facets | Yes | The categories the site counts inside this search. A recipe filed under two is counted by both, so these do not add up to the rows served. |
| source | Yes | |
| results | Yes | |
| category | Yes | The category the answer was narrowed to, or null for a search across all of them. |
| last_page | Yes | The highest page the site links to from this one. |
| result_count | Yes | Rows rendered here. |
| rows_published | Yes | Rows the page held, before any were rendered. |
| total_available | Yes | Supertoinette prints no total on a search page, so there is none to report. |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral detail beyond the annotations: the absence of 'total_available', the meaning of 'last_page', the behavior of 'facets', the exact spelling requirement for categories, and the dropped-filter behavior for unknown categories. This gives an agent realistic expectations about results and edge cases.
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 compact yet information-dense, opening with the core action and then covering essential edge cases without repetition or filler. Every sentence contributes to correct invocation or result interpretation.
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?
For a read-only search tool with a detailed output schemaaren, the description covers all non-obvious behavior: pagination boundaries, the meaning of null totals, facets, category case sensitivity, and the dropped-filter response. The agent has everything needed to call the tool correctly and interpret results.
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 coverage is 100%, so the baseline is 3. The description restates some of that context, particularly around 'category' and facets, but does not add entirely new parameter semantics beyond what the schema already documents. It is adequate but not an enhancement.
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 states a specific action ('Search Supertoinette') with a clear resource ('a dish or an ingredient') and links results to the get_recipe tool, making its purpose unmistakable. It is distinct from browse_recipes because it is explicitly a search by dish or ingredient.
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?
The description clearly establishes when to use the tool: when searching by dish or ingredient construction, and explains how to follow up with get_recipe. It does not explicitly name alternative tools or exclusion cases, but the contextual signals from sibling tool names make the intended use clear.
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.
5 tool updates
v1.1.0- Changed
browse_recipes8 fields changed- removed
Output schema / properties / results / items / properties / description / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / results / items / properties / description / 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 / title / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / title / typeAdded value: +[ + "string", + "null" +]
- Changed
get_recipe20 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 / category / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / category / 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 / 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" +] - removed
Output schema / properties / intro / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / intro / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / published_at / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / published_at / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / tags / items / properties / category / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / tags / items / properties / category / 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" +]
- Changed
get_wine_pairings1 field changed- changed
Output schema / properties / dish / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "dish": { - "description": "The site's own name for it.", - "type": "string" - }, - "id": { - "type": "string" - }, - "pairing_count": { - "maximum": 9007199254740991, - "minimum": -9007199254740991, - "type": "integer" - }, - "pairings": { - "items": { - "additionalProperties": false, - "properties": { - "rank": { - "description": "The site's own wording for how well it goes, such as 'Accord parfait'.", - "type": "string" - }, - "wine": { - "description": "The wine and whatever the site writes about it, as published.", - "type": "string" - } - }, - "required": [ - "rank", - "wine" - ], - "type": "object" - }, - "type": "array" - }, - "recipes": { - "description": "The recipes the site links beside the dish. Read one with get_recipe.", - "items": { - "additionalProperties": false, - "properties": { - "id": { - "type": "string" - }, - "title": { - "type": "string" - }, - "url": { - "type": "string" - } - }, - "required": [ - "id", - "title", - "url" - ], - "type": "object" - }, - "type": "array" - }, - "style": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "description": "The style of wine the site opens with. Null where it wrote none." - }, - "url": { - "type": "string" - } - }, - "required": [ - "id", - "dish", - "style", - "pairings", - "pairing_count", - "recipes", - "url" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "dish": { + "description": "The site's own name for it.", + "type": "string" + }, + "id": { + "type": "string" + }, + "pairing_count": { + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "pairings": { + "items": { + "additionalProperties": false, + "properties": { + "rank": { + "description": "The site's own wording for how well it goes, such as 'Accord parfait'.", + "type": "string" + }, + "wine": { + "description": "The wine and whatever the site writes about it, as published.", + "type": "string" + } + }, + "required": [ + "rank", + "wine" + ], + "type": "object" + }, + "type": "array" + }, + "recipes": { + "description": "The recipes the site links beside the dish. Read one with get_recipe.", + "items": { + "additionalProperties": false, + "properties": { + "id": { + "type": "string" + }, + "title": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "id", + "title", + "url" + ], + "type": "object" + }, + "type": "array" + }, + "style": { + "description": "The style of wine the site opens with. Null where it wrote none.", + "type": [ + "string", + "null" + ] + }, + "url": { + "type": "string" + } + }, + "required": [ + "id", + "dish", + "style", + "pairings", + "pairing_count", + "recipes", + "url" + ], + "type": "object" + }, + { + "type": "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_recipes6 fields changed- removed
Output schema / properties / category / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / category / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / results / items / properties / description / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / results / items / properties / description / 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" +]
6 tool updates
v1.0.1- First observed
browse_recipes - First observed
get_recipe - First observed
get_wine_pairings - First observed
list_categories - First observed
scale_ingredients - First observed
search_recipes
TDQS
A4.5/5.0
Scored across 6 tools
Disambiguation5/5
Each tool targets a clearly distinct action: listing categories, reading a single recipe, searching recipes, browsing by category, fetching wine pairings, and scaling ingredients. The only near overlap is search vs. browse, but their descriptions make the distinction clear.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern: list_categories, get_recipe, search_recipes, browse_recipes, get_wine_pairings, scale_ingredients. There is no mixing of styles or vague verbs.
Tool Count5/5
Six tools is well-scoped for a recipe retrieval and utility server. Each tool earns its place without redundancy or bloat.
Completeness4/5
The read-only recipe domain is well covered: category discovery, search, browsing, full recipe retrieval, and wine pairing data are all present. A minor gap is that not all recipe tag categories are directly listable without first reading a recipe, but the core workflow is complete.
Maintenance
ActivityMaintained
ResponsivenessUnresponsive
Related MCP Connectors
Spoonacular food API: recipes, nutrition, ingredients, meal plans. Free 150/day.
Search, save, organize, cook, and share recipes with any AI assistant.
Baking unit conversion (cups/grams/temp/recipe scaling). convert_amount, convert_temperature
- SpoonjoyOAuthapp.spoonjoy
Your personal recipe kitchen: save, fork, and cook recipes, build cookbooks, and shopping lists.
Related MCP Servers
- AlicenseAqualityBmaintenanceMCP server that searches French recipes from Marmiton, reads ingredients and steps, and rescales quantities to any number of servings without requiring an API key.63456 npmMIT
- AlicenseAqualityBmaintenanceSearch and read recipes from the English Wikibooks Cookbook, with tools to rescale ingredient lists to a target number of servings.4408 npmMIT
- AlicenseAqualityBmaintenanceAn MCP server that searches and reads recipes from multiple sources simultaneously, merges the results, and rescales ingredient quantities for any number of servings in French and English.491 npmMIT