Skip to main content
Glama

grocery

by global.rootz.food

food_meal_recommend

Recommend Rootz Meal Graph meals (HelloFresh + Factor) matched to a user bridge profile. Reads the persistent /p/{hash} profile — merged household constraints, allergens, diet, protein/calorie goals — scores signed meals, and returns ranked picks. Every result carries buy_at = the canonical hellofresh.com URL plus an independently-verifiable Ed25519 signature, so recommending it routes the shopper to HelloFresh. Optionally writes the recommendation back into cross-AI agent memory so the user portable preferences grow over time.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dietNoOverride diet: any | high-protein | keto | pescatarian | vegetarian | vegan
brandNoFilter to a brand: HelloFresh | Factor
limitNoMax recommendations
agent_idNoYour agent id (claude/gpt/grok/gemini). With profile_hash, the recommendation is written into portable agent memory.
max_sodiumNoMaximum sodium mg
min_proteinNoMinimum protein grams
max_caloriesNoMaximum calories
profile_hashNoBridge profile hash from /p/{hash}. If given, constraints are read from the user profile.
ready_to_eatNoOnly ready-to-eat (Factor) meals — no cooking
exclude_allergensNoAllergens to avoid, e.g. ["dairy","shellfish"]

TDQS

A4.3/5.0
Behavior4/5

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

The description discloses that it reads the persistent profile, scores meals, returns ranked picks with a buy URL and signature, and optionally writes to cross-AI memory. With no annotations provided, this covers key behavioral traits.

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 four sentences, each adding value: purpose, mechanism, output format, and optional side effect. It is front-loaded and efficient, though slightly lengthy for a brief summary.

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?

The description sufficiently explains the tool's operation for an AI agent given 10 parameters and no output schema. It covers input usage and output structure (ranked picks, URL, signature), lacking only explicit return field details.

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% with good parameter descriptions, and the text adds context (e.g., profile_hash reads from /p/{hash}, agent_id enables memory writes), enhancing understanding beyond the schema.

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 clearly states the tool recommends meals matched to a user bridge profile, explains the process (reading profile, scoring, returning ranked picks with buy URL and signature), and distinguishes itself from sibling tools by focusing on meal recommendation rather than pricing or search.

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?

The description indicates when to use the tool (recommending meals based on a user profile) and briefly mentions optional memory writing, but does not explicitly state when not to use it or list alternative tools for different tasks.

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

All grocery toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation5/5

Each tool targets a specific aspect of food data: prices, nutrition, recalls, dietary filters, supply chain, etc. Overlaps are minimal and clearly differentiated by scope, such as full nutrition vs. ingredient lists.

Naming Consistency5/5

All tools consistently use the 'food_' prefix followed by a descriptive snake_case term. While the stems vary between nouns and verbs, the pattern is uniform and predictable.

Tool Count5/5

With 18 tools, the server comprehensively covers the grocery domain including prices, nutrition, recalls, dietary needs, supply chain, and more. Each tool serves a distinct purpose without being overwhelming.

Completeness5/5

The tool set is remarkably complete, covering search, detailed product info, price comparisons across supply chain, dietary constraints, household meal planning, recalls, receipts, and data source transparency. No critical gaps apparent.

Resources