Vaultbeat MCP Server

Overview Schema Source Related Servers Discussions Admin

Log strength session (replaces day)

log_strength_entry

Destructive

Replace a day's strength-training session with new exercises, deleting any not re-sent. Append with merge instead. Encrypted end-to-end for Apple Health data.

Instructions

Log one strength-training session on the owner's behalf (agent write).

⚠️ THIS TOOL DELETES. The supplied exercises become the day's ENTIRE session — any exercise you don't re-send is silently deleted. If you meant to ADD to a day rather than replace it, STOP and call log_strength_append instead; it cannot delete anything.

(merge=True still does the same thing as log_strength_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_exercises — the names this call deleted. If that list is non-empty and you did not intend to replace the day, you just destroyed those exercises; re-send them with merge=True.

note=None LEAVES THE EXISTING NOTE ALONE (pass note="" to clear it).

date is the LOCAL calendar day the session happened, "YYYY-MM-DD". exercises is [{"name": "卧推", "sets": [{"weightKg": 30, "reps": 8}, ...]}, ...]. Encrypted end-to-end before it ever leaves this machine — this server never sends plaintext. Requires a bind made after this feature shipped (carries owner_user_id/owner_public_key_base64/owner_device_id from the pairing handshake); an older bind must re-pair by calling vaultbeat_start_binding then vaultbeat_poll_binding.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`date`	Yes
`note`	No
`merge`	No
`exercises`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.8.1Sep 23, 2026

TDQS

A5/5.0

Behavior5/5

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

Annotations already mark destructiveHint=true and readOnlyHint=false, but the description goes far beyond: it warns that unsent exercises are silently deleted, explains the replaced_exercises field in the result, details note=None behavior, and discloses end-to-end encryption and binding requirements. This is exactly the kind of context annotations cannot convey.

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 every sentence earns its place. The critical deletion warning is front-loaded, the alternative tool is named immediately, and subsequent paragraphs explain merge, note, date, exercises, encryption, and binding. No filler; the density is justified by the destructive risk.

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 write tool with encryption and binding prerequisites, the description covers all operational aspects: deletion semantics, merge behavior, note handling, input formats, security, and re-pairing steps. It even references the result field and sibling tools. An agent has everything needed to call it correctly and safely.

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 fully document parameters. It does: date format 'YYYY-MM-DD', exercises structure with a concrete example, note=None leaves existing note (pass note='' to clear), and merge=True behaves like the append tool. Every parameter is explained with behavioral nuance.

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 clearly states it logs one strength-training session, and immediately differentiates it from log_strength_append which adds without deleting. The phrase 'replaces day' in the title and the explicit warning make the destructive nature unambiguous. An agent can instantly tell this tool from its siblings.

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?

Explicitly instructs when to use this tool vs. log_strength_append: 'If you meant to ADD to a day rather than replace it, STOP and call log_strength_append instead'. Also explains merge=True compatibility and advises new callers to use the separate tool. No ambiguity remains.

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