Skip to main content
Glama
VictorForV
by VictorForV

get_activity_streams

Fetch activity time-series (heart rate, watts, cadence, altitude) downsampled to evenly spaced points, with min/mean/max per series. Select specific data types and sampling density.

Instructions

Time series inside one activity, downsampled.

    types is a comma-separated list, for example heartrate, velocity_smooth,
    altitude, cadence, watts, temp, latlng. Returns `points` evenly spaced
    samples per series plus min/mean/max over the whole series. points must
    be between 2 and 2000. The raw data can exceed ten thousand samples per
    series, so pass full=true only when the shape of every second genuinely
    matters -- not a small `points` value, which is rejected rather than
    silently answered with the full series.

    latlng sometimes comes back from intervals.icu as latitude only rather
    than [lat, lon] pairs; when that happens the series carries a note
    saying so instead of a silently wrong coordinate.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fullNo
typesNoheartrate,velocity_smooth,altitude,cadence,watts
pointsNo
activity_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations, the description carries the full disclosure burden and largely succeeds: it reveals downsampling, points bounds, rejection behavior, the full-series caveat, and the latlng anomaly. It also states the summary statistics returned. This is strong behavioral transparency.

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?

Front-loaded one-line purpose, then details in compact paragraphs. Every sentence adds operational value, including edge cases. There is no filler.

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?

Given no annotations and no output schema, the description gives the essential return shape (points plus min/mean/max) and critical caveats. It stops short of documenting all possible errors or the exact latlng-note representation, but is adequate for safe invocation.

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 0%, so the description must compensate. It explains types format with examples, points as evenly spaced samples with bounds, full semantics, and the activity scope. It does not fully define full's exact return shape or activity_id format, but covers the core parameters well.

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?

Opens with a crisp definition: time series inside one activity, downsampled. This clearly distinguishes it from broader get/list tools and from raw interval tools, even though no sibling is named. The example stream types reinforce the resource being retrieved.

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?

No explicit when-to-use versus alternatives is given; tool selection is only implied by 'inside one activity, downsampled.' It does provide clear parameter-level guidance on when full=true is appropriate and warns against small points values. Missing explicit sibling routing or exclusions keeps this at a 3.

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