mcp-supertoinette

Read one category's recipes

browse_recipes

Read-onlyIdempotent

Browse French recipe categories page by page to view recipe identifiers, difficulty, and total time. Use a category from list_categories or recipe tags to explore available recipes.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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

TableJSON 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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedv1.1.0Sep 11, 2026
- removedOutput schema / properties / results / items / properties / description / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / results / items / properties / description / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / results / items / properties / difficulty / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / results / items / properties / difficulty / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / results / items / properties / image_url / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / results / items / properties / image_url / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / title / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / title / type
```
Added value: +[
+  "string",
+  "null"
+]
```
First observedv1.0.1Aug 28, 2026

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.

Deploy Server