ask.recipes

Mark a recipe as cooked

mark_cooked

Destructive

Record that the user cooked a recipe, for "we made that tonight", "cooked the curry yesterday", "the lasagna was a hit". One entry per time it was cooked, with the day and an optional note on how it went. Pass date when the user names a day other than today. The recipe need not be saved. Pass rating when the user gave a verdict in stars or words, so the cook and the rating land in one call. Returns the entry plus how many times and when this recipe was last cooked.

Input Schema

Name	Required	Description
`id`	Yes	recipe id that was cooked
`date`	No	the day it was cooked as YYYY-MM-DD in the user's calendar, e.g. yesterday's date for 'we made it last night'; empty means today
`note`	No	what the user said about how it went, e.g. 'kids loved it, double the sauce next time'; at most 200 characters
`rating`	No	the user's stars for the recipe, 1 to 5, when they gave a verdict: 'it was a hit' is 5, 'fine' is 3, 'never again' is 1; replaces their earlier rating of this recipe; leave out when they said nothing about how it was

Output Schema

Name	Required	Description	Default
`entry`	Yes
`last_cooked`	No
`times_cooked`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 31, 2026
- addedOutput schema / properties / entry / properties / cooked_by
```
Added value: +{
+  "type": "string"
+}
```

Changed3 schema fields changedOct 29, 2026

addedInput schema / properties / rating

Added value: +{
+  "description": "the user's stars for the recipe, 1 to 5, when they gave a verdict: 'it was a hit' is 5, 'fine' is 3, 'never again' is 1; replaces their earlier rating of this recipe; leave out when they said nothing about how it was",
+  "type": "integer"
+}

addedOutput schema / properties / entry / properties / recipe / properties / askrecipes_ratings
```
Added value: +{
+  "type": "integer"
+}
```

addedOutput schema / properties / entry / properties / recipe / properties / my_rating

Added value: +{
+  "properties": {
+    "note": {
+      "type": "string"
+    },
+    "stars": {
+      "type": "integer"
+    }
+  },
+  "required": [
+    "stars"
+  ],
+  "type": [
+    "null",
+    "object"
+  ]
+}

Changed1 schema field changedOct 25, 2026
- addedOutput schema / properties / entry / properties / recipe / properties / main_protein
```
Added value: +{
+  "type": "string"
+}
```
Changed3 schema fields changedOct 25, 2026
- removedOutput schema / additionalProperties
```
Removed value: -false
```
- removedOutput schema / properties / entry / additionalProperties
```
Removed value: -false
```
- removedOutput schema / properties / entry / properties / recipe / additionalProperties
```
Removed value: -false
```
Changed1 schema field changedOct 24, 2026
- addedOutput schema / properties / entry / properties / recipe / properties / scale_class
```
Added value: +{
+  "type": "string"
+}
```
AddedOct 24, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=false; the description justifies these by explaining that each call creates a new entry rather than toggling a flag, and adds that the recipe need not be saved first. It also discloses the return payload (entry plus cook count and last-cooked date). It does not surface that a supplied rating replaces the earlier one, which is the concrete destructive effect.

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?

Front-loaded with the core action, then param rules, then return behavior. The quoted user utterances are dense with routing value rather than filler. Slightly longer than strictly necessary, with the third example ("the lasagna was a hit") adding little beyond the first two.

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 4-param mutation with full schema coverage, annotations, and an output schema, the description covers what to record, when, and what comes back. Minor residual gaps are overwrite semantics for rating and behavior on an unknown id, neither of which is essential to call it correctly.

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 coverage is 100%, so the baseline is 3, and the description earns the extra point by adding invocation rules rather than restating types: when to supply date versus default to today, and when a rating should be included at all. Note size limits and rating scale live in the schema, appropriately.

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?

States a specific verb and resource ("Record that the user cooked a recipe") plus the unit of record ("One entry per time it was cooked"), which separates it from rate_recipe and cooked_history without opening either schema. The example utterances anchor the intent unambiguously.

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?

Gives concrete when-to-use triggers ("we made that tonight", "cooked the curry yesterday") and routing rules for the optional params: pass date only when a day other than today is named, pass rating when a verdict was given "so the cook and the rating land in one call". It implies rate_recipe should not be called separately for the same event but never names that sibling explicitly, which is the one missing piece.

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

All ask.recipes tools Inspect

Try in Browser

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.