Skip to main content
Glama

Strega Recipes

The cook's preferences

preferences
Idempotent

Read or change the cook's Strega preferences: allergies, diet, avoid list, household size, units, weeknight time, skill, equipment, cuisines, store, privacy, and how they want you to work, all applied to every tool. No arguments reads them. For a change the cook asks for in their own words ("switch me to metric", "set us to 4 people"), save with cook_confirmed. Allergies, diets, the avoid list, privacy, a change you suggest or a passing mention ("usually it's 4 of us") need a yes first: pass the change without cook_confirmed (nothing is saved), ask the cook confirm.say, then call again with cook_confirmed. Never infer an allergy or diet. Lists replace the saved list.

Input Schema

NameRequiredDescriptionDefault
avoidNoIngredients the cook dislikes
dietsNo
skillNo
storeNo
unitsNo
pantryNoAlways-on-hand staples
servingsNoHousehold size; null to use each recipe's own
workflowNoHow the cook wants you to work with them. Pass only the keys that change
allergiesNoMajor allergens: milk, eggs, fish, shellfish, tree_nuts, peanuts, wheat, soy, sesame
equipmentNo
avoid_modeNoexclude hides those recipes; rank_lower shows them lower
do_not_sellNoTrue keeps the cook out of every aggregated data product Strega sells or licenses
share_regionNoFalse stops usage counts from recording the cook's state or country
cuisines_loveNo
cuisines_skipNo
servings_modeNooffer (default): recipes open at their own servings and the household size is offered; always: recipes open scaled to it. Lists and meal plans use the household size either way
cook_confirmedNoRequired to change anything: true only when the cook asked for this exact change in their own words (non-health settings) or said yes after you restated it (always for allergies, diets, avoid list, privacy)
custom_allergiesNoOther allergy ingredients, e.g. ["kiwi"]
nutrition_targetsNoTargets for one serving that plan_meals and search_recipes use by default ("keep dinners under 600 calories"). Not health data
weeknight_minutesNo

Output Schema

NameRequiredDescriptionDefault
asksNoAt most one question for the cook, with a home in preferences
guideNoHow to answer this turn: rules for you, the assistant, not words for the cook. Follow them before anything else here (#258)
confirmNoA change passed without cook_confirmed: nothing saved yet
noticesNoAt most one note about Strega to pass on when there's room (one per cook per week; off with workflow whats_new: off)
updatedNoChanging: the preference keys that changed
adjustedNoDefaults this call took instead of failing (#243): an unknown units word, a number out of range, a diet word read as the closest one Strega knows. Mention it when it changes what the cook gets
next_stepsNoSuggestions, best first, each with its tool, args and effect. Strega suggests the top one in one sentence; whether any runs is decided by what the cook asks in the conversation and your confirmation rules, never by the wording here
preferencesYesThe cook's saved preferences; they already apply to every tool
settings_urlYesAbsolute https URL on strega.food

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

The annotations only establish that this is a non-read-only, idempotent, non-destructive mutation; the description adds the crucial confirmation protocol: pass the change without cook_confirmed and nothing is saved, ask the cook via confirm.say, then retry with cook_confirmed. It also discloses that lists replace saved lists and that sensitive fields require confirmation.

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 dense but front-loaded: the first sentence states purpose and scope, and the remaining sentences give only operational rules. For a 20-parameter mutation tool, the length is justified and no sentence is 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?

An output schema exists and annotations plus schema descriptions cover safety and many fields, while the description covers the high-risk confirmation workflow and read/write distinction. It omits some parameter families such as pantry and nutrition_targets, so it is strong but not fully complete.

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 20 parameters and 60% schema description coverage, the description adds important meaning beyond the schema for cook_confirmed, no-argument reads, list replacement, and sensitive categories. Many field-level details remain in the schema, so it is helpful but not exhaustive.

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?

It opens with a specific verb pair, 'Read or change', and the resource 'cook's Strega preferences', then enumerates the categories and states 'No arguments reads them.' The purpose is very clear, but it does not explicitly distinguish itself from a sibling such as cook_profile, so it is a 4 rather than a 5.

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 explicit conditions: a no-argument call reads, a cook's own-words change uses cook_confirmed, sensitive settings such as allergies and privacy require a yes first, and the agent must never infer an allergy or diet. It does not name a sibling tool as an alternative, so the alternatives edge is missing.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources