Nume calculators

Calorie calculator

calorie_calculator

Read-onlyIdempotent

Daily calories for an adult to maintain weight, lose body fat or build muscle. Works out maintenance from age, sex, height, weight and how active a normal day is, not counting exercise, then the daily target and its range for the goal. Returns kcal a day, the range and a link to the method. Height (height_cm, or height_ft with height_in) and weight (weight_kg or weight_lb) are also required.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "age": "<age>",
      "sex": "<sex>",
      "day": "<day>"
    },
    "name": "calorie_calculator"
  }
}

Input Schema

Name	Required	Description
`age`	Yes	Age in years. The calculator is for adults; under 18 it says so instead of a number
`day`	Yes	A normal day, not counting exercise: seated (desk, driving), walking (errands, stairs, a commute on foot), on_feet (teaching, a shop, housework), physical (lifting, building, farm work)
`sex`	Yes	female or male; the equations and reference values differ by sex
`goal`	No	Optional. Without it, the answer is maintenance
`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.

Changed1 schema field changedNov 12, 2026
- addedInput schema / properties / sex / description
```
Added value: +"female or male; the equations and reference values differ by sex"
```
First observedNov 12, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already establish read-only, idempotent, closed-world, non-destructive behavior, so the bar is lower, and the description still adds real context: maintenance is computed from a non-exercise activity level, results come with a goal range and a link to the method, and the tool is deterministic per input. Minor overlap with the output schema in restating return values keeps it from a 5.

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?

Four sentences, front-loaded with the purpose before the mechanics and the input requirements. The final sentence partially repeats unit details already in the schema, but it earns its place by flagging that those inputs are required.

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?

For a nine-parameter calculator with an output schema and full annotation coverage, the description covers purpose, computation basis, return shape and input requirements adequately. The remaining gap is routing guidance relative to the sibling calculators and any statement of what happens on out-of-range or missing height/weight inputs.

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 meaning the schema does not: it clarifies that height and weight are effectively required despite not appearing in the schema's required list, and it pairs the unit alternatives (height_cm vs height_ft+height_in, weight_kg vs weight_lb). It also reinforces that 'day' excludes exercise, which is the main misinterpretation risk for that enum.

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 computed resource (daily calories for an adult) and the three goal variants (maintain, lose fat, build muscle). The resource alone cleanly separates it from bmi_calculator, protein_calculator and water_intake_calculator, so an agent can select it without opening a schema.

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?

Usage is implied rather than stated: the adult-only scope and the three goals give context for when the tool fits, but there is no explicit when-not guidance and no mention of the sibling calculators as alternatives. An agent must infer that non-adult users are out of scope and that this tool is not for BMI or macronutrient splits.

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?