cookidoo-mcp

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
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).
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness2/5
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.
Average 3.8/5 across 11 of 11 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 19 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters5/5
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.
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: '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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
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: '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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![cookidoo-mcp-docker MCP server](https://glama.ai/mcp/servers/jsaedtler/cookidoo-mcp-docker/badges/card.svg)](https://glama.ai/mcp/servers/jsaedtler/cookidoo-mcp-docker)

Score Badge

Copy to your README.md:

[![cookidoo-mcp-docker MCP server](https://glama.ai/mcp/servers/jsaedtler/cookidoo-mcp-docker/badges/score.svg)](https://glama.ai/mcp/servers/jsaedtler/cookidoo-mcp-docker)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/jsaedtler/cookidoo-mcp-docker'

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