enduraw-MCP

get_enduraw_records_progression

Retrieves an athlete's personal records and progression curves for standard running distances, with historical milestones and an optional distance filter.

Instructions

Retrieves the personal records and progression curves computed by Enduraw on standard benchmark distances (1k, 5k, 10k, 15k, Half-Marathon, 30k, Marathon) with historical milestones.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_enduraw_records_progression"
  }
}

Input Schema

Name	Required	Description	Default
`distance`	No	Optional target distance filter ('1k', '5k', '10k', '15k', 'semi', '30k', 'marathon')

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 3, 2026

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. 'Retrieves' and 'computed by Enduraw' imply a read of precomputed derived data rather than raw activity streams, which is useful. However it says nothing about permissions, latency, pagination, or whether a missing distance returns all distances.

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?

One front-loaded sentence with no filler; the parenthetical distance list is dense but earns its place by enumerating the benchmark set. Slightly overpacked rather than bloated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single optional-parameter read tool with no output schema and no annotations, the description covers what is returned conceptually but not the shape of records/progression data or the default when no distance is supplied.

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 optional 'distance' parameter already documents its accepted values. The description adds little beyond the schema, and notably names 'Half-Marathon' where the schema value is 'semi', a small inconsistency the agent must resolve on its own.

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 ('Retrieves') and resource ('personal records and progression curves'), and scopes the data to Enduraw's computed benchmarks with historical milestones. No sibling tool mentions records or progression, so it is distinguishable, though the description never explicitly contrasts itself with get_enduraw_performance_profile or get_enduraw_matrix.

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 only implied: the agent can infer this is the tool for PRs and milestone progression, but there is no statement of when to prefer it over performance_profile or slope_and_cadence, and no prerequisites or exclusions.

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