Skip to main content
Glama

Psychrometric air properties (HVAC)

hvac_psychrometrics
Read-onlyIdempotent

Answers "What is the dew point / enthalpy / humidity ratio of 95 °F air at 75 °F wet bulb?" and "What RH is 75 °F air with a 55 °F dew point in Denver?" for HVAC design, commissioning, energy and comfort work. From any two of dry bulb, wet bulb, dew point, relative humidity, humidity ratio, enthalpy or grains, returns the full state point: all seven plus specific volume, density and vapor pressure, at any site elevation (atmospheric pressure), in IP (°F, BTU/lb, gr/lb) or SI (°C, kJ/kg, g/kg). Uses the ASHRAE Handbook—Fundamentals (2021) Ch. 1 equations (Hyland-Wexler saturation pressure, ice below freezing) and is cross-checked against PsychroLib to within 0.02 °F. Every result includes steps: each equation with the numbers put into it and its ASHRAE reference, so the work can be checked or pasted into a calc package. Impossible states (wet bulb above dry bulb, RH over 100%) are errors and are not charged. You are only charged when a result is returned: invalid input (400) and upstream failures (4xx/5xx) are not settled. Costs $0.002 USDC per call via x402. Paid per call with x402 inside MCP (see the server instructions).

Input Schema

NameRequiredDescriptionDefault
viaNoOptional: the tool whose next_calls suggested this call (filled in for you).
unitsNo"IP" (°F, CFM, in, BTU) or "SI" (°C, L/s, mm, kW). Default IP. Applies to inputs and results.IP
grainsNoMoisture in grains per lb dry air (gr/lb), in either unit system (7,000 gr = 1 lb).
dry_bulbNoDry-bulb temperature, °F (IP) or °C (SI).
enthalpyNoEnthalpy: BTU per lb dry air (IP) or kJ/kg dry air (SI).
wet_bulbNoWet-bulb temperature, °F or °C.
dew_pointNoDew-point temperature, °F or °C.
elevationNoSite elevation, ft (IP) or m (SI); sets the atmospheric pressure. Default 0 (sea level).
humidity_ratioNoHumidity ratio: lb water per lb dry air (IP, e.g. 0.0100) or g/kg (SI, e.g. 10.0).
relative_humidityNoRelative humidity, % (0-100).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / via
      Added value: +{
      +  "description": "Optional: the tool whose next_calls suggested this call (filled in for you).",
      +  "maxLength": 64,
      +  "type": "string"
      +}
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the read-only/idempotent annotations, it discloses the billing model ($0.002 USDC via x402), exactly when a charge occurs versus when it does not (400 and 4xx/5xx are unsettled), the validation behavior (impossible states are errors), and the returned `steps` audit trail. This is unusually rich behavioral context.

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

Conciseness4/5

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

The description opens with the core question framing, then moves through inputs, outputs, equations, validation and billing in a logical order. It is dense and long, but nearly every sentence provides distinct, useful information rather than padding.

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?

With no output schema, the description carries the return-value burden and discharges it fully: it enumerates all seven state properties plus specific volume, density, vapor pressure, and the embedded `steps` object. Combined with units, elevation, error and billing coverage, an agent has everything needed to call and interpret it.

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 100%, so the baseline is 3, but the description adds the crucial combinatorial semantics that the schema cannot express: any two of seven thermodynamic properties are sufficient to define the state, and units/elevation govern both inputs and results. It does not mention the `via` tracking parameter, minor against its added value.

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 names a specific computation (psychrometric state-point solving) and grounds it in two concrete example questions about dew point, enthalpy and RH. It clearly distinguishes itself from the HVAC siblings hvac_coil_load and hvac_duct_size by resource and operation.

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?

It states the operative input rule ('from any two of dry bulb, wet bulb, dew point, relative humidity, humidity ratio, enthalpy or grains') and names the domains it serves (HVAC design, commissioning, energy, comfort), plus the failure condition (impossible states). It never explicitly routes away from a sibling or states when-not-to-use, so it falls short of a 5.

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