Skip to main content
Glama

bmi

Compute body mass index from metric or imperial height and weight. Pure CPU, instant.

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": {
      "weight": "<weight>"
    },
    "name": "bmi"
  }
}

Input Schema

NameRequiredDescriptionDefault
unitNometric or imperial
heightNoHeight in cm or inches
weightYesWeight in kg or lb

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added
  2. Removed
  3. Changed4 schema fields changed
    • addedInput schema / properties / height
      Added value: +{
      +  "description": "Height in cm or inches",
      +  "type": "number"
      +}
    • addedInput schema / properties / unit
      Added value: +{
      +  "description": "metric or imperial",
      +  "type": "string"
      +}
    • addedInput schema / properties / weight
      Added value: +{
      +  "description": "Weight in kg or lb",
      +  "type": "number"
      +}
    • addedInput schema / required
      Added value: +[
      +  "weight"
      +]
  4. Added

TDQS

B3.3/5.0
Behavior3/5

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

No annotations are supplied, so the description carries the burden of behavioral disclosure. It does add real value here by stating 'Pure CPU, instant', which signals no network calls, no auth, and no side effects, plus fast, deterministic execution. It omits what happens when height is omitted and says nothing about the return value, so it is adequate rather than thorough.

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 short sentences, front-loaded with the operation and followed by the performance trait. There is no filler and no repetition.

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?

For a simple three-parameter computation the covered ground is mostly enough. However, the schema marks only 'weight' as required and leaves height optional, which is odd for a BMI calculation, and the description does not address that or state the default unit. No output schema exists, so the description leaves the return value unexplained.

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%, so the schema already documents all three parameters with their units. The description restates the metric/imperial choice the schema already declares and adds no syntax or default-unit detail beyond it. Baseline 3 is correct when the schema does the heavy lifting.

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 uses a specific verb and resource: 'Compute body mass index from metric or imperial height and weight.' That is unambiguous about what the tool does. It stops short of a 5 because the sibling list contains near-duplicates ('calculate_bmi', 'bmr_calculator'), and the description never says how this tool differs from them.

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 or when-not-to-use guidance, and no named alternative. With 'calculate_bmi' sitting right next to this tool, an agent gets no help choosing between them. The only weak signal is that both height and weight can be given, which is implied usage rather than stated guidance, so it lands below 3.

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.

Resources