Povver — Strength Training

Training Insights

get_training_insights

Read-only

CAUTION: training_score / score_breakdown / score_drivers / rolling_score are DEPRECATED — do not use them; lead with strength_climb + training_context + muscle_volume. muscle_volume/volume_zone are CALENDAR-WEEK-TO-DATE, so mid-week most groups read below_mev — check partial_week / days_into_week before calling a group under MEV. Get AI-generated training insights and latest weekly review. Insights include: post-workout observations, guardrail alerts (junk volume, neglected muscles, overreach), volume flags. Weekly review includes: strength_climb (the 8-week strength-progress signal — see get_strength_climb; its all_lifts[].state is classified over window_weeks 8), training_context (score_basis, volume_completion, sessions adherence, fatigue, trained_muscle_count — the honest productivity signals), muscle_volume (per-group weekly_hard_sets + volume_zone + MEV/MAV/MRV, reproducing "Muscles · this week", plus weekly_fractional_sets + volume_zone_v2 + landmarks_v2 — the axis the engine judges volume on: 1 per hard set as a primary mover, ½ as a synergist; null on an older doc), fatigue status (ACWR), muscle balance, exercise trends, periodization assessment, and top_primary_movers (each mover's state is the 6-week e1rm_trends one, dated by its window_weeks — it can differ from the same lift's 8-week climb state; quote the window with the state). Lead with strength_climb + training_context + muscle_volume. muscle_volume/volume_zone are CALENDAR-WEEK-TO-DATE — mid-week they read low (below_mev) for most groups; check the top-level partial_week / days_into_week flags and do not call a group below MEV on a partial week. NOTE: training_score / score_breakdown / score_drivers / rolling_score are DEPRECATED (being removed) — do not build on them. Use for retrospective questions (the latest review may be the current in-progress week). For muscle-specific questions, use get_muscle_state. For recommendations, use get_recommendations.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description	Default
`insights`	No
`generated_at`	No
`partial_week`	No
`muscle_volume`	No
`weekly_review`	No
`days_into_week`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 17, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only cover readOnlyHint/openWorldHint, and the description goes well beyond them: it flags four deprecated fields to avoid, warns that muscle_volume/volume_zone are calendar-week-to-date and will read below_mev mid-week unless partial_week/days_into_week are checked, and warns that top_primary_movers states use a different window than strength_climb.

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

Conciseness2/5

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

The content is valuable but poorly structured and heavily redundant: the DEPRECATED warning appears twice (top and bottom), 'Lead with strength_climb + training_context + muscle_volume' appears twice, and the calendar-week-to-date/partial_week caution is stated twice. A single well-ordered paragraph could carry the same information at roughly half the length.

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 no-argument, output-schema-backed tool with a dense and trap-laden payload, the description covers everything an agent needs: which fields to lead with, which are deprecated, how the volume axes are computed, and when to defer to sibling tools.

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 takes zero parameters, so there is nothing to document and the baseline is 4. The description spends its space on field semantics of the response instead, which is appropriate here.

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 and resource ('Get AI-generated training insights and latest weekly review') and enumerates the payload (guardrail alerts, volume flags, strength_climb, training_context, muscle_volume). It also distinguishes itself from siblings by routing muscle-specific questions to get_muscle_state and recommendations to get_recommendations.

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?

Gives an explicit use case ('Use for retrospective questions') plus named alternatives with selection conditions: get_muscle_state for muscle-specific questions, get_recommendations for recommendations, get_strength_climb for the underlying signal. It even caveats that the latest review may be the in-progress week.

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.