Povver — Strength Training

Muscle State

get_muscle_state

Read-only

CAUTION: judge volume on weekly_fractional_sets + volume_zone_v2 + landmarks_v2 (MEV 4 / productive 10–18 / MRV 29); only on a doc without them fall back to weekly_hard_sets + volume_zone + mev/mav/mrv_target — never mix the two. Above MRV alone is NOT overreach. weekly_effective_volume is a SECONDARY weighted metric; never compare it to the landmarks or call it "sets". Trust the precomputed zone; do not reconstruct it. Get TIE's synthesized assessment for a muscle group: weekly_fractional_sets (the set count volume is judged on: 1 per hard set as a primary mover, ½ as a synergist, so it can be 7.5) with volume_zone_v2 (below_mev/mev/mav/mrv/above_mrv) and landmarks_v2 {mev, mav_low, mav_high, mrv}; weekly_hard_sets + volume_zone + mev/mav/mrv_target (the legacy primary-set axis — use only when the v2 fields are absent), weekly_effective_volume (a SECONDARY weighted metric — never compare it to the landmarks or call it "sets"), fatigue status (ACWR) and acwr_trend, plateau detection (plateau_weeks), e1RM trends (e1rm_trends: per-lift state over the window in its window_weeks, 6), current periodization phase, exercise rotation status, strength_climb (per-muscle indexed strength progress over window_weeks 8: median_pct, constituents, all_lifts — its per-lift state can differ from e1rm_trends for the same lift because the windows differ; quote the window with the state), and AI reasoning. Use volume_zone_v2 (else volume_zone — trust it, don't reconstruct) to say whether a muscle is below MEV / optimal / past MRV, and strength_climb to say whether the muscle's lifts are getting stronger. Use for muscle-specific questions. For exercise-specific trends, use get_exercise_progress.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`muscle_group`	Yes	Muscle group: chest, back, shoulders, quads, hamstrings, glutes, biceps, triceps, calves, abs

Output Schema

TableJSON Schema

Name	Required	Description	Default
`acwr`	No
`acwr_trend`	No
`mav_target`	No
`mev_target`	No
`mrv_target`	No
`e1rm_trends`	No
`volume_zone`	No
`landmarks_v2`	No
`muscle_group`	No
`valid_groups`	No
`current_phase`	No
`plateau_weeks`	No
`fatigue_status`	No
`plateau_status`	No
`strength_climb`	No
`volume_zone_v2`	No
`active_exercises`	No
`weekly_hard_sets`	No
`volume_zone_label`	No
`weekly_fractional_sets`	No
`weekly_effective_volume`	No
`weekly_synergist_hard_sets`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedSep 30, 2026

addedOutput schema / properties / landmarks_v2

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": {},
+      "propertyNames": {
+        "type": "string"
+      },
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

addedOutput schema / properties / volume_zone_v2

Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / weekly_fractional_sets

Added value: +{
+  "type": [
+    "number",
+    "null"
+  ]
+}

addedOutput schema / properties / weekly_synergist_hard_sets

Added value: +{
+  "type": [
+    "number",
+    "null"
+  ]
+}

First observedSep 17, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true), so the bar is low, and the description adds substantial interpretive guidance: which axis is authoritative, that 'above MRV alone is NOT overreach', that weekly_effective_volume is secondary and must not be compared to landmarks, and that e1rm_trends and strength_climb can legitimately disagree because their windows differ. It does not disclose rate limits or latency, but for a read-only analytics tool the added semantic warnings are meaningful.

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 description is bloated and heavily repetitive: the weekly_effective_volume warning ("SECONDARY weighted metric — never compare it to the landmarks or call it 'sets'") appears twice, and the volume_zone_v2 'trust it, don't reconstruct' instruction is repeated. The core purpose is not front-loaded, so an agent must parse cautions before learning what the tool does.

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?

For a complex analytics tool with an output schema present, the description supplies the interpretive context an agent needs to read the returned fields correctly (which axis governs, which metrics are comparable, why trend windows differ). It is arguably over-complete, restating return-field semantics that the output schema already covers, but nothing essential is missing.

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

Parameters3/5

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

There is one parameter (muscle_group) with 100% schema description coverage, including the enumerated muscle list, so the schema already carries the semantics. The description adds no additional meaning about the parameter itself, which matches the baseline 3 for fully documented single-param schemas.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description does state the specific verb and resource: "Get TIE's synthesized assessment for a muscle group," and it distinguishes itself from get_exercise_progress ("For exercise-specific trends, use get_exercise_progress"). However, the purpose statement is buried in the middle of a dense wall of axis/field cautions, so an agent scanning the opening lines sees warnings rather than what the tool returns.

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?

Explicitly routes usage: prefer weekly_fractional_sets + volume_zone_v2 + landmarks_v2, fall back to the legacy axis only when the v2 fields are absent, and never mix them. It also names the sibling alternative for a different question type (get_exercise_progress), which is exactly the when-to-use / when-not-to-use guidance this dimension rewards.

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.