Skip to main content
Glama
Notysoty

SimplyUtils MCP Server

by Notysoty
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Convert units

convert_units
Read-only

Convert a numeric value between units in the same category, such as length, weight, temperature, volume, speed, area, data, or time, by specifying the value, category, source unit, and target unit.

Instructions

Convert a value between units of the same category. Units (symbol or name): length: m, km, mi, ft, in, cm, mm, yd, nmi; weight: kg, g, lb, oz, t, mg, st; temperature: °C, °F, K; volume: L, mL, gal, fl oz, cup, tbsp, m³; speed: km/h, mph, m/s, kn, ft/s; area: m², km², mi², ft², ac, ha; data: B, KB, MB, GB, TB, bit, KiB, MiB, GiB, TiB; time: s, min, h, d, wk, mo, yr, ms.

Input Schema

NameRequiredDescriptionDefault
toYesUnit symbol or name, e.g. mi or mile
fromYesUnit symbol or name, e.g. km or kilometer
valueYesA plain number, e.g. 12.5
categoryYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4/5.0
Behavior3/5

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

Annotations already establish that this is a safe, read-only, non-destructive operation. The description adds the supported-unit catalog and same-category constraint, but does not disclose rounding, precision, case sensitivity, or error behavior for invalid units.

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 purpose is front-loaded in the first sentence, followed by a dense but useful unit catalog. The list is long but every category and unit mapping earns its place by defining valid inputs.

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 simple converter, the definition covers purpose, valid categories, and supported units, while annotations cover safety. It is slightly incomplete because it does not state the output format or behavior for unsupported conversions.

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 75%, with descriptions for value, from, and to. The description goes beyond the schema by listing supported units and mapping them to categories, which materially clarifies valid values for from and to.

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 states a specific verb and resource: 'Convert a value between units of the same category.' The same-category scope makes it clearly distinct from unrelated utility siblings such as convert_timestamp or hash_text.

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?

The same-category constraint implies when the tool applies, but there is no explicit guidance on alternatives, exclusions, or edge cases such as incompatible categories. Usage is clear enough to infer but not fully specified.

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

Deploy Server

Other Tools