Agent Utility Suite (x402)

HVAC duct sizing and friction loss

hvac_duct_size

Read-onlyIdempotent

Answers "What size duct for 1,000 CFM at 0.08 in. w.g./100 ft?", "What is the velocity and friction in a 24×12 duct at 2,000 CFM?" and "What height do I need with a 10 in depth limit?" for duct design and checking. Give any two of a duct size (round diameter, or rectangular width × height), airflow, velocity and friction rate (equal-friction sizing); a single width or height is held as a fixed side. Returns the exact round diameter and a rectangular equivalent (ASHRAE/Huebscher equivalent diameter for equal friction, or equal area for a velocity design), the nearest standard round and rectangular sizes with the velocity and friction of each, the friction loss per 100 ft (Darcy-Weisbach with Colebrook-White, galvanized steel, standard air), velocity pressure, Reynolds number, and design checks for velocity, friction and aspect ratio. IP (in, CFM, FPM) or SI (mm, L/s, m/s, Pa/m, metric sizes). Every result includes steps with the equations and numbers. 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

Name	Required	Description	Default
`via`	No	Optional: the tool whose next_calls suggested this call (filled in for you).
`units`	No	"IP" (°F, CFM, in, BTU) or "SI" (°C, L/s, mm, kW). Default IP. Applies to inputs and results.	IP
`width`	No	Rectangular width: in or mm. With height, the duct size; alone, a fixed side (e.g. a ceiling depth) the other side is solved for.
`height`	No	Rectangular height: in or mm.
`airflow`	No	Airflow: CFM (IP) or L/s (SI).
`diameter`	No	Round duct diameter: in (IP) or mm (SI).
`velocity`	No	Air velocity: FPM (IP) or m/s (SI).
`friction_rate`	No	Friction loss: in. w.g. per 100 ft (IP, typically 0.05-0.15) or Pa/m (SI, typically 0.4-1.2). With airflow, this is equal-friction sizing.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 12, 2026

addedInput schema / properties / via

Added value: +{
+  "description": "Optional: the tool whose next_calls suggested this call (filled in for you).",
+  "maxLength": 64,
+  "type": "string"
+}

AddedOct 6, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), but the description adds the billing model ($0.002 USDC per call via x402), the settlement edge cases (400 and 4xx/5xx not charged), the physics assumptions (Darcy-Weisbach/Colebrook-White, galvanized steel, standard air), and per-result 'steps' output. This is rich context well beyond the annotations.

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?

Dense and front-loaded with the example questions that anchor the tool's purpose, then inputs, outputs, units and pricing in order. It is long, and the units enumeration partly repeats the schema, but nearly every sentence carries information an agent needs.

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?

Despite eight optional parameters and no output schema, the description fully specifies the return payload (exact diameter, rectangular equivalent, nearest standard sizes, friction loss, velocity pressure, Reynolds number, design checks, and 'steps') plus unit systems. Nothing needed to call it correctly is missing.

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 encodes cross-parameter constraints the schema cannot express: 'any two of a duct size, airflow, velocity and friction rate', and the fixed-side behavior for a single width/height. These combination rules materially affect a correct call.

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?

Names a specific computation (duct sizing and friction loss) and leads with three concrete example questions that define the resource precisely. It is trivially distinguishable from siblings hvac_coil_load and hvac_psychrometrics, which cover different HVAC domains.

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 states 'for duct design and checking' and, more usefully, explains the input-combination rule: give any two of size/airflow/velocity/friction rate, and that a lone width or height is held as a fixed side. It stops short of explicit when-not guidance or naming which sibling to use for related HVAC questions.

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

All Agent Utility Suite (x402) tools Inspect

Try in Browser

Give agents eyes on the webHosted screenshot MCP. Send a URL, get a pixel-perfect image. $0.002 per grab. Works with Claude, Cursor, and Codex.grabbit.liveAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?