Vaultbeat MCP Server

Overview Schema Source Related Servers Discussions Admin

Log food (replaces day)

log_food_entry

Destructive

Log or replace a full day's food intake, including meals and nutrition. Missing meals are deleted, so use the append tool to add entries.

Instructions

Log one day's food intake on the owner's behalf (agent write).

⚠️ THIS TOOL DELETES. The supplied meals become the day's ENTIRE log — any meal you don't re-send is silently deleted. If you meant to ADD to a day rather than replace it, STOP and call log_food_append instead; it cannot delete anything.

(merge=True still does the same thing as log_food_append and keeps working for callers that already use it. New callers should use the separate tool: which one you called is visible to the owner, a flag buried in the arguments is not.)

The result carries replaced_meals — the meals this call deleted. If that list is non-empty and you did not intend to replace the day, you just destroyed them; re-send them with merge=True.

note=None LEAVES THE EXISTING NOTE ALONE in both modes (pass note="" to clear it).

date is the LOCAL calendar day, "YYYY-MM-DD". meals is a list of {name?, timeOfDay?, items: [...], note?} where each item is {food, portion?, note?, kcal?, proteinGrams?, fatGrams?, carbGrams?}, e.g. [{"name": "lunch", "items": [{"food": "香蕉", "portion": "1 根", "kcal": 105}]}]. Everything but food is optional so a rushed "just log 香蕉" still works; when you DO estimate nutrition at logging time, put the numbers in the structured fields (snake_case aliases like protein_g are accepted) — they persist for later sessions instead of being re-guessed each read.

ESTIMATING FROM A PHOTO: look for something of known size in the frame first — a utensil, a hand, a coin, the rim of a standard plate — and calibrate the portion against it. With no such reference an image cannot settle portion size, and portion size is what the whole estimate rests on. In that case say so in your reply and give a range rather than a precise-looking number. These values are persisted and summed into daily totals later, so a confident "650 kcal" that is wrong does more damage than "roughly 500-700, nothing in frame to judge size by" — the first silently poisons a week of trends, the second invites a correction. [keep the photo-estimation paragraph above in sync with log_food_append's copy] Encrypted end-to-end before it ever leaves this machine.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`date`	Yes
`note`	No
`meals`	Yes
`merge`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.9.1Oct 3, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
First observedv0.8.1Sep 23, 2026

TDQS

A5/5.0

Behavior5/5

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

Annotations declare destructiveHint=true, and the description goes well beyond that by naming exactly what is destroyed (any meal not re-sent), how the caller can detect it (replaced_meals in the result), the note=None vs note="" semantics, the deprecation status of merge, and that data is encrypted end-to-end. This is exactly the kind of context annotations cannot carry.

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

Conciseness5/5

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

It is long, but the length is justified: the destructive warning is front-loaded in caps before any detail, and each subsequent paragraph covers a distinct failure mode (accidental deletion, note clearing, date locality, photo estimation). The only waste is the leaked editorial note about keeping the photo paragraph in sync with log_food_append, which is boilerplate for maintainers rather than agents.

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 destructive, 4-parameter write tool with an output schema, the description covers the risks an agent needs to call it safely: replacement semantics, recovery via replaced_meals, note handling, and estimation guidance. Return-value shape is left to the output schema, which is the right division of labor.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the full burden and does: date format and timezone semantics, the nested meals shape with a concrete example, which fields are optional, accepted snake_case aliases, and the non-obvious note=None behavior. merge is also explained as a legacy alias.

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 states a specific verb and resource ('Log one day's food intake on the owner's behalf') plus the critical scope fact that it replaces the whole day rather than adding to it. It explicitly names the sibling it is not (log_food_append), so an agent can route correctly without opening either schema.

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?

It gives an explicit when-not rule with a stop condition ('If you meant to ADD to a day rather than replace it, STOP and call log_food_append instead; it cannot delete anything'), and explains the legacy merge=True path and why new callers should prefer the separate tool. Nothing about tool selection is left to inference.

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