Skip to main content
Glama
Sign In

In Da Mix

by com.divingtechnics.indamix
OverviewDiscussionsAdmin

How many fills the banks give

fills_from_bank
Read-onlyIdempotent

How many identical fills the source banks give before a bank can't supply the next one, and why it stops (bank down to the minimum pressure, or it can't decant high enough without a booster). Every tank is assumed to start the same (start_pressure / mix). Use for "how many tanks can I fill with NX32 from my 50 L O2 bank at 180 bar", "how many trimix fills can I make", "koliko boca mogu napuniti", "za koliko punjenja imam kisika". Answer: the number of complete fills, the banks and the start of each tank, the bank that limits it, the bank pressures after, and why one more fill isn't possible; say that every fill is assumed to start the same. one_fill_needs per bank: uses = the pressure one fill takes out of that bank (liters = its free gas) and bank_pressure = the least it must hold for one fill, whatever it holds now: give both for "how much must be in my helium bank", "koliko mi treba u boci helija od 50 l". For several fills ("for 4 fills", "za 3 punjenja") pass fills_wanted: fills_needs per bank gives bank_pressure = the least it must hold for that many fills (uses = per fill). When a bank stops it, stops_because.bank_needed is the pressure that bank needs for the next fill (with 0 fills: for one); give it for "is my bank enough". Then ask whether to see what a booster or an extra bank would add.

Input 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, trimix, heliair, heliox, or top_up (a ready-made supply gas from the top-up bank).
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
max_fillsNoStop counting here.
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.
fills_wantedNoOnly when the user asks what the banks must hold for this many fills: fills_needs.
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
min_bank_pressureNoA bank isn't used below this pressure (regulator / compressor intake / booster inlet), in pressure_unit. Default 10 bar.
supply_he_percentNoHe percent of the supply gas.
supply_o2_percentNoO2 percent of the ready-made supply gas (20.9 for air, 32 for EAN32).
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. Changed1 schema field changed
    • addedInput schema / properties / fills_wanted
      Added value: +{
+  "description": "Only when the user asks what the banks must hold for this many fills: fills_needs.",
+  "maximum": 100,
+  "minimum": 2,
+  "type": "integer"
+}
  2. First observed

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description usefully adds the key assumption that every tank starts the same, what start_pressure does to results and the instruction to ask when it's absent, and a follow-up offer about boosters. It still doesn't disclose limits like the max_fills cap, though that lives in the schema.

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

Conciseness2/5

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

A single long run-on paragraph mixing purpose, return values, per-bank breakdowns, Croatian example phrases, and follow-up suggestions. The core purpose is front-loaded, but subsequent sentences are dense and hard to parse, and several clauses repeat the 'every fill starts the same' assumption.

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?

For a 26-parameter tool with no output schema, the description does the necessary work of describing the return shape (fill count, limiting bank, post-fill pressures, stops_because) and stating the key assumption. It would be stronger with explicit guidance on defaults and the max_fills cap, but nothing critical for correct invocation is missing.

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 100%, so all 26 parameters are already documented, making 3 the baseline. The description adds marginal value by explaining how fills_wanted drives fills_needs and how stops_because.bank_needed is to be used, but most parameters get no extra semantic depth beyond the 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 first sentence states a specific capability: counting how many identical fills the source banks can supply before one can't, and why it stops. It's distinguishable from siblings like decant or blend, though the density makes the core purpose slightly harder to grab than it should be.

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?

Provides concrete example questions in English and Croatian for the main case, for one_fill_needs, for fills_wanted, and for stops_because.bank_needed, so the agent knows which fields map to which user intents. It stops short of explicitly naming sibling alternatives (decant, gas_usage) and when to prefer them.

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

All In Da Mix toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources