Skip to main content
Glama
Sign In
coros-training-mcp

coros-training-mcp

by dholliday3
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Get Run Workout Schema

get_run_workout_schema

Retrieve the shared run-step schema for creating and updating COROS running workouts, including accepted step fields, intensity labels, presets, and pace input formats.

Instructions

Return the shared run-step contract used by create_run_workout and update_run_workout.

This includes:

  • the plain-step fields accepted by create_run_workout

  • the selector + patch fields accepted by update_run_workout

  • the checked-in live Training Hub intensity labels and their raw COROS presets

  • the human pace input format ('4:05-4:15/km', '5:30/mi') which expands into intensity_type=3 with ms/km intensity_value / intensity_value_extend

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

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.1

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it enumerates what the returned contract contains (plain-step fields, selector+patch fields, live Training Hub intensity labels with raw COROS presets) and explains the pace string expansion into intensity_type=3. It doesn't state that the call is read-only/no side effects, but for a zero-param retrieval tool the risk surface is minimal.

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?

Front-loaded with the one-sentence purpose before a structured bullet breakdown. The last bullet on pace format is longer and denser than the others but still earns its place by documenting a non-obvious input encoding.

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 inputs and an output schema exists, so the description only needs to orient the agent to what kind of contract is returned and who consumes it, which it does. Slightly more explicit guidance on invoking it before create/update runs would close the remaining gap.

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 the baseline of 4 applies. The description adds useful meaning by detailing the field groups the returned contract covers, even though that is technically return-value content rather than input semantics.

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 ("Return the shared run-step contract") and names the two consuming tools, create_run_workout and update_run_workout. The word "run" in "run-step" implicitly distinguishes it from the sibling get_bike_workout_schema and get_strength_workout_schema.

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

Usage Guidelines4/5

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

By naming create_run_workout and update_run_workout as the consumers of this contract, the description gives clear context: call this to learn the accepted payload shape before writing. It stops short of an explicit "call this before creating or updating" instruction or an exclusion against the bike/strength schema siblings.

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

Deploy Server

Other Tools