Vaultbeat MCP Server

Overview Schema Source Related Servers Discussions Admin

Notes

get_notes

Read-onlyIdempotent

Decrypt recent on-device free-text notes, filter by kind or partner, and join them with same-day health metrics for pattern analysis. Returns notes about you by default.

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); "mood" | "general" are agent-authored via log_note. 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

TableJSON Schema

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

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds substantial context beyond them: data stays on-device and is never re-exported, the text is SENSITIVE, and it gives detailed coverage-block semantics (days_covered, span_days, window_satisfied, more_available) that would otherwise mislead. It does not explain the 'fresh' parameter behavior, so not a full 5.

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 purpose and filter behavior are front-loaded, and each block earns its place. It is somewhat long due to the detailed coverage guidance and the red-flag warning, but that content is task-critical rather than padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be restated; the description focuses on semantics and interpretation instead. It is thorough for a read tool but leaves the 'fresh' parameter and the exact enum formatting ('sleep' | 'menstrual' | 'mood' | 'general' vs the untyped schema) unaddressed.

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

Parameters3/5

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

Schema description coverage is 0% across 4 parameters. The description compensates for partner (explains the about: 'partner' distinction) and target_kind (lists the valid kinds and the filter role), and touches limit indirectly via the larger-limit advice. However, 'fresh' is never explained, so the description only partially covers the undocumented parameters.

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 with scope: 'Decrypt recent free-text notes (day annotations) locally.' It also names the kind categories and the sibling write path (log_note/log_note_append), so an agent can distinguish this read tool from the logging tools without opening schemas.

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 usage context: default returns notes about YOU, partner=true returns notes about the partner, and 'Pass target_kind to filter.' It implies but does not explicitly state when NOT to use this versus alternatives like get_metric or correlate_metric_series, so it falls short of the top tier.

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