Vaultbeat MCP Server

Overview Schema Source Related Servers Discussions Admin

Add to food log

log_food_append

Append meals to a day's food log without deleting existing entries. Use for logging a forgotten snack or adding dinner to an already-logged day.

Instructions

Add meals to a day WITHOUT touching what is already logged (agent write).

This tool cannot delete anything you did not send. Your meals are appended to whatever the day already holds; a meal whose name matches an existing meal gets its items appended to that meal. This is the right tool for "log the snack I forgot" / "add dinner to today" — which is almost every follow-up write of the day.

Reach for log_food_entry ONLY when you intend the supplied meals to become the day's ENTIRE log and everything else to be deleted.

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_entry's copy]

This tool deliberately cannot set the day's note: that field is replace-only, and a tool that promises to delete nothing must not carry an exception. Use log_food_entry to change it.

The result is the same shape log_food_entry returns. replaced_meals is always [] here — that empty list is the receipt that this call deleted nothing. Encrypted end-to-end before it ever leaves this machine.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`date`	Yes
`meals`	Yes

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?

The description goes well beyond the annotations: it explains the append semantics, the merge behavior for matching meal names, the guarantee that nothing is deleted, the always-empty replaced_meals receipt, the inability to set the day's note, and end-to-end encryption. It also discloses the persistence of estimated nutrition values and the risk of confident wrong estimates. This is rich behavioral context that annotations (which only say readOnlyHint=false, destructiveHint=false) do not provide.

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 long but every paragraph earns its place: append semantics, sibling routing, parameter shapes, photo estimation guidance, and the note-field limitation. The photo-estimation paragraph is somewhat tangential to the tool's core mechanics but is relevant because this tool persists estimates. The structure is front-loaded with the most critical semantic (append, not replace).

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 2-parameter tool with 0% schema coverage, the description is complete: it covers both parameters, the return shape, the deletion guarantee, the sibling distinction, and the persistence implications. The output schema exists and the description references its shape ('same shape log_food_entry returns'), so return values need no further explanation.

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 the full burden. It explains date as the LOCAL calendar day 'YYYY-MM-DD', and gives a full shape for meals with an example. It also documents that everything but food is optional, that snake_case aliases are accepted, and that estimated nutrition should go into structured fields. This fully compensates for the empty 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 opens with a specific verb and resource ('Add meals to a day WITHOUT touching what is already logged') and immediately distinguishes itself from the sibling log_food_entry. It clearly states the append semantics and names the exact use cases ('log the snack I forgot' / 'add dinner to today').

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 explicitly says when to use this tool vs log_food_entry: use this for appending, use log_food_entry only when the supplied meals should become the day's ENTIRE log. It also explains what this tool cannot do (set the day's note) and routes that to log_food_entry. This is explicit when/when-not guidance.

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