Nutrition MCP

Analyze a meal plan

analyze_plan

Read-onlyIdempotent

Analyzes a multi-day meal plan and assesses its daily average.

Every ingredient is resolved and converted, then totaled by dish, meal, and day, up to 400 ingredients. The assessment is of the daily average, not the multi-day sum. per_day has each day's totals, shopping_list totals ingredients at full recipe quantities, and failed lists ingredients missing from the totals. The detail breakdown is large for a full week.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "days": "<days>"
    },
    "name": "analyze_plan"
  }
}

Input Schema

Name	Required	Description
`days`	Yes	Days, 1-14, each {"day": "Monday", "meals": [{"name": "dinner", "dishes": [...]}]}. A dish is {"name": "Moussaka", "servings": 6, "eaten": 1, "ingredients": [...]}, where servings is the recipe yield and eaten is how many of those servings this person has.
`detail`	No	Include the per-dish, per-ingredient breakdown. Defaults to false.
`include_shopping_list`	No	Include total ingredient quantities to buy. Defaults to true.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4/5.0

Behavior5/5

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

Beyond the annotations (which already cover read-only, idempotent, closed-world, non-destructive), the description discloses real behavioral traits: a hard 400-ingredient ceiling, that ingredients are resolved and converted before totaling, that totals roll up by dish/meal/day, that shopping_list uses full recipe quantities rather than eaten amounts, that unresolvable ingredients are surfaced in `failed`, and that the detail breakdown is large for a full week. These are exactly the operational facts an agent needs before calling.

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?

Front-loaded with the purpose, then progressively more operational detail; no filler sentences. The output-field sentences are terse fragments, which reads efficiently but slightly compresses the prose flow.

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?

For a nested-input analysis tool with an output schema, this is close to complete: input shape, the 400-item cap, the daily-average framing, and the meaning of per_day/shopping_list/failed are all covered. The one omission is the failure mode when the ingredient cap is hit, which matters for a 14-day plan.

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 genuine semantics beyond the schema: shopping_list totals at full recipe quantities (i.e., not scaled by `eaten`), and the `detail` output is expensive for a full week. The only gap is that it never says what happens when the 400-ingredient limit is exceeded.

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?

"Analyzes a multi-day meal plan and assesses its daily average" gives a specific verb plus resource and a scope (multi-day) that separates it from analyze_meal and analyze_recipe without naming them. The purpose is unmistakable, though sibling differentiation is only implied by the word "multi-day."

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

Usage Guidelines3/5

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

Usage is implied by the scope words (multi-day plan, daily-average assessment), but there is no explicit when-to-use versus analyze_meal/analyze_recipe, no prerequisites, and no stated exclusions. The clarification that the assessment is of the daily average rather than the multi-day sum is about interpretation of results, not about when to pick this tool.

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

All Nutrition MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?