Skip to main content
Glama

Maintenance Calories Estimator

maintenance_calories
Read-only

Daily maintenance calories (TDEE) from Mifflin-St Jeor BMR and an activity level, using metric inputs.

Input Schema

NameRequiredDescriptionDefault
ageYesAge in years (10-90)
sexYesBiological sex
activityYesActivity level index 0-4: 0 sedentary, 1 light, 2 moderate, 3 very active, 4 extra active
heightCmYesHeight in centimetres (120-230)
weightKgYesWeight in kilograms (30-350)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds real value by disclosing the underlying formula (Mifflin-St Jeor) and the metric-unit convention, but says nothing about the return value, range of results, or handling of out-of-range inputs.

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?

A single front-loaded sentence with the resource named first and qualifiers trailing; nothing is wasted. It is arguably too terse for a five-required-parameter tool, but there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description should ideally say what comes back (a kcal/day figure) and note that results depend on all five required inputs. Annotations cover the safety side, but the return-value gap leaves it only adequate for a compute tool of this size.

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 description coverage is 100%, including the activity index legend and the valid ranges for age, height, and weight, so the schema carries the parameter burden. The description only reinforces that inputs are metric, adding little beyond structured data — the baseline 3 applies.

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 names a specific output (daily maintenance calories / TDEE) and the method used (Mifflin-St Jeor BMR plus activity level), so the agent knows exactly what is computed. It does not, however, distinguish itself from the overlapping sibling bmr_tdee, which appears to compute a closely related quantity.

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

Usage Guidelines2/5

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

There is no when-to-use guidance and no mention of the alternative tools (bmr_tdee, calorie, protein_molecular_weight, etc.). The only hint of applicability is the phrase 'using metric inputs', which implies a units precondition but doesn't state when this tool is preferred over bmr_tdee.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.