Skip to main content
Glama

Almost Fire

Find their foods

search_foods
Read-onlyIdempotent

Use this when the person tells you a food they ate without a photo, before log_foods. Find the person's own foods before anything else, by name or by kind: the words they used ("protein powder", "milk", "my usual bread"), not a brand you guess. mine is their saved foods that fit, each with an id, macros per 100 g, their usual grams (lastGrams), match (name: its name holds the words; kind: it is that kind of food, so "protein powder" finds their whey; word: only the last of their words, the one that says what it is, fits, so it is a different food of that sort, never theirs unless they say so) and lastEatenAt. When none fits by name, recent lists the saved foods they logged lately: read it too, because their food is often named by brand (a protein powder called Impact Lean Whey, a milk called Light Start). list is at most three plain foods from the food list, each with a foodKey; logging one saves it as a new food of theirs. Use their own food (mine or recent) when it is the same thing, or the kind of food they named (their milk for "milk", their whey for "protein powder"); a food that only sounds alike or shares a word is not it (corn flour is not corn, dark soy sauce is not dark chocolate). "My most recent" or "my usual" means the one they ate latest. Use list, an estimate or create_food only when none of theirs is it, and say it's new. Search before estimating, and log what it finds by grams. A recipe has recipe set: its foods and their grams, serves, cookedGrams and gramsLeft, what's left of the pot. Do not use to read a photo; use read_meal_photo.

Input Schema

NameRequiredDescriptionDefault
queryYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Goes well past the annotations by disclosing matching semantics: name matches must hold the words, kind matches resolve a category (whey for 'protein powder'), word matches are explicitly flagged as a different food that is not theirs, and false-positive rules are given (corn flour is not corn). Some of this overlaps the output schema, since it also narrates return fields like lastGrams, lastEatenAt and recipe contents, but the interpretive rules are genuine added behavior.

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

Conciseness2/5

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

Delivered as one long run-on block with deeply nested parentheses that bury rules like the name/kind/word distinction mid-sentence. Most content is genuinely useful, but it is not front-loaded with a purpose statement and the density makes the matching rules easy to misread.

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?

Given a one-parameter search over a complex domain, the description covers what it returns, what each match type means, what to do when nothing matches, a domain-specific false-positive guard, and the recipe edge case. An agent has enough to call it and interpret the result without further guidance.

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 0% for the single 'query' parameter, so the description must carry the meaning and it largely does: pass the words the person actually used, not a guessed brand, with concrete examples ('protein powder', 'milk', 'my usual bread'). What it does not specify is any syntax constraint or length limit, so some inference remains.

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: find the person's own saved foods by name or by kind, and it explicitly excludes photo reading by naming read_meal_photo. It is distinguishable from log_foods and create_food, though the actual purpose statement arrives after an opening sentence about when to use it rather than what it does.

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 when-to-use ('when the person tells you a food they ate without a photo, before log_foods'), explicit ordering against alternatives (mine or recent first, then list/estimate/create_food only when none of theirs fits), and an explicit exclusion ('Do not use to read a photo; use read_meal_photo'). It also handles ambiguous phrases like 'my most recent' or 'my usual'.

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