Skip to main content
Glama
Sign In
hhopke

intervals-icu-mcp

by hhopke
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Icu Get Workouts In Folder

icu_get_workouts_in_folder
Read-onlyIdempotent

List workouts in a specific library folder or training plan, including name, type, structure, training load, and intensity factor.

Instructions

List the workouts stored in one specific library folder or training plan — name, type, structure, training load, intensity factor.

Input Schema

NameRequiredDescriptionDefault
folder_idYesFolder ID to get workouts from
athlete_idNoAthlete ID (for coaches managing multiple athletes)

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv5.0.1
    • addedInput schema / properties / athlete_id
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Athlete ID (for coaches managing multiple athletes)"
+}
  2. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered by structured data. The description adds the shape of the response (the fields returned), which is mildly useful, but says nothing about pagination, ordering, empty folders, or coach/athlete access behavior.

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 and scope first and the returned fields after — no filler, nothing that could be cut without losing information.

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?

An output schema exists, so return values do not need explaining, and the annotations plus 100% schema coverage carry the safety and parameter burden. The one remaining gap is any hint at how this relates to the library-level sibling tool, which would help an agent disambiguate.

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 description coverage is 100%, so both folder_id and athlete_id are already documented, including the coaching use case for athlete_id. The description supplies no additional parameter semantics such as whether folder_id can refer to a training plan, 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?

The description names a specific verb (List) and resource (workouts) and scopes it to a single library folder or training plan, which distinguishes it from the library-wide sibling icu_get_workout_library. It also enumerates the returned fields (name, type, structure, training load, intensity factor), though it never explicitly names a sibling alternative.

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?

The phrase 'one specific library folder or training plan' implies the preconditions — you need a folder in hand — so the usage context is inferable. However, there is no explicit when-to-use/when-not statement, no guidance on how this differs from icu_get_workout_library or icu_get_upcoming_workouts, and no mention of the coach/athlete scenario.

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