Skip to main content
Glama

Nolio

Read a stats chart

get_stats_chart
Read-only

Read one statistics breakdown aggregated over a date window (the /statistic page data).

chart: an id from list_stats_charts, e.g. 'zones_duration_heartrate' (time in heart-rate zones), 'sport_duration' (volume by sport). date_from / date_to: 'YYYY-MM-DD' window (default: the last 365 days). athlete: a managed athlete's usr_… handle; omit for yourself. sport: an optional spt_… catalog handle to filter to one exact sport.

Returns rows ({label, value, color}, value is seconds for a duration/zones chart, a count of trainings, or the measure unit (distance, elevation_gain, kilojoules)) and total, the sum of the rows. A count chart counts the trainings carrying its dimension: sport_count every confirmed training of the window (competitions included, so it is the fill-rate denominator; a real/trainings listing hides competitions), rpe_count only those whose rpe is set (a null rpe is skipped, 0 counts as N/A), feeling_count every training (a missing feeling is the N/A row), tag_count counts a training once per tag it carries. For a month-by-month evolution, call this on several sub-windows and compare; a single call is the aggregate over the whole window. RPE/feeling rows also carry their numeric note in rpe/feeling (null for N/A). Use the numeric notes and counts for distributions; exclude null notes from statistics.

Input Schema

NameRequiredDescriptionDefault
chartYes
sportNo
athleteNo
date_toNo
date_fromNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the read-only annotations, the description discloses important behavioral details: default date window, athlete/sport scoping, return shape, count-chart inclusion rules, null RPE handling, tag counting, and how competitions affect counts. These are exactly the edge cases an agent needs before invoking the tool.

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?

The description is dense but well structured: purpose first, then parameter semantics, then return and count-chart behavior. Every sentence adds operational value for a complex stats tool, with no obvious repetition or filler.

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?

Although an output schema exists, the description adds necessary statistical interpretation around rows, totals, and count-chart denominators. Combined with the annotations and schema, an agent has enough information to call the tool correctly across the documented chart types.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry parameter meaning. It covers all five parameters: chart id source and examples, date format and default range, athlete handle semantics, and sport catalog filtering, leaving no required parameter ambiguous.

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?

The description states a specific verb and resource: read one statistics breakdown aggregated over a date window. It also distinguishes the tool from list_stats_charts by treating that sibling as the source of chart ids, so an agent can tell what this tool does and what it does not do.

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?

It explicitly routes chart-id discovery to list_stats_charts and explains the pattern for month-by-month evolution: call several sub-windows and compare. It lacks explicit when-not guidance or named alternatives for other stats-style questions, so it is clear but not fully exhaustive.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources