Mise — Meal Planner, Grocery List & Calories

Calorie Counter & Food Diary

log_calories

Log what I ate and count calories. Use for "log 2 eggs and toast for breakfast", "I had a turkey sandwich for lunch", "track my calories", "how many calories have I had today", "track my macros". Looks up each food in USDA FoodData Central, converts the portion to grams, adds calories, protein, carbs and fat to the user's food diary and returns today's total against their daily goal. Send foods with a quantity and US unit (each, cup, tbsp, oz, slice). Call with no foods to read today's totals. Keep the returned diary_id and pass it on later calls.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "log_calories"
  }
}

Input Schema

Name	Required	Description	Default
`date`	No	YYYY-MM-DD in the user's local time. Defaults to today (UTC).
`meal`	No		snack
`foods`	No	What the user ate, e.g. [{"name":"banana","quantity":1,"unit":"each"},{"name":"peanut butter","quantity":2,"unit":"tbsp"}].
`recipe`	No	Log servings of a recipe from plan_week or generate_recipe.
`diary_id`	No	Food diary id from an earlier log_calories call. Omit on first use; a new diary is created. Remember and reuse it.
`daily_goal`	No	Daily calorie goal; saved on the diary.

Output Schema

Name	Required	Description
`day`	Yes
`date`	Yes
`logged`	Yes
`diary_id`	Yes
`nutrition_source`	Yes
`unresolved_foods`	Yes	Ingredients that could not be matched to USDA FoodData Central; their calories are NOT included. Ask the user for a weight (oz/g) or a clearer name.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 21, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare mutating, open-world, non-idempotent, non-destructive, and the description adds real context beyond them: external USDA lookups, unit-to-gram conversion, persistent diary state, macro accumulation, and the returned total versus daily goal. It omits failure behavior for unmatched foods and any latency or rate context for the open-world lookups.

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 user-facing purpose and example phrasings, then mechanics, then the stateful diary instruction. It is a single dense paragraph; a bit of structure or trimming of near-duplicate unit lists would improve scanability, but every sentence carries information.

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?

With six optional parameters, nested food objects, and an output schema present, the description covers the essential contract: stateful diary creation and reuse, goal comparison, and recipe logging. Missing only edge-case behavior (unknown food, unit mismatch) that an agent would want before relying on it.

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 83%, so the baseline is 3, but the description adds value: the required quantity + US unit shape for foods, the empty-foods convention for reading, and the diary_id carry-forward rule. It does not clarify that an empty foods array silently becomes a read rather than an error in a mutation tool's terms, nor the date/meal defaults.

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?

States a specific verb and resource (log foods, count calories) plus the mechanism (USDA FoodData Central lookup, macro addition to a diary) and the dual read/write shape (no foods = read today's totals). An agent can distinguish this from plan_week or generate_recipe, which produce plans/recipes rather than diary entries.

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?

Gives concrete trigger utterances ("log 2 eggs and toast", "how many calories have I had today") and an explicit read-mode instruction ("Call with no foods to read today's totals") plus the diary_id reuse rule. It does not explicitly exclude meal planning, which belongs to the siblings, so a small routing gap remains.

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

All Mise — Meal Planner, Grocery List & Calories 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?