Skip to main content
Glama
Fino-wind

Vaultbeat MCP Server

Log strength session (replaces day)

log_strength_entry
Destructive

Log a strength-training session for a date, replacing all existing exercises for that day. Omitted exercises are deleted; use the append tool to add exercises instead.

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 running uvx vaultbeat-apple-health@latest bind in a terminal.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateYes
noteNo
mergeNo
exercisesYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.9.1
    • addedInput schema / additionalProperties
      Added value: +false
  2. First observedv0.8.1

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true, but the description goes far beyond them: it explains exactly what is destroyed (unlisted exercises silently deleted), surfaces the replaced_exercises result field as a verification signal, documents note=None vs note="" semantics, and discloses encryption plus a bind/version prerequisite with remediation.

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-loads the destructive warning before any procedural detail, which is exactly right. It is long, and the merge=True parenthetical and the re-pair remediation could be trimmed slightly, but nearly every sentence conveys operational information an agent needs.

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 4-parameter write with a nested payload, zero schema coverage, and a sibling that does the opposite, the description covers deletion semantics, verification via replaced_exercises, parameter edge cases, and the auth prerequisite. Nothing an agent needs to call it correctly 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%, so the description carries the full burden and does: date is the LOCAL calendar day in YYYY-MM-DD, exercises is given a concrete nested example, note=None preserves the existing note while note="" clears it, and merge's legacy behavior is explained.

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 ('Log one strength-training session') and immediately distinguishes itself from the sibling log_strength_append by declaring it REPLACES the day. An agent can tell the two tools apart without opening 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?

Explicit when/when-not routing: 'If you meant to ADD to a day rather than replace it, STOP and call log_strength_append instead; it cannot delete anything.' It also explains the merge=True legacy path and why new callers should prefer the separate tool.

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