mcp-supertoinette

Search the recipes

search_recipes

Read-onlyIdempotent

Search Supertoinette for French recipes by dish or ingredient, then narrow results using category facets from the response.

Instructions

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.

Input Schema

TableJSON Schema

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

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv1.1.0Sep 11, 2026
- removedOutput schema / properties / category / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / category / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- 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 / image_url / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / results / items / properties / image_url / type
```
Added value: +[
+  "string",
+  "null"
+]
```
First observedv1.0.1Aug 28, 2026

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.

Deploy Server