codecalc

Overview Schema Source Related Servers Discussions Admin

Convert Units

convert_units

Read-onlyIdempotent

Convert quantities between units across metric/imperial length, mass, speed, energy, pressure, temperature, volume, data sizes, and more. Use unit aliases like mph, celsius, or gb to get exact conversions.

Instructions

Convert a value between units (dimensional analysis via sympy).

Supports metric/imperial length, mass, time, speed, energy, power, force, pressure, temperature (°C/°F/K), volume, area, data sizes, frequency. Examples: ('60','mph','km/h'), ('100','celsius','fahrenheit'), ('1','gb','mib'). Use list_units for the full alias table.

Input Schema

TableJSON Schema

Name	Required	Description
`value`	Yes	Numeric quantity to convert, in `from_unit`
`to_unit`	Yes	Target unit alias, e.g. 'km/h', 'fahrenheit', 'mib'; see list_units for all aliases
`from_unit`	Yes	Source unit alias, e.g. 'mph', 'celsius', 'gb'; see list_units for all aliases

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.12.0Sep 9, 2026

addedInput schema / properties / from_unit / description

Added value: +"Source unit alias, e.g. 'mph', 'celsius', 'gb'; see list_units for all aliases"

addedInput schema / properties / to_unit / description

Added value: +"Target unit alias, e.g. 'km/h', 'fahrenheit', 'mib'; see list_units for all aliases"

addedInput schema / properties / value / description

Added value: +"Numeric quantity to convert, in `from_unit`"

Changed1 schema field changedv0.11.0Sep 9, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "title": "convert_unitsDictOutput",
+  "type": "object"
+}

Changed6 schema fields changedv0.2.0Aug 19, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
- addedInput schema / properties / from_unit / title
```
Added value: +"From Unit"
```
- addedInput schema / properties / to_unit / title
```
Added value: +"To Unit"
```
- addedInput schema / properties / value / title
```
Added value: +"Value"
```
- addedInput schema / title
```
Added value: +"convert_unitsArguments"
```
- changedOutput schema / (root)
```
Previous value: -{
-  "additionalProperties": true,
-  "type": "object"
-}New value: +null
```
First observedv0.1.0Aug 7, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already establish safety (readOnly, idempotent, non-destructive), so the description adds context by mentioning 'dimensional analysis via sympy' and specifying the supported measurement categories. It stops short of describing behavior on invalid units or edge cases, but with annotations carrying the safety profile and an output schema present, this is sufficient.

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?

The description is compact and well-structured: a one-line purpose, a category list, a few clarifying examples, and a pointer to list_units. Every sentence earns its place, and the core purpose is front-loaded.

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

Completeness5/5

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

For a moderate-complexity conversion tool, the description covers supported domains, gives representative examples, points to the alias reference, and benefits from a 100%-covered schema and an output schema. Nothing essential for invoking the tool correctly is missing.

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 baseline is 3. The description reinforces parameter meaning with examples like ('60','mph','km/h') and points to list_units for aliases, but it does not add new per-parameter semantics beyond what the schema already provides.

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: 'Convert a value between units (dimensional analysis via sympy)'. It enumerates the supported categories and gives concrete examples, making the tool's purpose unmistakable and distinguishing it from siblings like list_units and data_sizes.

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 description clearly implies this tool is for value conversion and explicitly routes users to list_units for the full alias table, which is a useful alternative-selection signal. However, it does not explicitly state when not to use convert_units or how to choose among potentially overlapping siblings such as data_sizes or human_duration.

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