Skip to main content
Glama

Strega Recipes

What the cook has on hand

pantry
Idempotent

Read or change the cook's pantry: food on hand and staples, which Strega leaves off shopping lists and uses for what-can-I-make. Use when the cook says what they have or ran out of ("I've got chicken thighs and half an onion", "we're out of eggs"), corrects it, or asks what's in it. Pass their words verbatim as text; or add/remove names; a fridge photo goes in photo (an upload name). No arguments reads it. Saying what they have is the cook's yes: save it and read the change back in one line. Never add what the cook didn't say. Returns the change (unsure lists what didn't read as food) or the whole pantry.

Input Schema

NameRequiredDescriptionDefault
addNoIngredient names to add
textNoWhat the cook said, verbatim
photoNoAn upload name (or its /media/ URL) from POST /api/upload with purpose "parse": a photo of the fridge or shelf to read
removeNoIngredient names to take out
replaceNoTake out every fresh item not in this update (staples stay)
staplesNoSet the always-on-hand list to exactly these

Output Schema

NameRequiredDescriptionDefault
asksNoAt most one question for the cook, with a home in preferences
addedNoChanging: what went in
countYesItems in the pantry now
guideNoHow to answer this turn: rules for you, the assistant, not words for the cook. Follow them before anything else here (#258)
itemsNoReading: everything on hand and the staples
staleNoReading: fresh items old enough to ask "still have it?"
unsureNoChanging: what didn't read as an ingredient; ask the cook
noticesNoAt most one note about Strega to pass on when there's room (one per cook per week; off with workflow whats_new: off)
removedNoChanging: names taken out
unknownNoChanging: asked to remove, but not in the pantry
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
pantry_urlYesAbsolute https URL on strega.food

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations, the description explains consent semantics: saying what they have counts as approval to save it. It also warns never to add items the cook did not mention and explains what the return value contains, including an 'unsure' list for text that did not read as food.

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 front-loaded with purpose and packed with useful behavior rather than filler. It is dense and somewhat run-on, but most clauses earn their place given the tool's read/write modes and safety rules.

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 covers purpose, usage triggers, input modes, consent behavior, mutation limits, and return shape. With an output schema present and annotations covering safety, it provides more than enough context for an agent to invoke the tool 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, but the description adds useful semantics for key parameters: text should be verbatim, add/remove take names, photo takes an upload name, and no arguments performs a read. It does not explain replace or staples in the prose, but the schema already documents those well.

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 states a specific read/change capability over the cook's pantry, inventory, and staples. It also clarifies scope by noting these are items left off shopping lists and used for what-can-I-make, which separates it from purely recipe or shopping-list tools.

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 triggers: when the cook states what they have, reports running out, corrects the pantry, or asks what is in it. It also explains the calling modes (verbatim text, add/remove names, photo, or no arguments), though it does not explicitly name sibling alternatives or when not to use this tool.

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