Vaultbeat MCP Server

Overview Schema Source Related Servers Discussions Admin

Log note (replaces note)

log_note

Destructive

Write a free-text daily note on the owner's behalf, replacing any existing note for that day and kind. Use for general day events, not moods or symptoms.

Instructions

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

For day events that belong next to the metric data instead of in chat history, worth joining against sleep/HRV later (kind="general", the default and the only kind this tool writes). A feeling does NOT go here, nor the story behind it: call log_state_of_mind, which keeps it as Apple Health's fields and has its own note for the why. This tool refuses kind="mood" — one feeling recorded twice, once structured and once as free text, is what that kind produced. (sleep, menstrual and day notes are written in the iOS app — refused too.)

⚠️ 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 (events, how a day went).

date = LOCAL calendar day "YYYY-MM-DD" (default today). Read back via get_notes (optionally target_kind="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 for you and your own AI machines only (the Vaultbeat app passes it on to your other paired machines) — never for your partner or their AI. 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

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

Output 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 already flag destructiveHint=true, but the description goes far beyond: it explains the one-note-per-(kind, day) model, that text becomes the ENTIRE contents and prior text is silently deleted, that replaced_text in the result signals an unintended destruction, and that content is end-to-end encrypted before leaving the machine.

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?

Purpose and the destructive warning are front-loaded and the prose is organized into scannable blocks, but it is long and repeats itself — the replace-vs-append danger is stated in the warning, again in the merge paragraph, and again in the replaced_text paragraph.

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, five-parameter write tool this covers everything an agent needs: routing to siblings, destruction semantics, date format, partner isolation, read-back path via get_notes, and recovery guidance. An output schema exists, yet the description still usefully calls out the one field that matters (replaced_text).

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 the full burden and does: date format and default, kind default and the only accepted value, text's replace-not-append semantics, merge's back-compat behavior, and partner's storage/isolation semantics. All five parameters are given meaning beyond their bare names.

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 up front ('Log a free-text note on the owner's behalf') and immediately narrows scope: only kind='general' is written. It explicitly names what this tool is not (log_state_of_mind, log_symptom, log_note_append), so an agent can route correctly without opening any 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?

Explicit when-to-use and when-not-to-use rules: feelings go to log_state_of_mind, symptoms to log_symptom, additive writes to log_note_append, and kind='mood'/sleep/menstrual/day notes are refused. It even explains the routing mechanism (separate tool vs buried flag) and which is visible to the owner.

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