Skip to main content
Glama
futureweb

Futureweb Intervals MCP

by futureweb

get_library_workout

Read-only

Read a saved library workout's steps, planned time, load, and targets to reuse it in events or validate training plans.

Instructions

Use to read one library workout (steps, planned time, load, targets), e.g. to reuse it with add_or_update_event or validate_workout. Ids: get_workout_library.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
athlete_idNoDefault: the configured athlete
workout_idYesLibrary workout id (get_workout_library); small numbers such as 1 are normal
output_formatNotext or json (complete workout incl. workout_doc)text

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. Beyond that, the description discloses what the read returns (steps, planned time, load, targets), which is meaningful behavioral context given there is no output schema. It does not mention auth or rate limits, but that is minor for a local read.

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?

Two compact sentences with no waste: purpose and returned contents first, followed by the id source. Everything is front-loaded and nothing is redundant.

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

Completeness5/5

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

For a read-only, three-parameter tool with full schema coverage and annotations covering the safety profile, the description supplies everything an agent needs: what it fetches, what it contains, and where ids come from. No output schema is needed since the return fields are described.

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 the schema already documents athlete_id, workout_id, and output_format. The description's "Ids: get_workout_library" adds a small hint that overlaps almost entirely with the workout_id schema description, so it earns baseline 3 rather than extra credit.

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+resource ("read one library workout") and enumerates the returned content (steps, planned time, load, targets), which clearly separates it from the sibling get_workout_library that lists workouts. The only gap is it doesn't explicitly contrast with preview_workout, but the singular scope makes intent unambiguous.

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?

Gives concrete usage context by naming downstream tools ("reuse it with add_or_update_event or validate_workout") and routes id lookup to get_workout_library. Clear when-to-use context, though it offers no explicit when-not or exclusion conditions.

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