Click on "Install 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., "@cookidoo-mcp upload a new chocolate chip cookie recipe"
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.
An MCP server that bridges LLM sessions (Claude, Gemini, or any MCP client) to Cookidoo custom recipes on a Thermomix (TM7 by default). Describe a recipe in a chat, and the server uploads it as a Cookidoo custom recipe with proper structured Thermomix settings (time, temperature, speed, reverse) so it looks and behaves like an official recipe on the device.
The server ships its own German authoring guide as an MCP prompt and resource, so the writing rules for Thermomix steps do not have to live in your prompts.
Disclaimer: Cookidoo/Vorwerk offers no official public API. This project relies on the reverse-engineered API of miaucl/cookidoo-api and may break whenever the Cookidoo backend changes. Use at your own risk.
Prior art this project builds on:
miaucl/cookidoo-api - the unofficial Cookidoo API library used for login and session handling
alexandrepa/mcp-cookidoo - first Cookidoo MCP server, source of the create/patch upload flow
Xdev22/cookidoo-mcp - discovered the structured TTS and INGREDIENT annotations that make custom recipes look like official ones
upload_recipe - upload a recipe with structured ingredients and steps.
The LLM supplies semantics only (text, time, temperature, speed, reverse);
the server renders the German settings notation and computes all Cookidoo
annotations itself. Optional image_url/image_base64 parameters attach
a photo in the same call.
set_recipe_image - set or replace the photo of an existing custom
recipe, from an https URL or base64 data.
list_custom_recipes - list your custom recipes.
get_custom_recipe - fetch one custom recipe by id.
delete_custom_recipe - delete a custom recipe by id.
get_recipe_details - fetch any Cookidoo recipe by id.
get_shopping_list, add_items_to_shopping_list,
add_recipe_to_shopping_list - read and fill the shopping list.
get_meal_plan, add_recipe_to_meal_plan - read and fill the weekly
planner.
MCP prompt and resource with the full German Thermomix authoring guide, plus compact server instructions delivered to every client on connect.
Optional GitHub OAuth with a user allowlist and persistent client registrations for safe public exposure.
Custom recipes can carry a photo. Pass image_url or image_base64
(exactly one source; base64 works with or without a data URI prefix) to
upload_recipe, or call set_recipe_image for a recipe that already
exists. JPEG and PNG are supported, from 80x80 pixels (smaller images are
rejected by Cookidoo) up to 10 MB. URL images are downloaded by the server
itself (https only), and Cookidoo re-hosts every image on its own CDN.
Clients should downscale images to about 800px (JPEG, quality around 70)
before embedding them as base64. An image failure does not
abort the recipe upload; the result then contains an image_warning
instead.
Related MCP server: Cookidoo MCP Server
Python 3.12 or newer
A Cookidoo account with an active subscription
uv sync
cp .env.example .envThen edit .env and fill in your Cookidoo credentials:
Variable | Meaning | Default |
| Cookidoo account email | required |
| Cookidoo account password | required |
| Country code |
|
| Language code |
|
| Device written to the recipe tools field |
|
Locale examples:
Country |
|
|
Germany |
|
|
Austria |
|
|
uv run cookidoo-mcpThis starts the server with streamable HTTP transport on
http://127.0.0.1:8000/mcp. Host and port are configurable via MCP_HOST
and MCP_PORT.
For clients that spawn the server as a subprocess, use stdio transport instead:
MCP_TRANSPORT=stdio uv run cookidoo-mcpclaude mcp add --transport http cookidoo http://localhost:8000/mcpAdd the server to your claude_desktop_config.json:
{
"mcpServers": {
"cookidoo": {
"type": "http",
"url": "http://localhost:8000/mcp"
}
}
}Connectors on claude.ai (web, mobile app, and the Claude Desktop connector dialog) are established from Anthropic servers, so LAN-only deployments are not reachable there. To use the server from those clients it must be exposed to the internet - and then it MUST be protected, otherwise anyone could use your Cookidoo account.
The server supports GitHub OAuth via FastMCP:
Register an OAuth app at https://github.com/settings/developers.
Homepage: your MCP_BASE_URL; callback URL:
<MCP_BASE_URL>/auth/callback.
Set GITHUB_CLIENT_ID, GITHUB_CLIENT_SECRET, MCP_BASE_URL,
ALLOWED_GITHUB_USERS (and ideally MCP_JWT_SIGNING_KEY plus
MCP_STATE_DIR for persistent client registrations - without it a
restart disconnects all authorized clients) in the .env file and
restart the container.
Make the server publicly reachable (see below).
Add the connector with your public https://.../mcp URL; Claude
redirects you through the GitHub login once per client.
Only the GitHub accounts listed in ALLOWED_GITHUB_USERS are accepted;
every other login is rejected after authentication. Without the GitHub
variables the server runs unauthenticated as before - keep it LAN-only
in that case.
The battle-tested setup (and the one this project runs in production) is a Cloudflare Tunnel in front of a localhost-only server container:
Put a domain on Cloudflare (free plan; only the nameservers change,
the registration stays where it is), create a tunnel under Zero Trust
-> Networks -> Tunnels, and map a public hostname such as
cookidoo.example.com to http://localhost:8443.
Run the connector next to the server (same host):
docker run -d --name cloudflared --network host \
--restart unless-stopped \
-e TUNNEL_TOKEN=<your tunnel token> \
cloudflare/cloudflared:latest tunnel runBind the server container to localhost only (the deploy script does
this), drop the MCP_SSL_* variables (Cloudflare terminates TLS with
auto-renewing certificates) and set MCP_BASE_URL and the GitHub app
URLs to the tunnel hostname.
This needs no router port forwarding and works behind DS-Lite or CGNAT, because the tunnel connects outbound and Cloudflare provides a dual-stack edge - important since the claude.ai connector infrastructure connects over IPv4 only, so an IPv6-only port release is never reached.
Known pitfall: Tailscale Funnel does NOT work as the public endpoint for claude.ai connectors. The funnel edge intermittently aborts TLS handshakes, and the multi-request OAuth flow of the connector broker gives up on the first failure, surfacing as "Couldn't reach the MCP server" with zero requests in your logs - even though curl and Claude Code work fine through the same funnel.
uv run pytestUnit and integration tests run offline against mocked HTTP. The end-to-end
tests in tests/test_e2e.py talk to the live Cookidoo API and are skipped
unless real credentials are present in .env.
Every push to main builds a multi-arch image (amd64/arm64) via GitHub
Actions and publishes it as
ghcr.io/jsaedtler/cookidoo-mcp-docker:latest. On the server you only
need the credentials file and one script:
sudo mkdir -p /docker/cookidoo-mcp
sudo cp .env.example /docker/cookidoo-mcp/.env # fill in your credentials
./deploy/update-cookidoo-mcp.shdeploy/update-cookidoo-mcp.sh stops and removes the old container,
pulls the latest image and starts it again with --restart=unless-stopped.
Re-run it any time to update. Adjust the ENV_FILE, SSL_DIR,
STATE_DIR and PORT variables at the top of the script to your setup.
When you do not use the Cloudflare Tunnel (for example LAN-only use with
Claude Desktop, which requires an https URL), the server can terminate
TLS itself: set MCP_SSL_CERTFILE and MCP_SSL_KEYFILE and mount a
certificate directory into the container (the deploy script does this
via SSL_DIR). Any certificate you already have works, for example a
Let's Encrypt certificate from another service on the same host. The
hostname in the MCP URL must match the certificate. After a certificate
renewal restart the container (docker restart cookidoo-mcp) so it
picks up the new files.
cp .env.example .env # fill in your Cookidoo credentials
docker compose up -d --buildThe server then listens on http://<host>:8000/mcp (Streamable HTTP) for
clients in your network. To change the port, adjust both sides of the
ports mapping in docker-compose.yml.
Notes:
Credentials are injected at runtime via env_file; the .env file is
never baked into the image (see .dockerignore).
The container binds :: (dual-stack). If the Docker daemon runs with
ip6tables: true, published ports are DNATed to the container's IPv6
address, so a v4-only bind would time out for all IPv6 clients even
though the port looks open on IPv4.
The image runs as a non-root user and builds on both amd64 and arm64.
Typical deployment on a server: clone the repository, create .env,
run docker compose up -d --build. The restart: unless-stopped
policy brings the container back after reboots.
Setzt freie Artikel (z. B. "Milch") auf die Einkaufsliste.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It only states the basic action and does not disclose whether items are appended, duplicates handled, list existence required, or any auth needs. For a mutating tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with clear verb-first structure and an example. No unnecessary words, perfectly sized for the simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple schema and an output schema exists, so return values need not be described. The purpose is clear, but it lacks explicit guidance on alternatives and behavioral details like merge semantics. Adequate but not comprehensive for the sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It adds meaning by specifying 'freie Artikel' and giving an example 'Milch', clarifying the strings are product names. However, it doesn't explain constraints like max count or behavior on duplicates, so compensation is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Setzt' (sets) with a clear resource 'Einkaufsliste' (shopping list), and clarifies it is for 'freie Artikel' (free items). This distinguishes it from the sibling tool 'add_recipe_to_shopping_list', making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for arbitrary items not tied to recipes, which hints at when to use it versus the sibling add_recipe_to_shopping_list. However, it does not explicitly state when to use this tool or exclusions, leaving usage guidance mostly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Plant ein Rezept fuer einen Tag (YYYY-MM-DD) im Wochenplan ein.
Fuer eigene Custom-Rezepte is_custom=true setzen.
| Name | Required | Description | Default |
|---|---|---|---|
| day | Yes | ||
| is_custom | No | ||
| recipe_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It explains the required date format and the custom-recipe flag, which adds useful context. However, it does not disclose side effects (e.g., whether an existing entry is overwritten), prerequisites (e.g., recipe existence), or error conditions, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the primary action, and each sentence serves a clear purpose: stating the operation and adding the custom-recipe conditional. No redundant information or repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (3 parameters, no nested objects) and the presence of an output schema, the description covers the essential semantics: what it does, the target resource, the date requirement, and the special flag condition. It leaves out minor details like error behavior or duplicate handling, but these are not critical for a straightforward insertion tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for missing parameter meanings. It explicitly explains the day format (YYYY-MM-DD) and the meaning of is_custom. However, recipe_id is not described beyond its name, though its purpose is partially inferable from the tool's context. This is adequate but not comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Plant' (schedule) with a specific resource 'Rezept' and 'Wochenplan' (weekly plan), clearly distinguishing it from sibling tools like add_recipe_to_shopping_list or get_meal_plan. It also specifies the date format and the is_custom flag, making the action unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating the action (scheduling a recipe in the weekly plan) but does not explicitly contrast with alternatives or state when not to use it. The note about setting is_custom=true for custom recipes offers a conditional usage hint, but no explicit exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Setzt die Zutaten eines Rezepts auf die Einkaufsliste.
Fuer eigene Custom-Rezepte is_custom=true setzen.
| Name | Required | Description | Default |
|---|---|---|---|
| is_custom | No | ||
| recipe_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only states the core action and the is_custom flag, but does not clarify side effects such as whether existing shopping list items are appended or overwritten, how non-custom recipes are resolved, or potential error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the primary action and followed by a precise parameter hint. There is no fluff or repetition, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no annotations, the description covers the core action and one parameter nuance, but lacks behavioral details, usage scenarios, or return-value information. It is minimally adequate but leaves clear gaps that an agent would need to infer from sibling tool names or additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds value by explaining is_custom ('For own custom recipes set is_custom=true'), which is not self-evident from the schema. However, it does not elaborate on recipe_id beyond its name, leaving some ambiguity about what constitutes a valid recipe source.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Setzt die Zutaten eines Rezepts auf die Einkaufsliste' (adds a recipe's ingredients to the shopping list). This is a specific verb+resource combination and distinguishes it from siblings like add_items_to_shopping_list, which handles arbitrary items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a parameter-specific instruction for custom recipes ('Fuer eigene Custom-Rezepte is_custom=true setzen'), which provides some guidance. However, it does not explicitly state when to choose this tool over alternatives such as add_items_to_shopping_list or add_recipe_to_meal_plan, leaving usage context implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Loescht ein eigenes Custom-Rezept endgueltig.
| Name | Required | Description | Default |
|---|---|---|---|
| recipe_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose the key destructive trait of permanence ('endgueltig') and scope ('eigenes'). However, it omits other important behavioral aspects such as side effects on related data, error handling, or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It efficiently conveys the action, object, and permanence, earning its place without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema exists), the description covers the core purpose and permanence but lacks context about preconditions, behavior on nonexistent IDs, or impact on related entities. It is viable but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter recipe_id is not mentioned in the description, and schema coverage is 0%. While the name is self-explanatory, the description adds no meaning beyond the schema, such as expected format, constraints, or relationship to ownership.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Loescht) and the target (eigenes Custom-Rezept), and specifies permanence (endgueltig). This distinguishes it from sibling tools like get_custom_recipe and list_custom_recipes, which are reads, and upload_recipe, which creates or updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or complementary tools, leaving the agent to infer usage solely from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Liest ein eigenes Custom-Rezept mit Zutaten, Schritten und Annotationen.
| Name | Required | Description | Default |
|---|---|---|---|
| recipe_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'liest' implies a read operation, and the description specifies the content (ingredients, steps, annotations), which is helpful. However, it does not disclose side effects, error handling, or permission requirements, leaving some behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately communicates the tool's purpose without any unnecessary detail or repetition. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers the core behavior and content. However, it lacks usage context regarding when to choose it over sibling tools like get_recipe_details, and it does not address potential edge cases, making it only partially complete for an agent selecting the appropriate tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single parameter 'recipe_id', and the description does not explicitly explain how to use it. While the parameter name is self-explanatory and the description implies reading a specific recipe, it does not add explicit meaning beyond the schema's structural definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads a custom recipe with ingredients, steps, and annotations. It uses a specific verb 'liest' (reads) and resource 'Custom-Rezept' (custom recipe), which distinguishes it from sibling tools like list_custom_recipes (listing) and get_recipe_details (which likely covers standard recipes, not custom ones).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or scenarios where other tools like get_recipe_details or list_custom_recipes would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Liest den Wochenplan der Kalenderwoche, die den Tag (YYYY-MM-DD) enthaelt.
| Name | Required | Description | Default |
|---|---|---|---|
| day | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It indicates a read operation, but adds no further behavioral details (e.g., error handling, auth needs). The description is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that fully conveys the tool's purpose and parameter semantics without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with an output schema, the description covers the essential logic (week retrieval from a date) and is complete. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a plain 'day' string. The description adds the required format (YYYY-MM-DD) and explains that the day determines the calendar week, which is meaningful context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads the weekly plan for the calendar week containing a given day, using specific verbs and resource. It distinguishes from sibling tools like add_recipe_to_meal_plan (write operation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: pass a date to get that week's meal plan. It doesn't explicitly name alternatives or exclusions, but the purpose is distinct enough that usage is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Liest die Details eines offiziellen Cookidoo-Rezepts.
| Name | Required | Description | Default |
|---|---|---|---|
| recipe_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The verb 'liest' explicitly indicates a read-only operation, which is a behavioral trait. However, with no annotations provided, the description does not disclose other aspects like authentication requirements, rate limits, or specific behaviors such as handling invalid IDs. It is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with zero wasted words. It is appropriately front-loaded and easy to process.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool has only one parameter and an output schema, the description lacks essential context such as how to find recipe_id, what 'official' means relative to custom recipes, or any usage notes. The minimal nature leaves gaps that a user would need to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema_description_coverage is 0% and the description does not explain the recipe_id parameter at all. The description fails to compensate for the lack of schema documentation, leaving the parameter's format, source, or semantics entirely unspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it reads details of an official Cookidoo recipe, using the specific verb 'liest' (reads) and identifying the resource ('Details eines offiziellen Cookidoo-Rezepts'). It differentiates slightly from sibling get_custom_recipe by noting 'official', though it does not explicitly name the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that get_custom_recipe should be used for custom recipes, nor any prerequisites (e.g., how to obtain a recipe_id).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Liest die Einkaufsliste: Rezepte, Zutaten und zusaetzliche Artikel.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'Liest' (reads), which conveys a read-only operation, but this is already implicit in the tool name 'get' and adds no additional context about side effects, caching, auth requirements, or error behavior. The description does not go beyond the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear German sentence that efficiently communicates the tool's purpose and the contents of the shopping list. There is no wasted wording or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and an output schema, so the description need not explain return values. It adequately covers the operation and resource contents, making it sufficiently complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, which the description correctly reflects. Since there are no parameters to explain, the baseline score of 4 applies. The description adds no parameter information, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Liest die Einkaufsliste' (reads the shopping list), and specifies the exact contents (recipes, ingredients, additional items). This distinguishes it from sibling tools like add_items_to_shopping_list and get_meal_plan, which involve different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by indicating the tool reads the shopping list, but it does not explicitly state when to use it versus alternatives, nor does it mention any exclusions. The context of sibling tools suggests it is for retrieval, but the description itself lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Listet alle eigenen Custom-Rezepte mit id, Name, Gesamtzeit und URL.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It states the action ('Listet alle') and the output fields, which implies a read-only operation, but it does not explicitly confirm non-mutating behavior or mention any potential side effects. It also does not disclose any ordering or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose and output fields. Every word earns its place, with no redundant information or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, clear action, and output fields listed), the description is sufficiently complete. It does not provide alternative tool references, but the purpose is unambiguous, and the output schema likely covers return value details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the input schema leaves nothing to explain. The description adds value by listing the output fields, which helps the agent understand what to expect from the response, even though this is not parameter-related.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Listet' (lists) with a clear resource 'eigene Custom-Rezepte' (own custom recipes), and explicitly mentions the returned fields (id, name, total time, URL). This clearly distinguishes it from sibling tools like get_custom_recipe, which likely retrieves a single recipe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its usage (to list all custom recipes) but does not explicitly state when to use it over alternatives, such as get_recipe_details or get_custom_recipe. There is no mention of exclusions or prerequisites, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Setzt oder ersetzt das Foto eines eigenen Custom-Rezepts.
Genau eine Bildquelle angeben:
image_url: https-URL eines JPEG- oder PNG-Bilds (maximal 10 MB); der Server laedt das Bild selbst herunter.
image_base64: Bilddaten als Base64, optional mit "data:image/...;base64,"-Praefix (z. B. Foto aus einem PDF). Das Bild vor der Einbettung auf ca. 800 px Kantenlaenge verkleinern und als JPEG mit Qualitaet ca. 70 speichern, damit die Anfrage klein bleibt.
Das Bild muss mindestens 80x80 Pixel gross sein, sonst lehnt Cookidoo es ab - beim Verkleinern also nicht unter diese Grenze gehen.
| Name | Required | Description | Default |
|---|---|---|---|
| image_url | No | ||
| recipe_id | Yes | ||
| image_base64 | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses server-side download behavior for URLs, Cookidoo's 80x80 pixel minimum rejection, and recommends resizing to ~800px/quality 70 to keep requests small. This goes beyond basic mutation semantics and adds operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and well-structured, with a lead sentence and clear parameter bullet points. All sentences add value, though the resizing instructions are slightly verbose. It remains appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple single-attribute mutation, the description covers the essential parameter semantics, constraints, and server behavior. It does not mention error cases or idempotency, but an output schema exists, so return values need not be described. Overall, sufficient for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates. It explains image_url (https, JPEG/PNG, ≤10MB, server downloads) and image_base64 (Base64, optional prefix, resizing advice), and clarifies the 'exactly one' constraint that the schema alone does not enforce.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Setzt oder ersetzt das Foto eines eigenen Custom-Rezepts' (sets or replaces a custom recipe's photo). This clearly distinguishes it from sibling tools like upload_recipe or get_custom_recipe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage constraints (exactly one image source, format/size limits) but no explicit guidance on when to prefer this tool over alternatives like upload_recipe. Context is clear but alternatives are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Laedt ein Custom-Rezept fuer den Thermomix nach Cookidoo hoch.
Regeln fuer den Aufbau (vollstaendige Anleitung: Resource cookidoo://rezept-anleitung):
Geraete-Einstellungen (Zeit, Temperatur, Stufe, Linkslauf) NIEMALS in den Schritt-Text schreiben. Nutze pro Schritt die strukturierten Felder time_seconds, temperature (37-120 oder "varoma"), speed (0.5-10 in halben Stufen, "turbo", "ruehrstufe") und reverse; der Server erzeugt die Notation und die Cookidoo-Annotationen selbst.
Schritt-Text im Imperativ, beginnt mit einem Verb, eine Aktion pro Schritt. Das Gefaess heisst immer "Mixtopf", niemals "Thermomix".
Zutatenmengen NIEMALS im Schritt-Text wiederholen; Artikel verwenden ("das Mehl zugeben", nicht "200 g Mehl zugeben"). Mengen stehen nur in der Zutatenliste mit getrennten Feldern quantity, unit und name.
Optional kann ein Rezeptfoto mitgegeben werden: image_url (https-URL, JPEG oder PNG) ODER image_base64 (Bild vorher auf ca. 800 px Kantenlaenge verkleinern, JPEG mit Qualitaet ca. 70; mindestens 80x80 Pixel, sonst lehnt Cookidoo es ab). Schlaegt nur das Bild fehl, wird das Rezept trotzdem angelegt und die Antwort enthaelt image_warning.
Das fertige Rezept zuerst dem Benutzer vollstaendig anzeigen und erst nach dessen ausdruecklicher Freigabe hochladen.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| hints | No | ||
| steps | Yes | ||
| servings | No | ||
| image_url | No | ||
| ingredients | Yes | ||
| image_base64 | No | ||
| prep_time_minutes | No | ||
| total_time_minutes | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses several non-obvious behaviors: the server generates notation and annotations from structured fields, a failed image upload still results in recipe creation with an image_warning in the response, and the tool must not actually upload until the user explicitly approves. This level of transparency goes beyond basic mutation warnings and gives the agent important operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a clear opening statement followed by bullet points for rules. Although lengthy, every sentence conveys critical usage information and earns its place. The structure improves scannability, and the content is front-loaded with the primary purpose. It is not wasteful or repetitive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is remarkably complete for a complex upload tool. It covers parameter semantics, validation constraints, behavioral edge cases (image failure, approval requirement), and the overall workflow. An output schema exists, so the absence of return value details is acceptable. Given the lack of annotations, the description fully compensates and leaves few unanswered questions about how the tool behaves.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is the sole source of parameter meaning. It explains the semantics of the most complex parameters: time_seconds, temperature (range and varoma), speed (values and half-steps), reverse, image_url/image_base64 (with size/format constraints), and ingredients (separate quantity, unit, name). It also explains structural rules for step text and ingredient quantities, covering nearly all non-obvious fields. The only minor gap is the 'hints' parameter, but overall it compensates fully for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: 'Laedt ein Custom-Rezept fuer den Thermomix nach Cookidoo hoch' (uploads a custom recipe for Thermomix to Cookidoo). This clearly distinguishes it from sibling tools like list_custom_recipes or set_recipe_image. The rest of the description elaborates on the exact scope and rules, leaving no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides extensive guidelines on how to construct the recipe correctly: specific rules for step text, temperature/speed fields, ingredient quantities, image constraints, and the requirement to show the recipe to the user before uploading. It does not explicitly name alternative tools or state when not to use this tool, but the context makes it clear that this is the upload path for custom recipes. A clear, context-rich guideline without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct resource and action: custom recipe CRUD (upload/list/get/delete/set image), official recipe read, shopping list read/add, and meal plan read/add. Even similar tools like add_items_to_shopping_list and add_recipe_to_shopping_list are clearly differentiated by their target (free items vs. recipe ingredients).
All tool names follow a consistent verb_noun pattern (upload_recipe, list_custom_recipes, get_shopping_list, add_recipe_to_meal_plan). Verbs are consistent (list, get, add, set, delete) and nouns clearly indicate the resource. No mixed naming conventions.
With 11 tools, the server is well-scoped for its purpose. Each tool covers a core aspect of Cookidoo integration—custom recipes, official recipe details, shopping list, and meal plan—without unnecessary duplication or bloat.
The set has notable gaps: custom recipes can be created and read but not updated (except image), shopping list items and meal plan entries can be added but not removed, and there is no search or list for official recipes. These missing operations will cause agents to fail when users need to modify or remove data.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search, save, organize, cook, and share recipes with any AI assistant.
Scraps Kitchen gives any AI agent a persistent, household-aware kitchen memory. Unlike generic chatbot recall, Scraps maintains structured cooking data: what's in your fridge (with freshness tracking), who you cook for (with allergens, dietary restrictions, and preferences), your recipe collection (with cook notes and per-diner ratings), your shopping list, and your kitchen equipment. 27 tools across 6 domains let agents read kitchen context, suggest meals that respect dietary safety, update the pantry after cooking, and build a history of what works for your household. Every interaction makes the data richer. Cooking history, preference signals, kitchen awareness = better suggestions next time. All tools work via oAuth and a free scraps.kitchen account.
Household-aware cooking brain: pantry, meal suggestions, dietary safety, recipes, shopping lists.
AI-powered kitchen management — pantry, recipes, meal plans, shopping lists
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jsaedtler/cookidoo-mcp-docker'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
