NexRex

Weekly workouts

get_week_workouts

Read-onlyIdempotent

Get the planned workouts of one calendar week (Monday to Sunday) from an athlete's active plan, with completion status, to check plan compliance or answer what is on the schedule. Use get_activities for what the athlete actually recorded over a longer window. When the athlete has several active plans and none is named, the result has status needs_plan_choice with active_plans.

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": {
      "athlete_id": "<athlete_id>"
    },
    "name": "get_week_workouts"
  }
}

Input Schema

Name	Required	Description
`athlete_id`	Yes	The athlete's user id: get_current_user's athlete_id for the connected account, or an id from get_coach_athletes or find_athlete.
`week_offset`	No	0 = this week, 1 = next week, -1 = last week.
`week_start_date`	No	Any date in the wanted week, YYYY-MM-DD or ISO 8601; it replaces week_offset. Weeks start on Monday in the athlete's timezone.
`plan_instance_id`	No	The plan to read when the athlete has several active plans (active_plans in a needs_plan_choice result).

Output Schema

Name	Required	Description
`count`	No
`error`	No
`reason`	No
`status`	No
`message`	No
`privacy`	No	Present when the athlete's settings withhold data.
`warnings`	No
`workouts`	No
`next_step`	No	What can be done next, for example after a failure.
`plan_name`	No
`athlete_id`	No
`resolution`	No
`next_cursor`	No	Reads the next page; null on the last page.
`reason_code`	No
`total_weeks`	No
`week_number`	No
`week_offset`	No
`active_plans`	No
`user_content`	No	Fields in this result that people wrote.
`week_end_date`	No
`total_workouts`	No
`weeks_returned`	No
`week_start_date`	No
`plan_instance_id`	No
`truncated_fields`	No	Lists cut to fit one response: rows returned and total.
`calendar_week_end`	No
`generated_content`	No	Fields in this result that NexRex's AI wrote.
`calendar_week_start`	No
`session_definitions`	No	Sessions that several rows of this result share by session_ref.
`content_block_fields`	No	Column names of every content_blocks row, nested blocks rows included.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 14, 2026

changedOutput schema / $defs / Activity / properties / content_blocks / anyOf

Previous value: -[
-  {
-    "items": {
-      "items": {
-        "anyOf": [
-          {
-            "type": "string"
-          },
-          {
-            "type": "integer"
-          },
-          {
-            "type": "number"
-          },
-          {
-            "type": "boolean"
-          },
-          {
-            "items": {
-              "anyOf": [
-                {
-                  "type": "string"
-                },
-                {
-                  "type": "integer"
-                },
-                {
-                  "type": "number"
-                },
-                {
-                  "type": "boolean"
-                },
-                {
-                  "type": "null"
-                }
-              ]
-            },
-            "type": "array"
-          },
-          {
-            "$ref": "#/$defs/LocalizedText"
-          },
-          {
-            "type": "null"
-          }
-        ]
-      },
-      "type": "array"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "items": {
+      "items": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "integer"
+          },
+          {
+            "type": "number"
+          },
+          {
+            "type": "boolean"
+          },
+          {
+            "items": {
+              "anyOf": [
+                {
+                  "type": "string"
+                },
+                {
+                  "type": "integer"
+                },
+                {
+                  "type": "number"
+                },
+                {
+                  "type": "boolean"
+                },
+                {
+                  "type": "null"
+                }
+              ]
+            },
+            "type": "array"
+          },
+          {
+            "$ref": "#/$defs/LocalizedText"
+          },
+          {
+            "items": {
+              "type": "array"
+            },
+            "type": "array"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "type": "array"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

changedOutput schema / $defs / Activity / properties / content_blocks / description

Previous value: -"Interval rows; each row's values follow content_block_fields."New value: +"Workout steps as rows whose values follow content_block_fields; an interval's blocks value is its nested steps as rows in the same columns."

changedOutput schema / properties / content_block_fields / description

Previous value: -"Column names of every content_blocks row."New value: +"Column names of every content_blocks row, nested blocks rows included."

First observedNov 12, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely new behavior: results carry completion status, weeks are Monday-start in the athlete's timezone, and a multi-plan situation returns a needs_plan_choice status with active_plans. It stops short of describing pagination or result volume, but that is minor for a single-week read.

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?

Three tight sentences: what it returns, the alternative to use instead, and the multi-plan edge case. The primary purpose is front-loaded and no sentence is filler.

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?

With an output schema present, return-value detail is unnecessary, and annotations cover safety. The description still supplies the disambiguation path, timezone/week convention, and sibling routing, leaving nothing an agent needs to call this correctly.

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 coverage is 100%, with athlete_id, week_offset, week_start_date, and plan_instance_id all documented including precedence of week_start_date over week_offset. The description's mention of unnamed plans producing needs_plan_choice largely restates what the plan_instance_id schema field already says, so it adds little beyond the structured data.

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 with precise scope: planned workouts for one calendar week (Monday to Sunday) from an athlete's active plan, including completion status. It is immediately distinguishable from get_activities, which the description explicitly characterizes as actual recorded activity over a longer window.

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?

Gives explicit use cases (check plan compliance, answer what is on the schedule) and names the alternative tool plus the condition that selects it (recorded vs. planned data, longer window). It also covers the ambiguous-plan case and points to the parameter that resolves it.

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

All NexRex tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?