Fulcra MCP Server

Get Workouts

get_workouts

Read-only

Retrieve workout details for a specified time period, including timezone-aware timestamps to support accurate local-time review.

Instructions

Get details about the workouts that the user has done during a period of time. Result timestamps will include time zones. Always translate timestamps to the user's local time zone when this is known.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "start_time": "<start_time>",
      "end_time": "<end_time>"
    },
    "name": "get_workouts"
  }
}

Input Schema

Name	Required	Description
`end_time`	Yes	the ending time of the period. Must include tz (ISO8601).
`start_time`	Yes	The starting time of the period. Must include tz (ISO8601).
`fulcra_userid`	No	Retrieve data for another Fulcra user (if shared)

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv1.18.7Oct 23, 2026

removedInput schema / properties / fulcra_userid / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / fulcra_userid / default
```
Removed value: -null
```
addedInput schema / properties / fulcra_userid / type
```
Added value: +"string"
```

changedOutput schema / (root)

Previous value: -{
-  "properties": {
-    "result": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "type": "object",
-  "x-fastmcp-wrap-result": true
-}New value: +null

Changed8 schema fields changedv1.1.0Oct 7, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

addedInput schema / properties / end_time / description

Added value: +"the ending time of the period. Must include tz (ISO8601)."

removedInput schema / properties / end_time / title
```
Removed value: -"End Time"
```

addedInput schema / properties / fulcra_userid

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Retrieve data for another Fulcra user (if shared)"
+}

addedInput schema / properties / start_time / description

Added value: +"The starting time of the period. Must include tz (ISO8601)."

removedInput schema / properties / start_time / title
```
Removed value: -"Start Time"
```
removedOutput schema / properties / result / title
```
Removed value: -"Result"
```
removedOutput schema / title
```
Removed value: -"_WrappedResult"
```

First observedAug 15, 2025

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already establish readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral context: result timestamps carry time zones and must be translated to the user's local zone, which is an output-handling instruction an agent would otherwise get wrong. It does not mention result caps or pagination, keeping it from a 5.

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?

Two sentences, zero padding, with the core purpose front-loaded and the timezone handling note following as a distinct, actionable instruction.

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?

With no output schema, the description does at least tell the agent what to expect about timestamp formatting, and all three params are covered by the schema. It leaves open the shape of a workout record (fields, volume of results, ordering), which would matter for a data-returning tool with no output schema.

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 100%, so start_time, end_time, and fulcra_userid are already fully documented, including the ISO8601 tz requirement. The description's 'period of time' phrasing restates the schema rather than adding syntax or constraint detail, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get details about the workouts') plus the scope ('during a period of time'), which cleanly separates it from siblings like get_sleep, get_location, and get_calendar_events. It stops short of explicitly naming those alternatives, so it earns a 4 rather than a 5.

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

Usage Guidelines2/5

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

The description never says when to reach for this tool versus get_records, get_time_series, or get_data_updates, all of which can also return time-ranged data. The time-window framing implies the use case but provides no exclusions or prerequisites.

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

Deploy Server