Vaultbeat MCP Server

Overview Schema Source Related Servers Discussions Admin

Workouts

get_workouts

Read-onlyIdempotent

Decrypt recent workouts (type, duration, calories, distance) for personal activity tracking, with coverage data to make averages and trends accurate.

Instructions

Decrypt recent workout sessions (type, duration, calories, distance). Reads YOUR workouts; workouts are never shared between partners, so this tool has no partner option.

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

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
```

removedInput schema / properties / owner

Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "title": "Owner"
-}

First observedv0.8.1Sep 23, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already establish a safe read-only, idempotent profile, and the description layers on substantial non-obvious behavior: server-side decryption, the fact that the returned window is capped by `limit`, and the critical caveat that coverage.window_satisfied=false and coverage.more_available=true can mask older available history. This is exactly the kind of data-completeness behavior an agent cannot infer from structured fields.

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 purpose in the first sentence, then progressively narrower interpretation rules. The coverage guidance is dense and slightly repetitive ('Never report a limit-shaped window as the extent of their data' restates the more_available warning), but every block still carries actionable content.

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 no explanation, and the description nonetheless documents the coverage block's interpretation rules thoroughly. What's missing is the meaning of the `fresh` parameter and any routing versus the strength/metric siblings, which keeps it short of fully complete.

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%, so the description must carry the load. It functionally explains `limit` (it truncates older days, and a larger value reveals more history) but never mentions `fresh` at all, leaving one of two parameters entirely undocumented anywhere.

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 workout sessions') and enumerates the payload fields (type, duration, calories, distance), so the agent knows exactly what comes back. It also delimits scope by declaring workouts are never partner-shared, which separates it from the partner-aware siblings in this server.

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 context ('Reads YOUR workouts', no partner option) and detailed instructions on how to consume the result safely. It does not, however, say when to prefer this over adjacent siblings such as get_strength_log or get_metric, which is a real gap given the overlapping fitness-domain tools.

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