NexRex

Recent activities

get_activities

Read-onlyIdempotent

Get an athlete's activities from the last days, newest first: completed activities with their measurements (distance, duration, pace, heart rate, effort) and scheduled or skipped plan workouts. Use it for what the athlete did; get_week_workouts gives one calendar week of the plan for compliance. Filters by type, subtype and status. Returns up to limit rows, fewer when the page reaches the response size bound; next_cursor reads the next page with the same filters. Route maps and media are omitted, and a coach sees only what the athlete shares. Strength rows carry session_kg_loads in kilograms.

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_activities"
  }
}

Input Schema

Name	Required	Description
`days`	No	Trailing days to read, 1-365.
`limit`	No	Activities per page, 1-100.
`cursor`	No	next_cursor from the previous page of this tool called with the same arguments; omit for the first page.
`statuses`	No	Keep only these statuses; omit for all.
`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.
`activity_type`	No	Activity type, for example run, bike, swim, walk, hike or strength; omit for every type.
`activity_sub_types`	No	Exact stored subtypes, for example easy_run, tempo_run, long_run or interval_run (planned workouts may store easy-run, tempo-run).

Output Schema

Name	Required	Description
`error`	No
`status`	No
`filters`	No
`message`	No
`privacy`	No	Present when the athlete's settings withhold data.
`warnings`	No
`next_step`	No	What can be done next, for example after a failure.
`activities`	No
`athlete_id`	No
`pagination`	No
`next_cursor`	No	Reads the next page; null on the last page.
`reason_code`	No
`total_weeks`	No
`user_content`	No	Fields in this result that people wrote.
`weeks_returned`	No
`truncated_fields`	No	Lists cut to fit one response: rows returned and total.
`generated_content`	No	Fields in this result that NexRex's AI wrote.
`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.8/5.0

Behavior5/5

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

Beyond the annotations (readOnly/idempotent/non-destructive/closed-world), the description discloses pagination behavior ("Returns up to `limit` rows, fewer when the page reaches the response size bound"), cursor continuation with unchanged filters, deliberately omitted data (route maps and media), an authorization boundary ("a coach sees only what the athlete shares"), and a unit note for strength rows (session_kg_loads in kilograms). These are exactly the traits annotations cannot express.

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?

The definition is front-loaded: purpose and ordering come first, then sibling routing, then filters, paging, omissions and the strength-unit caveat. It is dense with no filler, though the opening sentence is long enough that a reader must parse several clauses to extract the scope.

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 7-parameter read tool with an output schema (so return shapes need not be described), it covers the scope, ordering, paging contract, data omissions, and the coach/athlete visibility model. Nothing an agent needs to call it correctly or interpret a short page is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already defines days, limit, cursor, statuses, activity_type and activity_sub_types; the description mostly echoes them. It does add real meaning for `limit` by framing it as an upper bound that can return fewer rows at the response-size bound, and it clarifies that `cursor` must be reused with identical filters and that subtype filtering is by exact stored values. That is a modest but genuine increment over the schema.

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?

The opening sentence states a specific verb and resource ("Get an athlete's activities"), the time window, the ordering ("newest first"), and the exact row population (completed activities with measurements plus scheduled/skipped plan workouts). It then names the sibling it is not — "get_week_workouts gives one calendar week of the plan for compliance" — so an agent can separate the two 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?

Usage is stated positively ("Use it for what the athlete did") and the alternative is named with the condition that selects it (week-of-plan compliance work belongs to get_week_workouts). No exclusion or routing decision is left to inference.

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?