Skip to main content
Glama
tobilektri

Cookidoo MCP Server

by tobilektri

Plan Recipe

plan_recipe

Add one or more catalogue or personal recipes to a Cookidoo week plan for a specified day; connect to Cookidoo first, then provide date and comma-separated recipe IDs.

Instructions

Put one or more recipes into your Cookidoo week plan on a given day.

Catalogue recipes ("r59322") and your own recipes ("01M5...") can be mixed. You must be connected first using connect_to_cookidoo.

Input Schema

NameRequiredDescriptionDefault
dayYesThe day, as YYYY-MM-DD
recipe_idsYesRecipe IDs, comma-separated

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.9/5.0
Behavior3/5

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

With no annotations, the description must carry the full behavioral burden. It usefully discloses the authentication prerequisite and that catalogue and own recipes can be mixed, but it does not explain whether planning overwrites or appends to existing meals, how invalid IDs behave, or any side effects of this mutation.

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 paragraphs with no wasted words. The action is front-loaded, followed by recipe ID format guidance and the connection prerequisite.

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?

For a simple two-parameter mutation tool with a full schema and an output schema, the description covers the key context: what it does, valid ID formats, and the authentication prerequisite. It could be slightly more complete by mentioning overwrite/append behavior or duplicate handling, but it is largely sufficient for correct invocation.

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?

Schema description coverage is 100%, so the baseline is 3. The description adds value by clarifying acceptable recipe ID formats with examples ('r59322' and '01M5...') and noting that both catalogue and personal recipes can be mixed, which goes beyond the schema.

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 a specific verb and resource: putting recipes into the Cookidoo week plan for a given day. This is clearly a planning mutation, distinguishable in practice from search/list/unplan siblings, though no sibling is named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear usage context: adding recipes to the week plan, and explicitly requires the user to be connected first via connect_to_cookidoo. It does not state when not to use it, e.g., that unplan_recipe should be used to remove entries, nor does it mention duplicate handling.

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