Symbolic Algebra MCP Server

quantity_simplify_units

Simplifies unit-based expressions to reduced units or dimensionless results, converting compound quantities like kg·m/s² to newtons and helping resolve mixed-unit calculations.

Instructions

Simplifies a quantity with units using sympy's built-in simplify method for Quantity objects.

Args:
    expr_key: The key of the expression (previously introduced) to simplify.
    unit_system: Optional unit system (from UnitSystem enum). Not used with direct simplify method.

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

Example:
    # Simplify force expressed in base units
    expr_key = introduce_expression("kilogram*meter/second**2")
    result = quantity_simplify_units(expr_key)
    # Returns newton (as N = kg·m/s²)

    # Simplify a complex expression with mixed units
    expr_key = introduce_expression("joule/(kilogram*meter**2/second**2)")
    result = quantity_simplify_units(expr_key)
    # Returns a dimensionless quantity (1)

    # Simplify electrical power expression
    expr_key = introduce_expression("volt*ampere")
    result = quantity_simplify_units(expr_key)
    # Returns watt

Example with Speed of Light:
    # Introduce the speed of light
    c_key = introduce_expression("speed_of_light")

    # Convert to kilometers per hour
    km_per_hour_key = convert_to_units(c_key, ["kilometer", "1/hour"])

    # Simplify to get the numerical value
    simplified_key = quantity_simplify_units(km_per_hour_key)

    # Print the result
    print_latex_expression(simplified_key)
    # Shows the numeric value of speed of light in km/h

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

Input Schema

Name	Required	Description	Default
`expr_key`	Yes
`unit_system`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 29, 2026

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations, the description must carry the full behavioral burden. It does disclose that a new expression key is returned and that an 'error message' can result, and the examples reveal that simplification normalizes to derived SI units rather than merely tidying syntax. It does not state whether a new expression is registered in state, nor clarify the practical effect of the unit_system parameter beyond saying it is 'not used'.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, which is good, but the body is bloated: a 20-line unit inventory plus four multi-line commented examples, when two examples would establish the same behavior. The trailing 'Returns' line also restates what the output schema already declares, so not every sentence earns its place.

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?

An output schema exists, so return values need not be explained, and the description still supplies an available-units inventory and worked examples that make the tool callable without guesswork. Remaining gaps are its relationship to sibling simplification/conversion tools and the precise semantics of unit_system.

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 0%, so the description has to compensate; it does explain both parameters in the Args block, noting expr_key must be 'previously introduced' and unit_system comes from the UnitSystem enum. However, the five enum values (MKS, MKSA, natural, SI, cgs) are never explained and the note that unit_system is 'Not used with direct simplify method' is ambiguous about whether passing it has any effect.

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 first sentence gives a specific verb and resource ('Simplifies a quantity with units') and the examples concretely show the outcome (kg·m/s² → newton, volt·ampere → watt), which tells an agent what the tool actually produces. It never names or contrasts with the obvious siblings simplify_expression and convert_to_units, so differentiation is left to inference.

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 only implied through the 'Example with Speed of Light' chain, which shows convert_to_units followed by quantity_simplify_units, so an agent can infer the intended workflow. There is no explicit statement of when to prefer this over convert_to_units or simplify_expression, and no when-not guidance.

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