Skip to main content
Glama
Symbolic Algebra MCP Server

Symbolic Algebra MCP Server

convert_to_units

Converts an expression's quantity into specified target units, including compound units split into numerator and denominator parts, and returns a new expression key.

Instructions

Converts a quantity to the given target units using sympy.physics.units.convert_to.

Args:
    expr_key: The key of the expression (previously introduced) to convert.
    target_units: List of unit names as strings (e.g., ["meter", "1/second"]).
    unit_system: Optional unit system (from UnitSystem enum). Defaults to SI.

The following units are available by default:
    SI base units: meter, second, kilogram, ampere, kelvin, mole, candela
    Length: kilometer, millimeter
    Mass: gram
    Energy: joule
    Force: newton
    Pressure: pascal
    Power: watt
    Electric: coulomb, volt, ohm, farad, henry
    Constants: speed_of_light, gravitational_constant, planck

IMPORTANT: For compound units like meter/second, you must separate the numerator and
denominator into separate units in the list. For example:
- For meter/second: use ["meter", "1/second"]
- For newton*meter: use ["newton", "meter"]
- For kilogram*meter²/second²: use ["kilogram", "meter**2", "1/second**2"]

Example:
    # Convert speed of light to kilometers per hour
    expr_key = introduce_expression("speed_of_light")
    result = convert_to_units(expr_key, ["kilometer", "1/hour"])
    # Returns approximately 1.08e9 kilometer/hour

    # Convert gravitational constant to CGS units
    expr_key = introduce_expression("gravitational_constant")
    result = convert_to_units(expr_key, ["centimeter**3", "1/gram", "1/second**2"], UnitSystem.CGS)

SI prefixes (femto, pico, nano, micro, milli, centi, deci, deca, hecto, kilo, mega, giga, tera)
can be used directly with base units.

Returns:
    A key for the converted expression, or an error message.

Input Schema

NameRequiredDescriptionDefault
expr_keyYes
unit_systemNo
target_unitsYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the transparency burden and does well: it discloses the compound-unit list syntax, available units, optional unit system, and that the return is a key or error message. It does not explicitly state whether the original expression is modified or whether a new expression key is persisted, but overall behavioral context is strong for a computation tool.

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 long but justified by the complexity of unit conversion. It is front-loaded with the purpose, then structured into args, available units, important formatting rules, and examples with no wasted prose.

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?

Given the complex unit syntax and 0% schema description coverage, the description supplies the parameter meanings, unit inventory, compound-unit rules, and examples needed to invoke the tool correctly. An output schema exists, so the brief return note is sufficient.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must compensate, and it does thoroughly. It explains expr_key, target_units with compound-unit syntax and examples, and unit_system with default SI, going well beyond the bare schema.

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 states a specific verb and resource: converting a previously introduced expression to target units via sympy.physics.units.convert_to. It is clear what the tool does, but it does not explicitly differentiate itself from the sibling quantity_simplify_units or other unit-related tools.

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 description implies usage by requiring a previously introduced expr_key and by giving examples, but it never states when to use this tool versus alternatives. There are no explicit exclusions or guidance on choosing between convert_to_units and quantity_simplify_units.

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