enduraw-MCP

get_enduraw_activity_analysis

Retrieves deep physiological and pacing analysis by activity ID—covering heart rate zones, weather impact, and quality score—or returns summary and quota data if analysis is pending.

Instructions

Fetches the deep physiological and pacing analysis of a specific activity by its activityId. Includes storyline, performance claims, quality score, heart rate zones distribution, and weather impact. If the activity has not been analyzed yet due to free tier quotas, returns summary data and quota info.

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": {
      "activity_id": "<activity_id>"
    },
    "name": "get_enduraw_activity_analysis"
  }
}

Input Schema

Name	Required	Description	Default
`activity_id`	Yes	The numeric activity ID (e.g. 19918148378)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 3, 2026

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description must carry the full behavioral burden. It does disclose important fallback behavior — unanalyzed activities return summary data plus quota info — which is real value, but it does not state read-only/safety characteristics, permission or auth requirements, or rate limits for a tool that is presumably a read.

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?

Three sentences, purpose front-loaded, and the returned-fields list and quota fallback each add information rather than filler. Minor redundancy between 'deep physiological and pacing analysis' and the field list keeps it just short of ideal.

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?

No output schema exists, so enumerating the payload contents is valuable, and the description also covers the degraded-quota response path — the two things an agent most needs to interpret results. Only the read-only/auth aspects are left implicit, which is minor for a fetch-by-ID tool.

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% and the single activity_id parameter is fully documented in the schema with a numeric example. The description adds no format or constraint detail beyond it, 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 ('Fetches') and resource ('deep physiological and pacing analysis of a specific activity') keyed by activityId, and enumerates the returned contents (storyline, quality score, HR zones, weather). It is clearly distinguishable from aggregate siblings like get_enduraw_matrix or get_enduraw_cardio_zones, though no sibling is named explicitly.

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

Usage Guidelines3/5

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

Usage is implied: call this to get deep analysis for one activity ID. The description explains the quota fallback case but gives no explicit when-to-use versus siblings (e.g. when to choose this over get_enduraw_pillar_deep_dive or get_enduraw_cardio_efficiency) and no stated prerequisites.

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