Vaultbeat MCP Server

Overview Schema Source Related Servers Discussions Admin

Add to note

log_note_append

Append a line to a day's note without overwriting existing content. Use it to add multiple daily events while preserving earlier entries.

Instructions

Add a line to a day's note WITHOUT erasing what is already there (agent write).

There is one note per (kind, day). This tool appends your text to it on a new line and cannot delete what is already written.

The second note of a day is the normal case, not the exception — a morning event and an evening one — and log_note would replace the first with the second. Symptoms do NOT go here: use log_symptom, which keeps type, severity and timing as fields a later analysis can match.

Reach for log_note ONLY when you intend your text to become the note's ENTIRE contents and whatever is there now to be deleted (e.g. correcting something you yourself wrote a minute ago).

kind="general" (the default and the only kind it writes) for day events worth joining against sleep/HRV later. A feeling and the story behind it go to log_state_of_mind and its note; this tool refuses kind="mood", and sleep, menstrual and day notes are written in the iOS app. date = LOCAL calendar day "YYYY-MM-DD" (default today). Read back via get_notes.

The result is the same shape log_note returns. replaced_text is always null here — that null is the receipt that this call deleted nothing. 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
`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?

Beyond the annotations, the description clearly discloses that the tool appends and cannot delete existing content, that `replaced_text` is always `null` as a receipt of no deletion, and that data is encrypted end-to-end. It also explains the `partner=true` storage and visibility model in concrete terms, which is valuable behavioral context not captured by the annotations.

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 definition is front-loaded with the key append-versus-replace distinction, and the remaining paragraphs add useful routing and behavioral context. It is longer than typical, but most of the length is justified by the number of sibling tools and the non-obvious partner/encryption semantics.

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?

The tool has an output schema, so the description need not fully document return values, but it still notes that `replaced_text` is always `null` here. Combined with the explicit alternative-routing guidance and complete parameter explanations, an agent has enough information to call this tool correctly without opening sibling schemas.

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 compensate, and it does: it defines `date` as a local calendar day in `YYYY-MM-DD` format, explains `kind="general"` as the default and only writable kind while refusing `kind="mood"`, and fully specifies `partner=true` versus default behavior. It also makes clear that `text` is appended as a new line.

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: it appends text to a day's note without erasing existing content. It also explicitly distinguishes this append behavior from `log_note`, which replaces the note, so an agent can choose correctly without inspecting 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 explicit when-to-use and when-not-to-use guidance, including telling the agent to use `log_note` only when replacing the entire note and to use `log_symptom` for symptoms. It further routes feelings to `log_state_of_mind`, explains the `kind="general"` default, and clarifies partner-note behavior.

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