Povver — Strength Training

User Profile

get_user_profile

Read-only

Get the user's coaching profile: name, primary goal (e.g. build muscle / lose fat), experience level, target training days per week (training_days_per_week is the active routine's frequency, else the user's stated answer, else null; stated_training_days_per_week is what the user answered at onboarding and may be out of date), equipment preference (e.g. full gym / home), height and weight, timezone, and member-since date. Height and weight are ALWAYS stored in cm and kg (height_cm / weight_kg; height and weight carry the same values, height_unit is always "cm" and weight_unit always "kg"); height_display_unit (cm | ft_in) and weight_display_unit (kg | lbs) are the units the user sees in the app — convert to those when talking to the user, and never read a display unit as the unit of the stored number. Use this to CONTEXTUALIZE advice to the user's background and constraints — tailor volume, exercise selection, and progression to their experience level and available equipment. Excludes account/billing internals and contact info. For current-week training activity use get_training_snapshot; for subscription/connection status use check_connection.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description	Default
`goal`	No
`name`	No
`height`	No
`locale`	No
`weight`	No
`timezone`	No
`height_cm`	No
`weight_kg`	No
`height_unit`	No
`weight_unit`	No
`member_since`	No
`distance_unit`	No
`experience_level`	No
`auto_pilot_enabled`	No
`height_display_unit`	No
`weight_display_unit`	No
`equipment_preference`	No
`training_days_per_week`	No
`stated_training_days_per_week`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 1, 2026
- addedOutput schema / properties / distance_unit
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```

Changed5 schema fields changedSep 28, 2026

addedOutput schema / properties / height_cm

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

addedOutput schema / properties / height_display_unit

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

addedOutput schema / properties / stated_training_days_per_week

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

addedOutput schema / properties / weight_display_unit

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

addedOutput schema / properties / weight_kg

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

First observedSep 17, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds substantial behavior beyond that: unit-storage invariants (always cm/kg regardless of display units), the precedence rule for training_days_per_week vs stated_training_days_per_week, and staleness caveats. It stops short of stating error/empty-profile behavior, so not a 5.

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

Conciseness4/5

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

Front-loaded with what it returns, then use case, then exclusions and alternatives — good ordering. It is dense with parentheticals and long compound sentences, and the output-field documentation partially overlaps the existing output schema, but each sentence carries real disambiguation value.

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?

An output schema exists, so return-value documentation is optional, yet the description supplies the interpretation rules that a schema cannot (unit conversion policy, stale onboarding field). For a zero-param read tool, nothing an agent needs to call and interpret it correctly is missing.

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?

Zero input parameters, so the baseline is 4. The description does clarify the semantics of returned fields (height_unit always cm, display units separate), but that concerns outputs rather than inputs.

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+resource ('Get the user's coaching profile') and enumerates the exact contents returned, including ambiguous fields. It also explicitly distinguishes itself from siblings get_training_snapshot and check_connection, so an agent can route without opening a schema.

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 explicit when-to-use ('CONTEXTUALIZE advice... tailor volume, exercise selection, progression'), explicit exclusions ('Excludes account/billing internals and contact info'), and names the correct alternatives for adjacent needs (get_training_snapshot for weekly activity, check_connection for subscription status).

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.