Skip to main content
Glama
Packi1992

CalisthenicsCompanion-MCP

by Packi1992
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Get Training Progress

get_progress
Read-only

Retrieve calisthenics exercise progress series and format-specific progression (AMRAP, Death-By, EMOM) from local training data, including best set, session total, and direction labels.

Instructions

Two progress views in one tool, selected by kind. kind: "exercise" returns the per-exercise progress series across ALL sessions the exercise appears in (even sessions without a template) — each point carries the best single set AND the session total, in the metric appropriate to that exercise (e1RM for weighted exercises, reps or hold time for bodyweight exercises), plus a direction label with its own rule and the raw values it was computed from. Omit exerciseId to get the most recently trained exercises instead of one specific exercise. kind: "format" returns the format-specific progression (AMRAP rounds+reps, Death-By highest round, EMOM intervals) for one template, or all format templates if templateId is omitted. points overrides how many recent points each series returns (3-30) for this one call. A call with no matching data returns an empty series, never an error. Set outputFile: true to write the full point series to a local file instead of returning it inline.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.8/5.0
Behavior1/5

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

Annotation Contradiction: readOnlyHint=true indicates a read-only operation, but the description says `outputFile: true` will 'write the full point series to a local file.' That is a persistent side effect, so the description directly contradicts the annotation despite otherwise being rich about behavior.

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?

The description is dense and front-loaded with the key `kind` branching, and each clause contributes useful semantics. The long nested sentences make it harder to scan, but there is little filler.

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?

Given an empty input schema and no output schema, the description works hard to cover modes, metric selection, direction-label provenance, empty-result behavior, and file output. It is still not fully complete because the formal schema omits the described parameters and the 'local file' destination is underspecified, but as prose it is unusually thorough.

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?

The input schema exposes zero properties, yet the description fully defines `kind`, `exerciseId`, `templateId`, `points` (with range 3-30), and `outputFile`, including omission defaults. This is far more parameter meaning than the empty schema provides and meets the 0-param baseline with substantial added value.

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 pinpoints a specific resource and action: it returns two kinds of training progress series selected by `kind`, and it details what each mode returns. This clearly separates it from sibling tools like get_stats or get_history even without naming them.

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 provides explicit decision rules for choosing `exercise` vs `format`, for omitting `exerciseId` or `templateId` to broaden the result, and for overriding `points` or switching to `outputFile`. It does not explicitly tell the agent when not to use this tool in favor of a sibling, so it stops one point short.

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

Deploy Server

Other Tools