Skip to main content
Glama
futureweb

Futureweb Intervals MCP

by futureweb
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

get_load_projection

Read-only

Project future CTL, ATL and form from planned workouts or what-if scenarios. Returns weekly stats, race days, target form, and plan checks without writing data.

Instructions

Use for future fitness: CTL, ATL and form projected over the planned workouts in the calendar, or a what-if scenario (sessions or weekly templates not in the calendar) against the calendar plan (read-only, nothing is written).

Starts from Intervals.icu's CTL/ATL at the end of yesterday plus today's completed load; planned workouts without a load are reported, not guessed. Returns end values, lowest form, highest ramp, ISO weeks with plan statistics, race days, Intervals.icu's own projection, a model check and weeks outside commonly cited ranges (ramp 5-8 CTL/week, monotony > 2.0, no rest day). With target_date, target_form or a scenario: the target day (default the next RACE_A) at the start of the day; target_form adds a search for the load of the last taper_days that reaches it. Arithmetic, not a forecast; no verdict. Method and scenario format: intervals://methods/load (get_guide).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
atl_daysNoATL time constant in days, at least 1
ctl_daysNoCTL time constant in days; atl_days < ctl_days <= 365
end_dateNoLast day YYYY-MM-DD, max 180 days ahead; default 28 days ahead, extended to the target and scenario
scenarioNoWhat-if plan not in the calendar, object or JSON text: {"calendar": "add"|"replace"|"none", "sessions": [{"date", "load" or "duration_min"+"intensity_factor"}], "weekly": [{"start", "weeks", "load" or "hours"+"intensity_factor", "sessions" or "days"}]}; a list = sessions. Full format: intervals://methods/load
athlete_idNoDefault: the configured athlete
taper_daysNoDays before the target varied by the search, 1-42
target_dateNoTarget day YYYY-MM-DD, today or later (form at the start of that day); default the next RACE_A event
target_formNoForm range at the start of the target day: "5,15" (CTL - ATL) or "5%,20%" (of CTL); starts the search for the load before it
detail_levelNocompact = start, end, lowest form, races, target; standard adds ISO weeks and plan checks; full adds days (JSON: days always, with a scenario only at full)standard
output_formatNojson = machine-readable, all fieldstext

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnly/openWorld annotations, it discloses meaningful behavior: starting point (CTL/ATL at end of yesterday plus today's completed load), that planned workouts without a load are reported not guessed, and that it is "arithmetic, not a forecast; no verdict." This is exactly the extra context annotations cannot carry.

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?

Purpose and read-only guarantee are front-loaded, and the dense enumerations (returns list, scenario defaults) each carry information. It is long and packed, but nearly every clause earns its place, with only minor density overhead.

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?

With no output schema, the description compensates by enumerating the return payload (end values, lowest form, highest ramp, ISO weeks, race days, model check, out-of-range weeks) and the compact/standard/full detail progression. An agent has enough to call and interpret it without further sources.

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?

Schema coverage is 100% so the baseline is 3, but the description adds cross-parameter semantics the schema does not: target_date defaults to the next RACE_A and is measured at start of day, and target_form triggers a search over taper_days for the load that reaches it. It also routes scenario format details to get_guide.

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/use case ("Use for future fitness") and names the exact outputs (CTL, ATL, form projected over planned workouts) plus the two modes (calendar plan vs. what-if scenario). This cleanly distinguishes it from load-history siblings like get_training_load.

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?

Clearly frames when to use it (forward-looking projection against the calendar or a scenario) and notes it is read-only with nothing written. It does not explicitly name an alternative tool (e.g., use get_training_load for completed/actual load), so routing is implied rather than stated.

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