Skip to main content
Glama

Fitness Tools

by io.github.almostjacked

Adaptive TDEE

adaptive-tdee
Read-onlyIdempotent

Measure actual TDEE from a logged history of daily weight and/or calorie intake. Default method (kalman) is a joint Kalman filter over true weight and TDEE — handles missing days, gates outliers, and reports uncertainty (CI95) alongside denoised true weight; regression/endpoints are simple window-based estimates kept for comparison. Use instead of formula TDEE once real logged data exists. Each entry needs at least one of weight/kcal (not necessarily both). Entry dates must span 10 years or less (earliest to latest). Note: all methods need at least one weigh-in (kalman) or two (regression/endpoints) — a history with zero weight entries throws under the kalman default; pass methods:'all' to get a graceful empty/skipped result instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
entriesYes
methodsNokalman
window_daysNo
prior_tdee_kcalNoOptional starting TDEE estimate, e.g. from the tdee tool; speeds early convergence.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultsYes
skippedYes
consensusYes

TDQS

A4.3/5.0
Behavior4/5

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

Describes how kalman handles missing days, gates outliers, reports CI95 uncertainty, and explains regression/endpoints. Also notes error vs graceful fallback on zero weigh-ins. Adds value beyond readOnlyHint/idempotentHint annotations.

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 purpose, then method explanation, then usage details. Every sentence adds value, though slightly lengthy. Minor redundancy in referencing methods.

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?

Covers main behaviors, constraints, and edge cases (zero weigh-ins). Output schema exists, so return format not needed. For a complex multi-method tool, description is fairly complete, though could mention method selection effect.

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?

Schema coverage is 25% (only prior_tdee_kcal described). Description compensates for entries (requires at least weight or kcal) and methods (explains default and alternatives), but does not fully cover window_days or prior_tdee_kcal details beyond schema.

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?

Clearly states 'Measure actual TDEE from logged history', distinguishes from formula TDEE ('Use instead of formula TDEE'), and lists specific methods (kalman, regression, endpoints).

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 recommends using this tool 'instead of formula TDEE once real logged data exists', provides entry constraints (date span ≤10 years, at least one of weight/kcal), and warns about weigh-in requirements with fallback (methods:'all').

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

All Fitness Tools toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation5/5

Each tool targets a distinct fitness metric or calculation method, e.g., TDEE via formula vs. data, body fat via different protocols, strength, muscle mass, etc. There is no overlap that would confuse an agent.

Naming Consistency5/5

All tool names follow a consistent lowercase-with-hyphens pattern (e.g., adaptive-tdee, one-rep-max, powerlifting-attempts). The naming clearly conveys the purpose without mixing styles.

Tool Count5/5

10 tools cover a comprehensive set of fitness calculations without being excessive. Each tool earns its place, and the number is well-scoped for the domain.

Completeness5/5

The tool surface covers major fitness estimation needs: TDEE (two methods), body fat, FFMI, macros, muscle potential, strength (1RM, attempts), and sarcopenia screening. No obvious gaps for calculation-oriented fitness tools.

Resources