Project Gumball

BMI, calories, and protein with error bounds (Body Metrics)

body_metrics

Read-only

Compute BMI, energy expenditure, and protein targets from height and weight. Height and weight MUST carry units — a bare number is REFUSED rather than guessed, because a unit mix-up produces a plausible-looking answer that is badly wrong. Returns every standard BMR formula plus the spread between them, because the spread IS the precision of the estimate. Do not relay a single calorie figure as though it were exact. Not medical advice, and the response says so in its payload.

WHY DELEGATE THIS: Two failure modes at once. A bare number is ambiguous — "170" is a height in centimetres or a weight in pounds — and a wrong unit yields a plausible BMI that is off by a factor of two. And the standard energy formulas disagree by hundreds of calories, so any single figure is false precision.

Owned by Body Metrics at https://body-metrics-tau.vercel.app, which is also callable directly if you would rather not go through the aggregator.

Input Schema

TableJSON Schema

Name	Required	Description
`age`	Yes	Years, 15-100.
`sex`	Yes	The BMR equations are fitted separately.
`height`	Yes	WITH a unit: 178cm, 1.78m, 5'10", 70in. Bare numbers refused.
`weight`	Yes	WITH a unit: 75kg, 165lb, 11st 8lb. Bare numbers refused.
`activity`	No	The largest source of error. Most people overestimate; take the lower band.
`targetBmi`	No
`bodyFatPercent`	No	Adds the Katch-McArdle estimate.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedSep 5, 2026

TDQS

A4.3/5.0

Behavior5/5

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

The description goes well beyond the readOnlyHint and openWorldHint annotations by disclosing that bare numbers are refused, that all standard BMR formulas are returned with the spread as precision, that single calorie figures should not be relayed as exact, and that the response includes a medical disclaimer. This is rich behavioral context an agent needs.

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 front-loaded with the core purpose and the most critical constraint. The sections are structured and purposeful, though the 'WHY DELEGATE THIS' and ownership paragraphs add length beyond the minimum needed. Still, every section earns its place for an agent that needs to decide whether to delegate.

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?

There is no output schema, so the description correctly explains key return behavior: every standard BMR formula plus the spread, and the medical disclaimer in the payload. It is complete enough for correct invocation, but it does not explain targetBmi's purpose or give a detailed response structure, so it stops short of a 5.

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 86%, so the baseline is 3. The description reinforces the unit requirement for height and weight, but the schema already documents this clearly with examples. The description adds little new parameter-specific meaning; targetBmi remains undocumented in both schema and description.

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 opens with a specific verb and resource: 'Compute BMI, energy expenditure, and protein targets from height and weight.' It clearly distinguishes this tool from its unrelated siblings by stating its exact domain and its emphasis on error bounds. The scope is unambiguous.

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?

The 'WHY DELEGATE THIS' section gives strong contextual guidance about when this tool is appropriate, especially around unit ambiguity and false precision. It also names a direct API alternative. However, it does not explicitly state when not to use the tool or name a specific sibling alternative.

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

All Project Gumball tools Inspect

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 clearly distinct domain or a complementary counterpart (cron_build/cron_explain, vocab_draw/vocab_check, round_cash_total/rounding_impact), and the descriptions make those relationships explicit. There is no real risk of selecting the wrong tool for a task.

Naming Consistency3/5

Most tools follow a noun_verb pattern (cron_build, regex_explain, timezone_convert), but there are exceptions like body_metrics, due_date, offside, json_to_types, and round_cash_total, which mix noun phrases, gerunds, prepositions, and verb-first order. The names are readable but not uniform.

Tool Count4/5

13 tools is within a reasonable range, and each utility earns its place as a standalone delegated calculator. The count feels slightly large only because the server is a grab-bag of unrelated domains rather than a focused toolkit, but no tool is redundant.

Completeness4/5

Most subdomains have solid coverage: cron has both build and explain directions, vocabulary has draw and check, and rounding has both per-transaction and aggregate analysis. Minor gaps exist, such as no timezone zone listing, no reverse due-date calculation, and no regex test/match step, but these are workable limitations.

Resources

Need Help?