Nume calculators

BMI calculator

bmi_calculator

Read-onlyIdempotent

Body mass index from height and weight, its WHO adult category, and the weight range WHO calls normal for that height. Height (height_cm, or height_ft with height_in) and weight (weight_kg or weight_lb) are both required.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "bmi_calculator"
  }
}

Input Schema

Name	Required	Description
`height_cm`	No	Height in centimetres, 100 to 250
`height_ft`	No	Height in feet, with height_in, instead of height_cm
`height_in`	No	The inches part of the height, 0 to 11
`weight_kg`	No	Weight in kilograms, 25 to 400
`weight_lb`	No	Weight in pounds, instead of weight_kg

Output Schema

Name	Required	Description
`note`	No	A line instead of a number, when no number applies
`page`	Yes
`tool`	Yes
`inputs`	Yes	The inputs as understood, in metric units
`method`	Yes	How the answer is worked out
`result`	No
`disclaimer`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the marginal bar is low, and the description adds real content: it discloses exactly what is returned, including the WHO category and the normal-weight range. The word 'adult' in 'WHO adult category' usefully signals population scope that annotations cannot convey.

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?

Two sentences, output contract first, input constraint second, with no filler. The most decision-relevant information (what it returns) is front-loaded.

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 an output schema and full annotation coverage, the description only needs to carry scope and input-pairing rules, and it does both. A small gap remains: weight_lb has no documented bounds in the schema, and the description gives no range for it, nor does it say the WHO normal-weight range is adult-only while the category label hints at it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds pairing semantics the schema cannot express: height_cm OR height_ft-with-height_in, and weight_kg OR weight_lb, with both a height and a weight required. That mutual-exclusivity and joint-requirement logic is the main calling ambiguity and the description resolves it.

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 names a specific computation (BMI from height and weight) and enumerates all three outputs: the index, the WHO adult category, and the WHO normal weight range for that height. It is unambiguously a BMI tool, clearly distinct from the calorie, protein, and water siblings.

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?

It states that both a height and a weight input are needed and gives the alternate unit routes (height_cm vs height_ft+height_in; weight_kg vs weight_lb), which is genuine invocation guidance. It stops short of saying when to pick this over a sibling calculator, or when the result should not be used (children, pregnancy, athletes).

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

All Nume calculators tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?