Skip to main content
Glama

In Da Mix

Blend a mix (fill steps)

blend
Read-onlyIdempotent

Use whenever the user asks how to blend, mix, fill or prepare a breathing gas, even if they don't mention In Da Mix. Step-by-step fill plan for blending nitrox, trimix, heliair or heliox into a scuba tank, from what is in it now to the mix and pressure wanted: how much helium and oxygen to add, the order, cooling waits, the O2 test, the air top-up, and booster bars. Partial pressure or continuous, with the app's calculation methods. Use for "how do I blend 18/45 to 220 bar", "how much O2 do I add for EAN32", "fill from the gas left in the tank", "kako napraviti trimix 12/65", "koliko helija trebam za 200 bara", "napravi plan punjenja boce". Needs the target mix and pressure, and what is in the tank now: if the start is unknown, ask; never assume an empty tank. The method, temperature and banks come from the settings. Answer: the start gas, the target, the additions in order with their pressures, the resulting mix, and the key filling and analysis precautions. Then ask whether to calculate the gas this fill takes from the source banks (gas_usage).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
howNopartial_pressure: add pure He and O2 to the tank, then top up with air. continuous: He / O2 go into the compressor intake (a premix stream).partial_pressure
banksNoSource banks (storage cylinders). Any bank not given is taken from the In Da Mix settings and listed in `assumed`.
methodNoCalculation method (equation of state), as in the app. Default from the In Da Mix settings (see list_methods for the current default); listed in `assumed`. IDEAL_GAS_DALTON is the simple ideal-gas method; DIVESOFT_REAL_GAS also plans the decant from the banks.
languageNoLanguage of the texts in the answer: en (English) or hr (Croatian). Use the user's language.en
mix_typeYesnitrox (O2 + air), trimix (He + O2 + air), heliair (He + air), heliox (He + O2).
dive_modeNoOpen circuit (OC) or closed-circuit rebreather (CCR). Sets which defaults apply (from the In Da Mix settings: ppO2, END, density, O2 narcotic). The values used are listed in `assumed`.OC
depth_unitNoUnit of every depth in the question and the answer.m
temperatureNoFill-site (ambient) temperature, in temperature_unit. Default from the In Da Mix settings; listed in `assumed`.
use_boosterNoA gas booster is available: banks that can't decant high enough are boosted. With DIVESOFT_REAL_GAS it changes the plan; with other methods it only plans the gas.
helium_firstNoPartial pressure: add helium before oxygen (trimix, heliox).
include_stepsNoAlso return the app's ƒx steps ("How this was calculated"): every formula with its numbers. Long: only when the user asks how it was calculated.
pressure_unitNoUnit of every pressure in the question and the answer.bar
tank_volume_lNoWater volume of the tank being filled, litres (a twin 12 = 24). Used for gas litres and bank use.
start_pressureNoPressure already in the tank, in pressure_unit. 0 = empty. This changes the result a lot: if the user did not give it, ask before calling. If you call without it, the tool assumes an empty tank and lists that in `assumed`.
heat_correctionNoCorrect for the heating of the gas while filling.
target_pressureYesFill pressure wanted, in pressure_unit (e.g. 200 or 232 bar, 3000 psi).
start_he_percentNoHe percent of the gas already in the tank.
start_o2_percentNoO2 percent of the gas already in the tank (21 for air).
temperature_unitNoUnit of the fill temperature.C
target_he_percentNoHe percent of the mix wanted (trimix, heliair, heliox).
target_o2_percentNoO2 percent of the mix wanted (nitrox, trimix, heliox).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), and the description goes well beyond them: it discloses the empty-tank fallback and that assumptions are recorded in `assumed`, that method/temperature/banks are inherited from settings, and the exact shape of the returned answer plus its precautions.

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?

Front-loaded with the trigger condition, and each sentence contributes something (examples, preconditions, output contract, follow-up), which justifies the length for a 21-parameter tool. It is somewhat sprawling, with many multilingual example phrases in one clause, but there is little true redundancy.

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?

No output schema exists, so the description carries the return-value burden and does so fully: it lists the start gas, target, ordered additions with pressures, resulting mix, and key filling/analysis precautions. For a complex, deeply nested parameter set, the agent has everything needed to call correctly.

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 description coverage is 100%, so the schema already documents all 21 parameters and the baseline is 3. The description adds genuine meaning on top: it flags start_pressure as result-changing with an ask-first rule, notes the target mix/pressure requirement, and explains that several parameters are defaulted from settings and surfaced in `assumed`.

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?

States a specific verb and resource (step-by-step fill plan for blending nitrox/trimix/heliair/heliox into a scuba tank) and enumerates exactly what the plan contains. It is clearly distinguished from siblings by naming the settings source, list_methods for defaults, and the gas_usage follow-up.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit trigger ('whenever the user asks how to blend, mix, fill or prepare a breathing gas'), explicit preconditions (target mix, pressure, and current tank contents), an explicit when-not/ask rule ('if the start is unknown, ask; never assume an empty tank'), and named alternatives (gas_usage, list_methods). Nothing is left to inference.

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