Skip to main content
Glama
smeet666

mcp-supertoinette

Search the recipes

search_recipes
Read-onlyIdempotent

Find French recipes on Supertoinette by dish or ingredient. Use the returned category facets to narrow results, and each row's identifier to open the full recipe.

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
NameRequiredDescriptionDefault
pageNoWhich page of results to read, 1 by default. 'last_page' says how far they run.
limitNoRows to render, 20 by default. The site serves at most 39 to a page, and 'rows_published' always states what the page held.
queryYesA dish or an ingredient to look for, in French.
categoryNoNarrow 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
NameRequiredDescriptionDefault
urlYesThe page these rows were read from.
pageYesThe page these rows were read from.
notesYes
queryYes
facetsYesThe 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.
sourceYes
resultsYes
categoryYesThe category the answer was narrowed to, or null for a search across all of them.
last_pageYesThe highest page the site links to from this one.
result_countYesRows rendered here.
rows_publishedYesRows the page held, before any were rendered.
total_availableYesSupertoinette prints no total on a search page, so there is none to report.
Behavior5/5

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

Annotations already declare read-only, open-world, and idempotent behavior, and the description adds valuable non-obvious details: no total_available, last_page semantics, facets, and the fact that an unknown category behaves like an empty match while the answer says so. This is exactly the kind of site-specific behavior an agent needs.

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 main action is front-loaded, and every sentence earns its place by explaining a behavior or boundary the agent would otherwise have to discover at runtime. The density is high without being verbose.

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 4-parameter search tool with an output schema and safety annotations, the description covers all operational edge cases: no site total, last_page, facets, invalid-category behavior, and the get_recipe handoff. Nothing needed for a correct call 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%, and every parameter already has detailed meaning (page limits, the 39-row ceiling, French query, exact category spelling). The description echoes some of this but does not materially add beyond the schema, 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 names a specific action and resource: search Supertoinette by a dish or an ingredient, and links results to get_recipe via the identifier. This clearly distinguishes the tool from siblings like browse_recipes or list_categories, so an agent knows exactly what it does.

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: search by dish/ingredient, narrow with a facet-derived category, then read via get_recipe. It does not explicitly list conditions against sibling tools like browse_recipes or list_categories, so it stops short of full exclusions; that is the only gap.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/smeet666/mcp-supertoinette'

If you have feedback or need assistance with the MCP directory API, please join our Discord server