Skip to main content
Glama
Fino-wind

Vaultbeat MCP Server

Log note (replaces note)

log_note
Destructive

Write a free-text note for a day, replacing any prior note of the same kind and date. Use for mood or general events; to add without deleting, choose the append tool.

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.

For symptoms, use log_note_append. Discomfort shows up in installments across a day (nausea at noon, dizziness at night), so the second write of the day is the normal case, not the exception — and this tool would replace the morning's entry with the evening's.

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNo
kindNogeneral
textYes
mergeNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.8.1

TDQS

A5/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 goes far beyond that: it states one note per (kind, day), that text becomes the entire contents, that overwritten notes are silently deleted, and that replaced_text reveals the deletion. It also discloses merge=True compatibility, refusal of iOS-authored sleep/menstrual notes, end-to-end encryption, and how to recover a destroyed note.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but the destructive behavior makes the length justified. It is front-loaded with the core action, then immediately warns about deletion with a bold callout. Subsequent paragraphs each add independent value: alias behavior, recovery instructions, symptom use-case, date semantics, and encryption. The structure keeps high-risk information prominent.

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 tool's destructive semantics, 4 parameters, 0% schema coverage, and output schema, the description covers everything an agent needs: purpose, parameter semantics, when to choose the sibling, deletion consequences, recovery via merge=True, output meaning, and privacy. Nothing material is missing.

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%, and the description fully compensates. It explains kind values (mood vs general), date as LOCAL calendar day YYYY-MM-DD with default today, text as replacing the entire note, and merge=True as equivalent to log_note_append. It even clarifies the output field replaced_text. Every parameter and the key return value gets meaningful semantic context.

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 first sentence states a specific action and resource: "Log a free-text note on the owner's behalf (agent write)." It also differentiates from siblings like log_note_append and get_notes by describing the note-taking role and the kind values it supports. The description makes it unmistakable what this tool does.

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 tells when to use this tool versus log_note_append: "If you meant to ADD to a day rather than replace it, STOP and call log_note_append instead" and "For symptoms, use log_note_append." It also warns that new callers should prefer the separate visible tool over the buried merge=True flag. This is exemplary when-to-use guidance.

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