Skip to main content
Glama
fulcradynamics

Fulcra MCP Server

by fulcradynamics
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

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.

Input Schema

NameRequiredDescriptionDefault
end_timeYesthe ending time of the period. Must include tz (ISO8601).
start_timeYesThe starting time of the period. Must include tz (ISO8601).
fulcra_useridNoRetrieve data for another Fulcra user (if shared)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.18.7
    • 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
  2. Changed8 schema fields changedv1.1.0
    • 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"
  3. First observed

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

Other Tools