Vaultbeat MCP Server

Overview Schema Source Related Servers Discussions Admin

Log note (replaces note)

log_note

Destructive

Record a free-text mood or daily note for a specific day, replacing any existing note of that kind; content stays encrypted on your device.

Instructions

Log a free-text note on the owner's behalf (agent write).

For narratives that belong next to the metric data instead of in chat history: kind="mood" for emotional state ("为什么今天情绪低落"), kind="general" for day events worth joining against sleep/HRV later. (sleep/menstrual notes stay iOS-authored — this tool refuses them.)

⚠️ THIS TOOL DELETES. There is one note per (kind, day), and your text becomes its ENTIRE contents — anything already written for that kind+day is silently deleted. If you meant to ADD to a day rather than replace it, STOP and call log_note_append instead; it cannot delete anything.

(merge=True still does the same thing as log_note_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_text — the note this call deleted. If it is non-null and you did not intend to replace, you just destroyed that text; re-send it with merge=True.

Symptoms do NOT go here: use log_symptom, one call per symptom. A note is free text nothing can be matched against; a symptom entry keeps its type, severity and timing so it can later be lined up with sleep, food and heart rate. A note is for what surrounds it (mood, events, how a day went).

date = LOCAL calendar day "YYYY-MM-DD" (default today). Read back via get_notes (optionally target_kind="mood"/"general"). Encrypted end-to-end before it ever leaves this machine.

partner=true records a note ABOUT your partner ("she had a stomach ache this morning"). It is stored in YOUR account and sealed to you and this machine only — your partner's account is never touched, and it never mixes into your own notes: plain reads leave it out, get_notes(partner=true) returns it. Default false = a note about you.

Input Schema

TableJSON Schema

Name	Required	Default
`date`	No
`kind`	No	general
`text`	Yes
`merge`	No
`partner`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.9.1Oct 3, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
- addedInput schema / properties / partner
```
Added value: +{
+  "default": false,
+  "title": "Partner",
+  "type": "boolean"
+}
```
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?

Annotations declare destructiveHint=true, and the description goes well beyond that: it explains the one-note-per-(kind,day) model, that text becomes the ENTIRE contents, that existing text is silently deleted, the replaced_text recovery path, E2E encryption, and partner-account scoping. This is exactly the extra context a destructive tool needs.

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 purpose and the destructive warning, but the merge=True legacy explanation and the repeated deletion caveat make it longer than strictly necessary; still, each block targets a distinct failure mode so little is waste.

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?

Covers read-back via get_notes, the replaced_text output field (so no separate return-value explanation needed), encryption, and partner isolation — complete for a destructive 5-param tool with an output schema.

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 coverage is 0%, so the description carries full burden and does: date format ('YYYY-MM-DD', default today), kind values, text semantics (replaces, not appends), merge as a legacy alias, and partner=true meaning a note about the partner stored in the caller's own account.

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+resource ('Log a free-text note on the owner's behalf') and immediately distinguishes itself from siblings by naming log_note_append and log_symptom as the wrong destinations for certain content.

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?

Explicitly routes: narratives vs chat history, kind='mood' vs 'general', sleep/menstrual notes refused, add-intent should go to log_note_append, symptoms to log_symptom. When-to-use and when-not-to-use are both covered with concrete examples.

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