Vaultbeat MCP Server

Overview Schema Source Related Servers Discussions Admin

Log food (replaces day)

log_food_entry

Destructive

Replace a day's complete food log with the specified meals, permanently deleting any entries not included. Use to overwrite an entire day's intake.

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.

First observedv0.8.1Sep 23, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Even though annotations already set destructiveHint=true, the description adds crucial behavioral detail: this tool silently deletes any meal not re-sent, merge=True behaves like log_food_append, note=None preserves the existing note, and the call is encrypted end-to-end. It also warns about the replace-vs-append mistake and what the result's replaced_meals field means.

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 front-loaded with the critical deletion warning and organized into focused paragraphs. It is longer than strictly necessary, and the maintainer note about keeping photo-estimation copy in sync is noise for an agent, but nearly every other sentence adds operational value.

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 the destructive nature and four parameters, the description is remarkably complete: it covers all parameters, the exact deletion semantics, the alternative tool, merge behavior, note handling, output's replaced_meals, photo-estimation pitfalls, and persistence of nutrition values. An agent has everything needed to invoke it safely and correctly.

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 carries full responsibility for parameter semantics. It thoroughly explains date as 'LOCAL calendar day, YYYY-MM-DD', gives the meals structure with an example, documents note=None behavior vs. note="", and clarifies the merge parameter. It even covers optional item fields and snake_case aliases, going well beyond the bare 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 states a specific action and resource: 'Log one day's food intake on the owner's behalf' and the title adds 'replaces day'. It explicitly contrasts itself with log_food_append, so an agent can distinguish the destructive replacement behavior from appending without opening the sibling tool.

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?

The description gives clear when-to-use vs. when-not-to-use guidance: 'If you meant to ADD to a day rather than replace it, STOP and call log_food_append instead'. It also explains the merge=True alias and directs new callers to the separate tool, leaving no ambiguity about the preferred alternative.

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