Skip to main content
Glama
sedoglia

Garmin Connect MCP Server

by sedoglia

Get Fitness Age

get_fitness_age
Read-only

Estimate your fitness age from VO2 max and health metrics for a given date, revealing how your body's fitness compares to your chronological age.

Instructions

Get fitness age estimation based on VO2 max and other metrics.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNoDate in YYYY-MM-DD format.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv4.3.0

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare the operation read-only and open-world, so the bar for additional disclosure is lower. The description adds that the value is an estimation based on VO2 max and other metrics, but it does not explain default behavior or how the optional date influences the result.

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

Conciseness5/5

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

The description is a single concise sentence that gets straight to the point. It wastes no words and aligns cleanly with the tool name and title.

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?

With one optional parameter, no nested objects, and a simple read-only concept, the level of detail is nearly sufficient. The main gap is the absence of any note about the return shape or expected behavior when no date is provided.

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?

The input schema already provides 100% coverage of the only parameter, with a clear format description. The tool description does not add additional semantic meaning to the date parameter, so the baseline score of 3 is appropriate.

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 uses a specific verb and resource ('Get fitness age') and adds meaningful scope by indicating the estimate is based on VO2 max and other metrics. This clearly distinguishes it from the many related sibling metric tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The intended use is reasonably implied by the name and description, but there is no explicit guidance about when to choose this tool over other fitness metrics or any mention of how the optional date parameter affects usage.

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