Vaultbeat MCP Server

Overview Schema Source Related Servers Discussions Admin

Notes

get_notes

Read-onlyIdempotent

Decrypt recent free-text day, sleep, menstrual, mood, or general notes locally; filter by kind or partner to analyze patterns alongside same-day health metrics.

Instructions

Decrypt recent free-text notes (day annotations) locally.

SENSITIVE free text. Each note carries owner_user_id (who wrote it), target_kind, and target_date (the local day it annotates) — join against the same-day metric data for pattern analysis. Kinds: "sleep" | "menstrual" are written manually in the iOS app by either partner (e.g. "昨晚舍友很吵" on a sleep day), and "day" is what the person wrote about the day itself in the app's notes list (app 1.3.0+); "general" is agent-authored via log_note; "mood" notes are ones an AI wrote before moods moved to get_state_of_mind — read them here, write no new ones. Pass target_kind to filter. Stays on-device, never re-exported.

Returns notes about YOU by default. partner=true returns notes about your partner: the ones they wrote themselves and shared, plus the ones your AI recorded about them (about: "partner", written with log_note_append(partner=true)).

Carries a coverage block: quote coverage.days_covered (distinct days, not the row count) and coverage.span_days beside any average or trend. coverage.window_satisfied: false alone does NOT mean a short history: it is also false when older days exist beyond your window. 🔴 Before saying how far back someone's data goes, read coverage.more_available: true means this server can decrypt days OLDER than first_day that your limit left behind — re-read with a larger limit, or quote coverage.oldest_available as the real start of their history. Never report a limit-shaped window as the extent of their data.

Input Schema

Name	Required	Description	Default
`fresh`	No
`limit`	No
`partner`	No
`target_kind`	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.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the readOnly/idempotent/closed-world annotations: states data stays on-device and is never re-exported, flags the content as SENSITIVE free text, and warns about the coverage-block semantics (days_covered vs row count, window_satisfied ambiguity, more_available meaning days older than first_day exist). This is exactly the behavioral context annotations cannot carry.

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 the core purpose and every section (kinds, partner scope, coverage warnings) adds decision-relevant information, so the length is largely earned. Structure suffers from awkward mid-sentence line breaks and some density, but there is little true filler.

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?

An output schema exists, yet the description still explains the coverage block an agent must quote correctly and the more_available trap that prevents misreporting history extent. Combined with the kind taxonomy and partner scoping, an agent has everything needed to call and interpret this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry parameter meaning and largely does: it enumerates the target_kind values and their provenance, defines partner=true, and implies limit's role via the 'limit-shaped window' warning and 're-read with a larger limit'. The fresh parameter is never explained, which is the one gap.

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 ('Decrypt recent free-text notes (day annotations) locally') and immediately distinguishes itself from siblings by explaining that mood notes live in get_state_of_mind and new notes are written via log_note/log_note_append. An agent can tell exactly what this tool retrieves and what it does not.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear routing context: pass target_kind to filter, use partner=true for partner-authored/partner-about notes, read legacy mood notes here but write no new ones. It stops short of a crisp when-to-use-vs-alternative rule (e.g. no explicit 'use get_notes vs get_state_of_mind when...'), but the implicit guidance is strong.

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