Povver — Strength Training

List Trained Exercises

list_trained_exercises

Read-only

Enumerate the exercises the user actually trains, from their logged set history — the fastest way to orient before per-lift analysis (saves the 10+ sequential get_exercise_progress calls it used to take to survey the user). For each exercise returns: the exact exercise_id (pass it to get_exercise_progress to avoid name-match ambiguity), session_count, weeks_of_data, set_count, last_performed + days_since_last, is_stale, typical_reps, e1rm_coverage, strength_state (the trend state — progressing / holding / stalling / deloading / insufficient_data — classified over the window in strength_state_window_weeks (6), read from the SAME source as get_exercise_progress, so it never contradicts that tool; get_strength_climb classifies over 8 weeks and may differ), and can_trend (strength_state != insufficient_data) with trend_blockers explaining WHY a lift can't trend yet: insufficient_weeks (<3 distinct weeks), no_e1rm, or no_trend_state (enough raw data but no computed trend — usually variant fragmentation or e1RM coverage; see fragmented_variants). Staleness is a separate axis (is_stale / days_since_last: a hard-trained but old lift can still trend, its trend is just stale). Also returns a data_quality block: overall e1rm_coverage (fraction of working sets with a computed e1RM — typically ~1.0 post-update, so it flags coverage gaps like bodyweight sets, NOT e1RM confidence), fragmented_variants (one movement split across near-duplicate catalog ids, e.g. bicep curl as barbell + cable + dumbbell — the reason a well-trained movement can still read insufficient_data per variant), exercises_cannot_trend_yet (with weeks_of_data + blockers), and stale_trends. USE THIS FIRST to discover exact ids and which lifts have enough data to trend, then call get_exercise_progress(exercise_id) for the specific lifts. The window block reports the scan bound: scan_capped=true means older history exists beyond the scan window, so a lift trained only earlier than window.oldest_set_date may not appear (absence here is not proof it was never trained).

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description	Default
`window`	No
`exercises`	No
`truncated`	No
`data_quality`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 17, 2026

TDQS

A4.7/5.0

Behavior5/5

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

The annotations provide readOnlyHint=true, and the description adds meaningful behavior beyond that: scan_capped semantics, that strength_state reads from the same source as get_exercise_progress and therefore never contradicts it, staleness as a separate axis, and trend_blockers explaining why a lift cannot trend. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, but the description is a dense, sprawling block with many nested caveats and examples. It is highly informative, but the structure could be clearer with more separation between core purpose, return fields, and edge cases.

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 zero-parameter tool, the description is unusually complete: it enumerates the key return fields, explains data quality concepts like fragmented_variants and e1rm_coverage, and covers edge cases such as scan_capped and stale trends. An agent has enough context to call it and interpret the result correctly.

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?

The tool has zero parameters and schema description coverage is 100%, so no parameter explanation is needed. With 0 parameters, the baseline is 4; the description appropriately spends no time on parameter semantics.

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 opens with a specific verb and resource: 'Enumerate the exercises the user actually trains, from their logged set history.' It also clearly differentiates itself from siblings like get_exercise_progress by positioning itself as the fast orientation step and explicitly naming the sequential calls it replaces.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit routing advice: 'USE THIS FIRST to discover exact ids and which lifts have enough data to trend, then call get_exercise_progress(exercise_id).' It also distinguishes its 6-week classification window from get_strength_climb's 8-week window and warns that scan-capped results mean absence is not proof the exercise was never trained.

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

All Povver — Strength Training tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.