What can you do with this server?

This server connects a chat client to the French cooking site Ptitchef, letting you discover, search, browse, read, and rescale recipes without an API key. * list_categories — Walk the site's ingredient-family and category tree to find valid category slugs and pages. * search_recipes — Find recipes by French dish or ingredient names, with ratings, counts, images, and category context. * browse_recipes — Page through a category or read standing lists: latest, top_rated, and most_viewed. * search_by_ingredients — Ask what can be cooked from 1–5 ingredients already on hand (e.g., courgettes, feta, mint). * get_recipe — Read a full recipe: ingredients, method steps, illustrated steps, times, nutrition, cost, author, ratings, FAQs, and translations; optionally rescale ingredients to a requested number of servings. * scale_ingredients — Rescale any French ingredient list (factor or from/to servings) without contacting the site. * get_recipe_translations — List the other languages a recipe was published in, with direct URLs.

How do I use mcp-ptitchef?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-ptitchef What are the main recipe categories?" 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.

en es ko zh

mcp-ptitchef

by smeet666

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

mcp-ptitchef

npm license MCP Registry Glama M8ven LobeHub Install in Cursor Install in VS Code

Ptitchef is a French cooking site where home cooks publish their recipes. Each one gives its ingredients, its steps, often photographed one by one, its preparation and cooking times, its cost, its nutrition figures and the ratings its readers left. The site files its recipes under a tree of ingredient families, and publishes many of them in several languages.

This server connects a chat client to that site. You can walk the tree of categories, search the recipes by dish or by ingredient, browse a category or one of the site's standing lists, ask what can be made from what is in the fridge, read one recipe with its ingredients rescaled to the number of people at your table, and find the other languages a recipe was published in. It needs no API key and no account.

Version française

Install

One-click install

Install in Cursor Install in VS Code

Claude Code

claude mcp add ptitchef -- npx -y mcp-ptitchef

Claude Desktop, Cursor, and any client using the standard config format

{
  "mcpServers": {
    "ptitchef": {
      "command": "npx",
      "args": ["-y", "mcp-ptitchef"]
    }
  }
}

Node 24 or later is required, and no environment variable has to be set.

With Docker

{
  "mcpServers": {
    "ptitchef": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "ghcr.io/smeet666/mcp-ptitchef:1.0.1"]
    }
  }
}

-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.ptitchef.com, and nothing else: no volume, no port, no credential.

Bundle, without npm

Download mcp-ptitchef-1.0.1.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: France BOAMP MCP

What you can ask

« Qu'est-ce que Ptitchef a comme recettes de chou kale ? »
"What can I cook with courgettes, feta and mint?"
"Read me that gratin for eight people."
"Show me the highest rated recipes on the site."
"Is that recipe published in Spanish too?"

Ptitchef is a French site, so its recipes are found in French. The ordinary path runs from a listing to a recipe: a row carries an id, and get_recipe takes that id.

Tools

Tool	What it does
`list_categories`	Walks the tree of ingredient families the site files under.
`search_recipes`	Finds recipes by dish or by ingredient.
`browse_recipes`	Reads a category page by page, or a standing list.
`search_by_ingredients`	Answers what can be made from what a cook already has.
`get_recipe`	Reads one recipe, rescaled to a number of servings on request.
`scale_ingredients`	Rescales any ingredient list, with no request to the site.
`get_recipe_translations`	Lists the other languages a recipe was published in.

Start at list_categories. The site gives you the right addresses, which saves building one by hand: an address built that way lands on the site's front page.

`list_categories`

Reads the tree the site files its recipes under. Called with no argument it returns the families; pass a family's slug back as family to read what it holds.

Argument	Type	Required	What it does
`family`	string, 1 to 80 characters	no	A family's slug, to read the categories under it.
`limit`	integer, 1 to 200, default `20`	no	Rows to serve.

In return: rows carrying slug, which comes back as family or as category; title in the site's own wording; url; description, which is null where the page carries none; and sample_children for the categories one level below.

`search_recipes`

Searches the recipes for a dish or an ingredient.

Argument	Type	Required	What it does
`query`	string, 1 to 120 characters	yes	A dish or an ingredient, in French.
`limit`	integer, 1 to 100, default `20`	no	Rows to serve.

In return: results, rows carrying id, title, url, image_url, rating, rating_count and review_count, a counter the page prints nothing for being null. The envelope says how the site answered: kind reads category when the answer came from a category page of its own, whose total_available counts that whole category, and free_text when the site answered on its own terms on a single page, where the total counts the rows served. Those two totals count different things. kind also reads guide for a topic the site wrote by hand, where rows carry a name and an address and no total exists. Alongside come result_count, rows_seen, page, single_page and url. A listing marked single_page whose total exceeds rows_seen has a remainder the site counts and does not serve.

`browse_recipes`

Reads a category page by page, or one of the site's standing lists.

Argument	Type	Required	What it does
`category`	string, 1 to 120 characters	no	A category slug, as `list_categories` published it.
`listing`	`latest`, `top_rated` or `most_viewed`	no	A standing list, read instead of a category.
`page`	integer, 1 to 1000	no	The page of a category to read. A standing list has one page.
`limit`	integer, 1 to 100, default `20`	no	Rows to serve.

In return: the envelope search_recipes returns, with kind reading category, standing or topic. page is the page the site served, which is the first one again when the page asked for is past the last.

`search_by_ingredients`

Answers what can be made from the ingredients a cook already has.

Argument	Type	Required	What it does
`ingredients`	array of 1 to 5 strings, 1 to 60 characters	yes	The ingredients on hand, in French.
`limit`	integer, 1 to 100, default `20`	no	Rows to serve.

In return: the envelope the other listings return, with kind reading fridge. The site matches on its own vocabulary, so an ingredient it writes differently narrows the answer rather than widening it.

`get_recipe`

Reads one recipe in full, and rescales its ingredients when a number of servings is given.

Argument	Type	Required	What it does
`id`	string, 1 to 300 characters	yes	The `id` of a row from a search or a listing.
`servings`	integer, 1 to 500	no	Rescale the ingredients to this many servings.

In return: title, url, description, image_url, category, cuisine, difficulty in the site's own wording, author, published, modified, rating, rating_count, review_count, prep_minutes, cook_minutes, total_minutes, nutrition as published for the serving size it names, estimated_cost, keywords, faq and translations, each null where the page states nothing. steps carries the method one line per step, and illustrated_steps the same steps with the photograph the site took of each. yield says what the recipe was written for and what it was rescaled to. Every ingredient carries scaling, which reads scaled, rounded or unscaled: read it before quoting a quantity, since rounded was moved to stay usable in a kitchen.

`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
`ingredients`	array of 1 to 100 strings, up to 300 chars	yes	The lines to rescale, in French.
`factor`	number, above 0 and up to 100	one of two	The multiplier to apply.
`from_servings`	number, above 0 and up to 500	one of two	How many servings the list is written for.
`to_servings`	number, above 0 and up to 500	one of two	How many servings are wanted.

Pass factor, or the from_servings and to_servings pair.

In return: the factor used, the rescaled ingredients in the shape get_recipe returns, and scaled_count, rounded_count and unscaled_count.

`get_recipe_translations`

Lists the other languages one recipe was published in, using the pairing the site publishes itself.

Argument	Type	Required	What it does
`id`	string, 1 to 300 characters	yes	The `id` of a row from a search or a listing.

In return: translations, each carrying the language tag the site publishes and the url of that version, with translation_count and the url of the French page they were read from.

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
`PTC_USER_AGENT`	the project identity	Names your application to the site, with an address where a person can be reached.
`PTC_MIN_INTERVAL_MS`	`1500`	Gap between two requests, from 1000 to 60000.
`PTC_TIMEOUT_MS`	`20000`	Deadline for one request, from 1000 to 120000.
`PTC_MAX_RETRIES`	`3`	Attempts after a transient failure, from 0 to 8.
`PTC_CACHE_TTL_MS`	`900000`	How long a page stays in memory, from 0 to 86400000.
`PTC_CACHE_MAX_ENTRIES`	`200`	Pages held in memory at once, from 1 to 5000.
`PTC_MAX_BODY_BYTES`	`8000000`	The largest response read whole, from 100000 to 64000000.
`PTC_BUDGET_MS`	`60000`	The time one read owes an answer inside, retries and waits included, from 5000 to 600000.
`PTC_LOG_LEVEL`	`error`	`silent`, `error`, `info` or `debug`, written to stderr.

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
`not_found`	The site answered, and holds no such recipe or page.	Check the slug with `list_categories`, or the id with a search.
`invalid_input`	The arguments were refused before any request went out.	Read the message, which names the argument.
`rate_limited`	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.
`parse_failure`	The page loaded and the expected content was absent.	Report it at the issue tracker.
`network_error`	The request did not complete.	Try again shortly.
`timeout`	The request passed its deadline or its budget.	Raise `PTC_TIMEOUT_MS` or `PTC_BUDGET_MS`, or ask for fewer rows.

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 { PtitchefClient } from "mcp-ptitchef/client";

const client = new PtitchefClient();
const { data, cached } = await client.listCategories();
console.log(data.results.length, cached);

listCategories, searchRecipes, browseRecipes, searchByIngredients and getRecipe each answer { data, cached }, and throw an error carrying one of the six codes. The floor between two requests holds here as well.

Pacing and attribution

Requests go out one at a time with at least a second and a half between them, and the floor of one second 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 categories belong to Ptitchef and to the cooks who wrote them.

This MCP server is an unofficial project, with no affiliation to Ptitchef.

Privacy

This server collects nothing about you and sends nothing to its author. It runs on your machine, contacts www.ptitchef.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 check

Tests 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 Ptitchef and to their authors.

mcp-ptitchef (français)

English version

Ptitchef est un site de cuisine français où des cuisiniers publient leurs recettes. Chacune donne ses ingrédients, ses étapes, souvent photographiées une à une, ses temps de préparation et de cuisson, son coût, ses valeurs nutritionnelles et les notes laissées par ses lecteurs. Le site classe ses recettes dans un arbre de familles d'ingrédients, et en publie beaucoup en plusieurs langues.

Ce serveur relie un client de conversation à ce site. On peut parcourir l'arbre des catégories, chercher des recettes par plat ou par ingrédient, lire une catégorie ou l'une des listes permanentes du site, demander ce qu'on peut faire avec ce qu'il y a dans le frigo, lire une recette avec ses ingrédients adaptés au nombre de convives, et trouver les autres langues dans lesquelles une recette a été publiée. Aucune clé d'API, aucun compte.

Installation

Installation en un clic

Install in Cursor Install in VS Code

Claude Code

claude mcp add ptitchef -- npx -y mcp-ptitchef

Claude Desktop, Cursor, et tout client au format de configuration standard

{
  "mcpServers": {
    "ptitchef": {
      "command": "npx",
      "args": ["-y", "mcp-ptitchef"]
    }
  }
}

Node 24 ou plus récent est nécessaire, et aucune variable d'environnement n'est à renseigner.

Avec Docker

{
  "mcpServers": {
    "ptitchef": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "ghcr.io/smeet666/mcp-ptitchef:1.0.1"]
    }
  }
}

-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.ptitchef.com, et de rien d'autre : aucun volume, aucun port, aucun identifiant.

Bundle, sans npm

Téléchargez mcp-ptitchef-1.0.1.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

« Qu'est-ce que Ptitchef a comme recettes de chou kale ? »
« Qu'est-ce que je peux cuisiner avec des courgettes, de la feta et de la menthe ? »
« Lis-moi ce gratin pour huit personnes. »
« Montre-moi les recettes les mieux notées du site. »
« Cette recette existe-t-elle aussi en espagnol ? »

Ptitchef est un site français, donc ses recettes se trouvent en français. Le chemin ordinaire va d'une liste à une recette : une ligne porte un id, et get_recipe reprend cet identifiant.

Les outils

Outil	Ce qu'il fait
`list_categories`	Parcourt l'arbre des familles d'ingrédients du site.
`search_recipes`	Trouve des recettes par plat ou par ingrédient.
`browse_recipes`	Lit une catégorie page par page, ou une liste permanente.
`search_by_ingredients`	Répond avec ce qu'on peut faire de ce qu'un cuisinier a déjà.
`get_recipe`	Lit une recette, adaptée à un nombre de parts sur demande.
`scale_ingredients`	Adapte n'importe quelle liste d'ingrédients, sans requête au site.
`get_recipe_translations`	Liste les autres langues où une recette a été publiée.

Commencez par list_categories. Le site vous donne les adresses correctes, ce qui évite d'en construire une à la main : une adresse construite ainsi mène à la page d'accueil du site.

`list_categories`

Lit l'arbre sous lequel le site classe ses recettes. Appelé sans argument, il rend les familles ; redonnez le slug d'une famille en family pour lire ce qu'elle contient.

Argument	Type	Requis	Ce qu'il fait
`family`	chaîne, 1 à 80 caractères	non	Le slug d'une famille, pour lire les catégories dessous.
`limit`	entier, 1 à 200, défaut `20`	non	Lignes à servir.

En retour : des lignes portant slug, qui se redonne en family ou en category ; title dans les termes du site ; url ; description, null là où la page n'en porte pas ; et sample_children pour les catégories du niveau inférieur.

`search_recipes`

Cherche des recettes par plat ou par ingrédient.

Argument	Type	Requis	Ce qu'il fait
`query`	chaîne, 1 à 120 caractères	oui	Un plat ou un ingrédient, en français.
`limit`	entier, 1 à 100, défaut `20`	non	Lignes à servir.

En retour : results, des lignes portant id, title, url, image_url, rating, rating_count et review_count, un compteur que la page n'imprime pas valant null. L'enveloppe dit comment le site a répondu : kind vaut category quand la réponse vient d'une page de catégorie, dont le total_available compte toute la catégorie, et free_text quand le site a répondu à sa façon sur une seule page, où le total compte les lignes servies. Ces deux totaux comptent des choses différentes. kind vaut aussi guide pour un dossier que le site a écrit à la main, où les lignes portent un nom et une adresse sans qu'aucun total existe. Viennent aussi result_count, rows_seen, page, single_page et url. Une liste marquée single_page dont le total dépasse rows_seen a un reste que le site compte et ne sert pas.

`browse_recipes`

Lit une catégorie page par page, ou l'une des listes permanentes du site.

Argument	Type	Requis	Ce qu'il fait
`category`	chaîne, 1 à 120 caractères	non	Un slug de catégorie, publié par `list_categories`.
`listing`	`latest`, `top_rated` ou `most_viewed`	non	Une liste permanente, lue à la place d'une catégorie.
`page`	entier, 1 à 1000	non	La page de catégorie à lire. Une liste permanente n'en a qu'une.
`limit`	entier, 1 à 100, défaut `20`	non	Lignes à servir.

En retour : l'enveloppe que rend search_recipes, avec kind valant category, standing ou topic. page est la page que le site a servie, qui est la première de nouveau quand la page demandée dépasse la dernière.

`search_by_ingredients`

Répond avec ce qu'on peut faire des ingrédients qu'un cuisinier a déjà.

Argument	Type	Requis	Ce qu'il fait
`ingredients`	tableau de 1 à 5 chaînes, 1 à 60 caractères	oui	Les ingrédients sous la main, en français.
`limit`	entier, 1 à 100, défaut `20`	non	Lignes à servir.

En retour : l'enveloppe des autres listes, avec kind valant fridge. Le site fait correspondre son propre vocabulaire, donc un ingrédient qu'il écrit autrement resserre la réponse au lieu de l'élargir.

`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
`id`	chaîne, 1 à 300 caractères	oui	L'`id` d'une ligne de recherche ou de liste.
`servings`	entier, 1 à 500	non	Adapte les ingrédients à ce nombre de parts.

En retour : title, url, description, image_url, category, cuisine, difficulty dans les termes du site, author, published, modified, rating, rating_count, review_count, prep_minutes, cook_minutes, total_minutes, nutrition telle que publiée pour la portion qu'elle nomme, estimated_cost, keywords, faq et translations, chacun null là où la page n'indique rien. steps porte la méthode une ligne par étape, et illustrated_steps les mêmes étapes avec la photographie que le site a prise de chacune. yield dit pour quoi la recette est écrite et vers quoi elle a été adaptée. Chaque ingrédient porte scaling, qui vaut scaled, rounded ou unscaled : lisez-le avant de citer une quantité, rounded ayant été déplacée pour rester utilisable en cuisine.

`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
`ingredients`	tableau de 1 à 100 chaînes, jusqu'à 300 caractères	oui	Les lignes à adapter, en français.
`factor`	nombre, au-delà de 0 jusqu'à 100	l'un des deux	Le multiplicateur à appliquer.
`from_servings`	nombre, au-delà de 0 jusqu'à 500	l'un des deux	Le nombre de parts de la liste d'origine.
`to_servings`	nombre, au-delà de 0 jusqu'à 500	l'un des deux	Le nombre de parts voulu.

Passez factor, ou le couple from_servings et to_servings.

En retour : le factor employé, les ingredients adaptés dans la forme que rend get_recipe, et scaled_count, rounded_count et unscaled_count.

`get_recipe_translations`

Liste les autres langues dans lesquelles une recette a été publiée, d'après l'appariement que le site publie lui-même.

Argument	Type	Requis	Ce qu'il fait
`id`	chaîne, 1 à 300 caractères	oui	L'`id` d'une ligne de recherche ou de liste.

En retour : translations, chacune portant l'étiquette language que le site publie et l'url de cette version, avec translation_count et l'url de la page française d'où elles ont été lues.

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
`PTC_USER_AGENT`	l'identité du projet	Nomme votre application auprès du site, avec une adresse où joindre une personne.
`PTC_MIN_INTERVAL_MS`	`1500`	Écart entre deux requêtes, de 1000 à 60000.
`PTC_TIMEOUT_MS`	`20000`	Délai d'une requête, de 1000 à 120000.
`PTC_MAX_RETRIES`	`3`	Tentatives après un échec passager, de 0 à 8.
`PTC_CACHE_TTL_MS`	`900000`	Durée pendant laquelle une page reste en mémoire, de 0 à 86400000.
`PTC_CACHE_MAX_ENTRIES`	`200`	Pages gardées en mémoire à la fois, de 1 à 5000.
`PTC_MAX_BODY_BYTES`	`8000000`	La plus grosse réponse lue en entier, de 100000 à 64000000.
`PTC_BUDGET_MS`	`60000`	Le temps dans lequel une lecture doit rendre une réponse, reprises et attentes comprises, de 5000 à 600000.
`PTC_LOG_LEVEL`	`error`	`silent`, `error`, `info` ou `debug`, écrit sur la sortie d'erreur.

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
`not_found`	Le site a répondu, et n'a ni cette recette ni cette page.	Vérifiez le slug avec `list_categories`, ou l'identifiant avec une recherche.
`invalid_input`	Les arguments ont été refusés avant toute requête.	Lisez le message, qui nomme l'argument.
`rate_limited`	Le site demande à ce client de ralentir.	Attendez les secondes indiquées et rappelez avec les mêmes arguments. La recette est toujours là.
`parse_failure`	La page a chargé et le contenu attendu est absent.	Signalez-le sur le suivi d'incidents.
`network_error`	La requête n'a pas abouti.	Réessayez sous peu.
`timeout`	La requête a dépassé son délai ou son budget.	Augmentez `PTC_TIMEOUT_MS` ou `PTC_BUDGET_MS`, ou demandez moins de lignes.

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 { PtitchefClient } from "mcp-ptitchef/client";

const client = new PtitchefClient();
const { data, cached } = await client.listCategories();
console.log(data.results.length, cached);

listCategories, searchRecipes, browseRecipes, searchByIngredients et getRecipe répondent chacun { data, cached }, et lèvent une erreur portant un des six codes. Le plancher entre deux requêtes tient également ici.

Rythme et attribution

Les requêtes partent une à une avec au moins une seconde et demie entre elles, et le plancher d'une seconde 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 catégories appartiennent à Ptitchef et aux cuisiniers qui les ont écrites.

Ce MCP est un projet non officiel, sans affiliation à Ptitchef.

Confidentialité

Ce serveur ne collecte rien sur vous et n'envoie rien à son auteur. Il tourne sur votre machine, ne joint que www.ptitchef.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 check

Les 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 à Ptitchef et à leurs auteurs.

Available Tools

7 tools

browse_recipesBrowse a category or a standing listA

Read-onlyIdempotent

Read the recipes under one category of Ptitchef, page by page, or one of the lists the site keeps standing. Pass 'category' with a slug from list_categories or from a search's 'topic_slug', or pass 'listing' for one of: latest, top_rated, most_viewed. Never build a category slug by hand: the site writes them freely and answers an address it does not hold by serving another page. The page in the answer is the one the site served, which is the first page again when the page asked for is past the last one.

ParametersJSON Schema

Name	Required	Description
`page`	No	The page of a category to read. A standing list has one page only.
`limit`	No	Rows to render, 20 by default.
`listing`	No	One of the site's standing lists, read instead of a category.
`category`	No	A category slug: one from list_categories whose 'is_family' is false, or the 'topic_slug' a search answered with. A family's slug belongs to list_categories instead.

Output Schema

ParametersJSON Schema

Name	Required	Description
`url`	Yes	The address the listing was read from.
`kind`	Yes	How the listing came to be, which decides what its total counts. 'topic' means the site answered a search from a page of its own; 'free_text' means it answered on its own terms.
`page`	Yes	The page that was read, which is the one the site served.
`asked`	Yes	What was asked for: a search, a category, or a list of ingredients. 'query' carries the same value under the name every source of recipes publishes it in.
`notes`	Yes	What qualifies this answer: what its total counts, what it left out, and where the site answered from an address other than the one asked for. Read these before quoting a figure.
`query`	Yes	What was asked for, under the name a search publishes it in.
`title`	Yes	The site's own heading for the listing.
`folded`	Yes	Rows naming a recipe already held. A guide lists one recipe under two headings where it belongs to both; such a row is counted in 'rows_seen' and rendered once.
`source`	Yes	The site this answer was read from. Credit it when showing a row.
`results`	Yes
`rows_seen`	Yes	Rows the site served on this page, before any were set aside.
`topic_slug`	Yes	The category page this listing was served from. Pass it to browse_recipes as 'category' to read the topic's further pages, and its total where this answer carries none.
`single_page`	Yes	True when the site serves this listing on one page and offers no further one.
`result_count`	Yes	Rows rendered here.
`total_available`	Yes	Recipes the site says this listing holds. Null when it published no figure.

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the readOnly/idempotent/non-destructive annotations, the description discloses a non-obvious behavioral quirk: the site serves another page when it does not hold the address, and pages past the last one silently return the first page. This is exactly the kind of edge-case behavior an agent needs before invoking the tool.

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?

Four sentences, and each earns its place: the core operation, the two input modes, the slug-authoring warning, and the pagination fallback behavior. The main purpose is front-loaded and the caveats are placed after the primary semantics.

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 paginated browsing tool with rich schema descriptions and an output schema, the definition covers the dangerous non-obvious behaviors that could otherwise cause an agent to misread results: slug tolerance and page wrapping. Nothing essential for correct invocation is missing.

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

Parameters4/5

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

The schema already documents all parameters at 100% coverage, but the description adds usable guidance about where category slugs come from, that listing values are mutually exclusive with category, and the warning against hand-built slugs. It reinforces but does not deeply extend the schema's parameter descriptions, so a 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Read the recipes under one category of Ptitchef, page by page, or one of the lists the site keeps standing.' It clearly states both operating modes and distinguishes this from siblings like list_categories (which returns categories) and search_recipes (which returns search results).

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 explicit input-selection rules: pass 'category' with a slug from list_categories or a search's 'topic_slug', or pass 'listing' with one of the named standing lists. It also gives a strong exclusion: never hand-build a category slug. It does not explicitly name the sibling tools to use instead, but the context is clear.

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

get_recipeRead one recipeA

Read-onlyIdempotent

Read one Ptitchef recipe: its ingredients, method, times, rating, nutrition and the cost the site estimates for it. Pass the 'id' of a row from search_recipes, browse_recipes or search_by_ingredients. Give 'servings' to rescale the ingredients, and read each line's 'scaling' before quoting a quantity: 'scaled' is exact arithmetic, 'rounded' was moved to stay usable, and 'unscaled' carries nothing that could be multiplied. A time or a figure the site publishes none of comes back null, never zero.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	The 'id' of a row from a search or a listing, which is the recipe's own page path.
`servings`	No	Rescale the ingredients to this many servings. Left out, the ingredients come back as published.

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes
`faq`	Yes
`url`	Yes	The public page. Show this when citing the recipe.
`notes`	Yes	What qualifies this answer: what the arithmetic did, what it could not do, and what the site states rather than this server. Read these before quoting a quantity or a cost.
`steps`	Yes	The method, one line per step, in the shape every source of recipes publishes it in. 'illustrated_steps' carries the same lines beside the photograph the site took of each.
`title`	Yes
`yield`	Yes
`author`	Yes
`rating`	Yes	1 to 5, as the site states it.
`source`	Yes	The site this recipe was read from. Credit it when showing it.
`cuisine`	Yes
`category`	Yes
`keywords`	Yes
`modified`	Yes
`image_url`	Yes
`nutrition`	Yes	As published, per the serving size it names.
`published`	Yes
`author_url`	Yes
`difficulty`	Yes	The site's own wording, such as 'facile'.
`attribution`	Yes
`description`	Yes
`ingredients`	Yes	The lines as published where no servings were asked for, in which case 'yield.factor' is null and each line's 'scaling' describes no arithmetic. Pass 'servings' to rescale them.
`cook_minutes`	Yes
`prep_minutes`	Yes
`rating_count`	Yes
`review_count`	Yes
`translations`	Yes	The other languages this recipe was published in, which get_recipe_translations answers on its own for a caller who wants nothing else.
`total_minutes`	Yes
`estimated_cost`	Yes	What the site estimates the ingredients cost, with the currency it names. Repeated as published: it is the site's figure and readers of the site dispute it.
`illustrated_steps`	Yes
`steps_are_one_block`	Yes	True when the site published its method as one block of prose, so the single step above is that block rather than the first of several.

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already cover read-only, open-world, idempotent, and non-destructive behavior. The description adds valuable behavioral detail beyond that: it explains the 'scaling' field's values ('scaled', 'rounded', 'unscaled') and their meaning for quoting quantities, and states that absent site figures come back null, never zero. No contradiction with annotations.

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?

Four sentences, each earning its place: scope, id sourcing, servings, and output semantics. It is dense but front-loaded with the core purpose, and no sentence is filler.

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?

With an output schema present and annotations covering the safety profile, the description provides enough context for correct invocation. It handles id provenance, optional servings, scaling nuances, and null semantics; minor omissions like invalid-id behavior are not critical.

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

Parameters4/5

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

Schema coverage is 100%, so the schema already documents both parameters. The description adds value by specifying that valid 'id' values come from rows of three sibling tools and clarifies that 'servings' rescales ingredients, echoing the schema in more actionable terms.

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'), a unique resource ('one Ptitchef recipe'), and enumerates what is returned (ingredients, method, times, rating, nutrition, cost). It also differentiates from search siblings by instructing the agent to pass an id from search_recipes, browse_recipes, or search_by_ingredients.

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 clear context: use with an id coming from the three listed search tools, and optionally pass servings to rescale. It names the upstream tools that produce valid ids, but doesn't explicitly state when not to use it (e.g., when scale_ingredients might be more appropriate), so it stops short of full exclusion guidance.

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

get_recipe_translationsFind a recipe in the other languages it was published inA

Read-onlyIdempotent

List the other languages a Ptitchef recipe was published in, with the page of each. get_recipe already carries this list under 'translations', so call this one only where the rest of the recipe is not wanted. Pass the 'id' of a row from a search or a listing. The pairing is the site's own: each page names its counterparts, and this repeats those names rather than matching titles. How many there are belongs to the recipe: a recent one names more than twenty, from German to Hindi, and an older one names none. An empty list is what the site published, and the read succeeded.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	The 'id' of a row from a search or a listing, which is the recipe's own page path.

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes
`url`	Yes	The French page these counterparts were read from.
`notes`	Yes
`title`	Yes
`source`	Yes
`translations`	Yes
`translation_count`	Yes

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already indicate read-only, idempotent, open-world, and non-destructive behavior. The description adds meaningful nuanced behavior: the translation pairing is site-defined and repeated rather than title-matched, the count varies by recipe, and an empty list still means the read succeeded. This goes well beyond the annotation hints.

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 front-loaded with the core purpose and is not padded. A few repeated details from the schema and the illustrative language examples add length, but each sentence contributes useful operational or interpretive context for an agent.

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 single-parameter read tool with an output schema and strong annotations, the description is complete: it explains when to use this tool instead of get_recipe, how to source the id, what the result represents, how size varies, and how to interpret an empty list.

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%, and the schema already explains that 'id' is 'The id of a row from a search or a listing, which is the recipe's own page path.' The description repeats this same guidance without adding substantial new parameter semantics, so the baseline of 3 is appropriate.

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?

Description names a specific verb and resource: 'List the other languages a Ptitchef recipe was published in, with the page of each.' It explicitly contrasts with the sibling get_recipe, which already contains this list, so an agent can immediately distinguish this tool from the main recipe-fetching tool.

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

Usage Guidelines5/5

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

The description gives a clear when-to-use rule: call this only when the rest of the recipe is not wanted, because get_recipe already carries the translations list. It also tells the agent exactly what input to pass: the 'id' of a row from a search or listing.

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 byA

Read-onlyIdempotent

List the categories Ptitchef browses its recipes by. Called without arguments it returns the families of ingredients; pass a family's slug as 'family' to list the categories it holds. Read this before building an address by hand: the site writes its slugs freely, so the same vegetable appears as 'chou-kale' on one line and as 'recette-de-petits-pois' on the next, and a slug that was guessed lands on a page the site does not hold. Each entry carries the slug to pass back and the page to open.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Entries to render, 20 by default and 200 at most. A level holding more than this says so, and 'categories_published' always states what the page listed.
`family`	No	The slug of a family to open, taken from a previous call. Leave it out to read the families themselves, which is where the tree starts.

Output Schema

ParametersJSON Schema

Name	Required	Description
`url`	Yes	The page these categories were read from.
`notes`	Yes
`family`	Yes	The family that was opened, or null for the root.
`source`	Yes
`categories`	Yes
`family_title`	Yes	The site's own heading for this level. Null when the page carries none.
`category_count`	Yes	Entries rendered here.
`categories_published`	Yes	Entries the page listed, before any were rendered.

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already establish that this is read-only, idempotent, non-destructive, and open-world. The description adds valuable behavioral context beyond those annotations by warning that slugs are written freely by the site, that guessed slugs land on non-existent pages, and that entries carry the slug to pass back. This directly addresses the open-world nature of the catalog and prevents a common failure mode.

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 core action and the two-mode behavior appear first, followed by a necessary warning about slug instability. Every sentence contributes either to correct invocation or to avoiding an error, with no filler or repetition of schema content.

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 tool's two-level hierarchy, optional parameters, rich annotations, and existing output schema, the description covers everything an agent needs: how to start, how to descend, and why slug guessing is unsafe. Pagination and return details are already handled by the schema and output schema, so nothing essential is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema fully documents 'limit' and 'family.' The description reinforces that 'family' should come from a previous call and that omitting it reads the families, but it does not add meaning significantly beyond the schema. Baseline 3 is appropriate because the schema carries the parameter documentation burden.

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 and resource: 'List the categories Ptitchef browses its recipes by.' It also clarifies the hierarchical relationship between families of ingredients and categories, which separates it from sibling tools like search_recipes, browse_recipes, and get_recipe. The two-call pattern (no argument for families, family slug for categories) makes 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 gives explicit instructions for both usage modes: called without arguments it returns families, and passing a family's slug as 'family' returns its categories. It also warns against hand-building slugs. It does not explicitly name sibling alternatives or state when to prefer this tool over search/browse tools, but the context is clear enough for an agent to select it for category-tree navigation.

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

scale_ingredientsRescale an ingredient listA

Read-onlyIdempotent

Rescale a list of ingredient lines to a different number of servings, without contacting any website. Give either 'factor' directly, or 'from_servings' and 'to_servings' and the factor is computed. Works on any French ingredient list, whatever its source, so it also serves a recipe pasted in by hand. Quantities in grams or millilitres are multiplied and rounded to readable values; a countable thing lands on a half when half of one can be poured, weighed or cut, as a boîte, a sachet, a feuille de gélatine or a cuillère can, and on a whole one when it cannot, as an oeuf, a jaune or a blanc; approximate measures such as a pinch or a handful have their count multiplied in whole units and stay in their own vocabulary. A line writing an article where a digit would go, as in 'un bouchon de rhum' or 'une pincée de sel', is read as one of that measure. Lines carrying no quantity are returned untouched and flagged. Prefer this over doing the arithmetic yourself.

ParametersJSON Schema

Name	Required	Description
`factor`	No	Multiplier to apply. Use this or the from/to pair.
`ingredients`	Yes	Ingredient lines, for example ['200 g de farine', '3 oeufs', 'sel'].
`to_servings`	No	How many servings are wanted.
`from_servings`	No	How many servings the list is written for.

Output Schema

ParametersJSON Schema

Name	Required	Description
`notes`	Yes
`factor`	Yes
`ingredients`	Yes
`scaled_count`	Yes
`rounded_count`	Yes	Lines whose value rounding moved away from the exact product, not lines that could have been rounded.
`unscaled_count`	Yes

TDQS

A4.6/5.0

Behavior5/5

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

The annotations already declare readOnly, idempotent, and non-destructive behavior, but the description goes far beyond them: it explains rounding to readable values, the half/whole rounding rule based on countable items, treatment of approximate measures, parsing of articles as one unit, and that unquantified lines are returned untouched and flagged. This is rich behavioral disclosure with no contradiction to 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?

The opening sentence front-loads the core purpose and the no-network constraint. The following sentences pack dense but relevant detail: parameter alternatives, French-list applicability, rounding rules with concrete examples, edge-case handling, and a closing usage preference. Every clause earns its place; there is no filler.

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?

Given the tool's complexity, the description covers domain scope, parameter alternatives, rounding rules, approximate measures, and unquantified lines. An output schema exists, so return-value details are not required. The only notable omission is the fallback or error behavior when no scale parameter is provided, since the schema does not enforce one of factor/from_servings/to_servings.

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 schema already describes every parameter, so the baseline is 3. The description adds meaning by explaining the relationship between factor and from_servings/to_servings, stating that the factor is computed from the serving pair. It also gives concrete ingredient-line examples. A minor gap is that it does not explicitly state what happens if neither factor nor the from/to pair is supplied, though the schema only requires ingredients.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Rescale a list of ingredient lines to a different number of servings,' and adds the key constraint 'without contacting any website.' This clearly distinguishes it from sibling recipe browsing and search tools, which focus on finding or retrieving recipes rather than transforming ingredient lines.

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

Usage Guidelines4/5

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

Gives clear context: it works on any French ingredient list, including pasted recipes, and explicitly says 'Prefer this over doing the arithmetic yourself.' It does not name a competing sibling tool or state explicit exclusions, but no sibling targets the same operation, so the guidance is adequate.

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

search_by_ingredientsFind recipes from the ingredients a cook hasA

Read-onlyIdempotent

Find Ptitchef recipes from the ingredients a cook already has. Give one to 5 ingredients in French, as a cook would name them ("poulet", "citron"). The site counts every recipe it finds and serves one page of them, so 'total_available' can be far larger than the rows returned, and the rest cannot be reached. A longer list than the site's own form reads is refused rather than sent and silently cut.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Rows to render, 20 by default.
`ingredients`	Yes	One to 5 ingredients, in French. The site reads no more than that.

Output Schema

ParametersJSON Schema

Name	Required	Description
`url`	Yes	The address the listing was read from.
`kind`	Yes	How the listing came to be, which decides what its total counts. 'topic' means the site answered a search from a page of its own; 'free_text' means it answered on its own terms.
`page`	Yes	The page that was read, which is the one the site served.
`asked`	Yes	What was asked for: a search, a category, or a list of ingredients. 'query' carries the same value under the name every source of recipes publishes it in.
`notes`	Yes	What qualifies this answer: what its total counts, what it left out, and where the site answered from an address other than the one asked for. Read these before quoting a figure.
`query`	Yes	What was asked for, under the name a search publishes it in.
`title`	Yes	The site's own heading for the listing.
`folded`	Yes	Rows naming a recipe already held. A guide lists one recipe under two headings where it belongs to both; such a row is counted in 'rows_seen' and rendered once.
`source`	Yes	The site this answer was read from. Credit it when showing a row.
`results`	Yes
`rows_seen`	Yes	Rows the site served on this page, before any were set aside.
`topic_slug`	Yes	The category page this listing was served from. Pass it to browse_recipes as 'category' to read the topic's further pages, and its total where this answer carries none.
`single_page`	Yes	True when the site serves this listing on one page and offers no further one.
`result_count`	Yes	Rows rendered here.
`total_available`	Yes	Recipes the site says this listing holds. Null when it published no figure.

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the readOnlyHint, openWorldHint, and idempotentHint annotations, it discloses non-obvious behaviors: the site counts all matches but serves only one page, the rest cannot be reached, and an over-long ingredient list is refused rather than silently truncated. This is exactly the kind of behavioral context annotations do not capture.

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 short sentences with the purpose first, then instructions, then boundary behaviors. Every sentence earns its place and there is no filler or repetition of annotation data.

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 rich annotations and output schema, the description covers everything an agent needs to invoke it correctly: ingredient count, language, refusal behavior, and pagination limitations. The only minor gap is not explicitly routing to sibling search_recipes, but the ingredient-based purpose makes that choice obvious.

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?

The input schema already has 100% coverage, including the French requirement, one-to-five item bounds, and per-string length limits. The description adds helpful cook-friendly examples, but it largely restates the schema rather than adding deeper semantic meaning, so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb-resource pair ('Find Ptitchef recipes') and narrows the scope to ingredients a cook already has, which distinguishes it from sibling search_recipes, browse_recipes, and list_categories. It also clarifies the input language and gives examples, making the tool's identity unmistakable.

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 actionable usage instructions: one to five ingredients, in French, using natural cook phrasing with examples. It doesn't explicitly say when not to use this tool or name an alternative, so it stops short of a 5, but the context is clear enough for an agent to select it appropriately.

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

search_recipesSearch recipesA

Read-onlyIdempotent

Search recipes on Ptitchef by dish or ingredient. The site answers in one of two ways and the answer says which: it either sends the search to a category page of its own, whose total counts what that category holds, or it answers on its own terms on a single page whose total is the number of rows served. When a category answered, 'topic_slug' names it and browse_recipes reads its further pages. Some topics come back as a guide the site wrote instead, grouped under headings of its own and carrying no total; browse_recipes on the same 'topic_slug' reads their full listing. A search the site matched nothing for comes back with no row and a total of zero, which is an absence the site stated.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Rows to render, 20 by default. 'rows_seen' states what the page served.
`query`	Yes	A dish or an ingredient, in French, as a reader of the site would type it.

Output Schema

ParametersJSON Schema

Name	Required	Description
`url`	Yes	The address the listing was read from.
`kind`	Yes	How the listing came to be, which decides what its total counts. 'topic' means the site answered a search from a page of its own; 'free_text' means it answered on its own terms.
`page`	Yes	The page that was read, which is the one the site served.
`asked`	Yes	What was asked for: a search, a category, or a list of ingredients. 'query' carries the same value under the name every source of recipes publishes it in.
`notes`	Yes	What qualifies this answer: what its total counts, what it left out, and where the site answered from an address other than the one asked for. Read these before quoting a figure.
`query`	Yes	What was asked for, under the name a search publishes it in.
`title`	Yes	The site's own heading for the listing.
`folded`	Yes	Rows naming a recipe already held. A guide lists one recipe under two headings where it belongs to both; such a row is counted in 'rows_seen' and rendered once.
`source`	Yes	The site this answer was read from. Credit it when showing a row.
`results`	Yes
`rows_seen`	Yes	Rows the site served on this page, before any were set aside.
`topic_slug`	Yes	The category page this listing was served from. Pass it to browse_recipes as 'category' to read the topic's further pages, and its total where this answer carries none.
`single_page`	Yes	True when the site serves this listing on one page and offers no further one.
`result_count`	Yes	Rows rendered here.
`total_available`	Yes	Recipes the site says this listing holds. Null when it published no figure.

TDQS

A4/5.0

Behavior5/5

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

The description discloses a wealth of behavioral detail far beyond what annotations provide. It explains the two distinct response modes (category pages vs. single pages), the meaning of the total (category count vs. row count), the existence of topic_slug, the guide case with no total, and the zero-result case as an explicit absence. This is precisely the kind of non-obvious behavior an agent needs to know before calling the tool.

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

Conciseness2/5

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

While the purpose is front-loaded in the opening sentence, the remainder is a long, winding explanation of response behavior packed into a single run-on paragraph. It lacks clear structure and could be shortened or bullet-pointed. The complexity is high, but the description is not concise; several sentences could be consolidated without losing information. This makes it harder for an agent to quickly extract the key points.

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 search tool with rich behavioral nuances, the description covers all essential aspects: response variants, total semantics, topic_slug usage, guides, and the no-result case. It also routes to browse_recipes for pagination. Since an output schema exists, the description need not explain return values, and it already explains the meaning of fields like rows_seen and total as they appear in responses. No critical missing context is apparent.

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?

The input schema already covers both parameters with clear descriptions (query in French, limit with default and meaning of rows_seen). The description adds no additional parameter-specific meaning, which is acceptable given 100% schema coverage. Baseline 3 is appropriate; the description does not need to repeat schema content.

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 first sentence clearly states a specific verb and resource: 'Search recipes on Ptitchef by dish or ingredient.' It also distinguishes itself from the sibling 'browse_recipes' by explaining that browse_recipes reads further pages of a category topic. This gives an agent a precise initial understanding of what the tool does and how it differs from a closely related tool.

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?

The description provides explicit guidance on when to follow up with 'browse_recipes' (when a category answers or a guide is returned), which is a form of usage routing. However, it never mentions the alternative 'search_by_ingredients' or states when to choose this tool over it. It also does not explicitly state when NOT to use search_recipes, so the guidance is partial and relies on inference.

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.

7 tool updatesv1.0.0Aug 28, 2026
- First observedbrowse_recipes
- First observedget_recipe
- First observedget_recipe_translations
- First observedlist_categories
- First observedscale_ingredients
- First observedsearch_by_ingredients
- First observedsearch_recipes

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.4/5.0

Scored 2026-08-28 01:20 across 7 tools

Disambiguation4/5

Each tool targets a distinct action—listing, searching, browsing, reading, scaling, translating—but search_recipes and search_by_ingredients overlap conceptually, and get_recipe's built-in rescaling partially duplicates scale_ingredients. The descriptions are detailed enough to separate them, though an agent could still pause between those pairs.

Naming Consistency5/5

All tool names follow a clear snake_case verb_noun pattern: list_, search_, browse_, get_, scale_. The one longer name, search_by_ingredients, still fits predictably and does not break the convention.

Tool Count5/5

Seven tools is a well-scoped set for a recipe site: discovery, browsing, retrieval, scaling, and translations are each represented without unnecessary duplication. Each tool earns its place in the workflow.

Completeness5/5

The read-side recipe workflow is fully covered: find categories, search, browse, search by ingredients, read a recipe, rescale ingredients, and access translations. There are no dead ends, and CRUD operations are not relevant to this domain.

Maintenance

ActivityMaintained

ResponsivenessUnresponsive

Resources

Need Help?

Related Servers

Related MCP Connectors

recipes A
io.github.pipeworx-io
Recipes MCP — wraps TheMealDB API (free tier, no auth)
Search Open Data
352
NoshUp: Canadian Grocery Deals & Recipes A
io.github.navshainc
Canadian grocery flyer deals and recipes by item, store, postal code, cuisine, or diet. No auth.
E-commerce & Retail Search
31
VeryChic Hotel Deals A
io.github.jordantete
Unofficial read-only MCP server for VeryChic hotel offers
Travel & Transportation E-commerce & Retail
221
Recipe Signal A
io.github.absharma9796
Search and compare attributed recipe records through a public read-only remote MCP endpoint.
Search Open Data
41

Related MCP Servers

Recettes MCP Server
Web Scraping Databases
Symfomany
F
license
C
quality
D
maintenance
Enables 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.
Updated 9 months ago (2025-12-17 16:21 UTC)
18
-
France BOAMP MCP
Government Data Open Data
pipeworx-io
A
license
Not graded
quality
C
maintenance
Enables querying French government public procurement notices (BOAMP) without an API key.
Updated 23 days ago (2026-08-26 17:07 UTC)
16 npm
MIT
mcp-marmiton
Health & Wellness Search
smeet666
A
license
A
quality
B
maintenance
MCP server that searches French recipes from Marmiton, reads ingredients and steps, and rescales quantities to any number of servings without requiring an API key.
Updated 20 hours ago (2026-09-17 17:14 UTC)
6
3
456 npm
MIT
mcp-bbc-goodfood
Health & Wellness Search
smeet666
A
license
A
quality
A
maintenance
Enables read-only recipe search and filtering on BBC Good Food by exposing available filter axes with counts, requiring no API key.
Updated 5 days ago (2026-09-14 00:54 UTC)
4
294 npm
MIT