Skip to main content
Glama

get_enduraw_athlete_profile

Retrieves an Enduraw athlete's profile, settings, biometrics, and account plan entitlements so AI assistants can tailor training insights and account-aware guidance.

Instructions

Retrieves the Enduraw athlete profile, settings, biometrics (height, weight, age) and account plan/entitlements.

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

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations supplied, the description carries the full behavioral burden; "Retrieves" at least establishes this is a non-mutating read. It also discloses the payload's scope (profile, settings, biometrics, entitlements), but says nothing about authentication/entitlement requirements, behavior when no profile exists, or whether the call is expensive or rate-limited.

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?

A single front-loaded sentence with the verb first and the returned data grouped in a parenthetical. No filler, no repetition of the tool name as a standalone claim, and nothing an agent must skip past to reach the substance.

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?

There is no output schema, so the description must convey return values, and it does so by naming the four data groups. For a zero-parameter read tool that is largely sufficient; the remaining gap is disambiguation from the sibling performance-profile tool, which an agent would need in order to choose correctly.

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?

The tool takes zero parameters, so there is no parameter semantics to explain; the baseline for a parameterless tool applies. The description correctly avoids inventing inputs and instead spends its words on what is returned.

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") plus the resource ("Enduraw athlete profile") and enumerates the contents returned: settings, biometrics, and plan/entitlements. That makes the scope clear, but it does nothing to distinguish itself from the closely named sibling get_enduraw_performance_profile, so an agent could plausibly pick either.

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?

There is no explicit when-to-use guidance, no prerequisites, and no named alternatives despite the presence of many near-neighbour tools (get_enduraw_performance_profile, get_enduraw_athlete_lab, get_enduraw_physio_tests). Usage is only inferable from the list of returned data, which is weak routing information.

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