Skip to main content
Glama

IZeat

Read an IZeat recipe to cook

get_recipe

Returns one IZeat catalogue recipe in full, to cook it with the customer: the ingredients scaled to their plate, the seasonings and the whole method. The ingredients are scaled to the customer's plate, but steps are the original method for the whole recipe: quantities written inside them are not scaled. Make this distinction clear; use the scaled ingredient list for plate quantities and do not present whole-recipe quantities as plate quantities. Use it when the customer chooses a recipe from find_recipes to cook, or asks for the method of an IZeat recipe. recipe is the reference find_recipes gave; plate_g the plate it showed, unless the customer wants another size. Call it for each new explicit request for a complete recipe, even if that recipe appeared earlier in the conversation. Show it with your own recipe view when your app has one (the ingredients, then the steps, with its step-by-step cooking mode), one serving being this plate and every quantity the one IZeat gives; otherwise list the ingredients and guide them through the method one step at a time, waiting for them before the next step. Answer their questions about the dish. Log nothing while they cook. A successful request for the complete method records one recipe use, at most once per account, recipe and UTC day. Eligible uses determine creator royalties; a later meal log does not count another use. Requesting the method does not prove that the customer cooked or ate it. When they have eaten, ask what they actually ate and how much, then log it with log_meal, with their own quantities and changes, and pass this recipe's reference in log_meal recipes. Example: get_recipe { "recipe": "mac-beef", "plate_g": 550 }. statement is the customer-facing IZeat message. It begins with "IZeat ·" so customers can distinguish information returned by IZeat from the assistant's own response. For write operations, it also states whether the requested change was recorded in their IZeat account. Account: Sam (review@izeat.app)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
recipeYesThe recipe reference find_recipes gave
plate_gYesThe plate find_recipes showed, in grams, or the size the customer asked for

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYes
dataYes
statementYesCustomer-visible IZeat receipt. Its value begins with "IZeat ·".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only flag readOnlyHint=false and idempotentHint=false; the description explains why and what that means: a successful call 'records one recipe use, at most once per account, recipe and UTC day', royalties derive from eligible uses, and requesting the method does not prove cooking. It also discloses the scaling asymmetry (ingredients scaled, in-step quantities not) and the 'log nothing while they cook' constraint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded in sentence one, but the text runs long and mixes tool semantics with agent workflow instructions (recipe view vs step-at-a-time guidance, when to log, what to tell the customer) and spends several sentences explaining the 'statement' output field despite an output schema existing.

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 tool with side effects and an output schema, the description supplies everything else an agent needs: scaling semantics, the display/step-by-step protocol, the use-recording rule with its royalty and once-per-day implications, and a concrete call example.

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 100%, so the schema already documents both parameters. The description's 'recipe is the reference find_recipes gave; plate_g the plate it showed, unless the customer wants another size' largely restates the schema text, adding only the alternate-size nuance.

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 first sentence gives a specific verb and resource ('Returns one IZeat catalogue recipe in full, to cook it') and immediately enumerates the payload (scaled ingredients, seasonings, method). It is clearly distinguishable from find_recipes (selection) and log_meal (consumption) named in the siblings.

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

Usage Guidelines5/5

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

Explicit trigger conditions are given: 'Use it when the customer chooses a recipe from find_recipes to cook, or asks for the method of an IZeat recipe', plus the repeat-call rule ('Call it for each new explicit request... even if that recipe appeared earlier'). It also routes downstream behavior to log_meal, so when and when-not are fully covered.

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