Skip to main content
Glama

In Da Mix

Decant (cascade from cylinders)

decant
Read-onlyIdempotent

Decanting one gas (oxygen, or helium) from source cylinders into a small cylinder without a compressor, as the app's Decant: a cascade, each cylinder equalised in turn (ideal gas). plan refills: one refill or a series (e.g. a CCR O2 cylinder from 75 to 150 bar after every dive): which cylinders each refill uses, the pressures after, how many refills the cylinders give, why it stops, and how many cylinders would be needed. plan diving_days: the app's diving-days planner (use per day, dives a day, Extra cylinders). For linked banks or a booster use fills_from_bank. Prefer it for CCR oxygen logistics. Use for "how many 3 L O2 cylinders do I need to refill my 2 L CCR cylinder after 10 dives", "how many CCR diving days do these O2 cylinders give", "koliko dana mogu roniti s ovim bocama kisika", "koliko puta mogu pretočiti kisik". Don't invent cylinders and don't change the user's gas use per dive or per day. Answer for refills: the number of complete refills, which cylinders each uses, the pressures after where useful, the cylinder that limits it, and why one more refill isn't possible. Answer for diving days: the days, dives a day, use per day, the pressures it keeps to, the cylinders used, and the Extra cylinders. Then ask whether to compare with an extra cylinder, another start pressure or another daily use.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
planNorefills: the tank goes from start_pressure to target_pressure at every refill. diving_days: the app's Decant planner (use per day, dives a day).refills
refillsNorefills: how many refills in a row are wanted (e.g. dives − 1). Left out: as many as the cylinders give.
sourcesNoThe source cylinders, each with its volume and pressure; several identical ones: one entry with count. refills: needed; opened lowest pressure first. diving_days: decanted in this order; left out = the app's defaults (listed in `assumed`).
languageNoLanguage of the texts in the answer: en (English) or hr (Croatian). Use the user's language.en
dives_per_dayNodiving_days: dives a day.
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 cylinder being refilled, litres (e.g. a rebreather's 2 or 3 L).
gas_he_percentNoHe percent of that gas.
gas_o2_percentNoO2 percent of the gas decanted (100 for oxygen, 0 for helium); only names it in the answer.
start_pressureNorefills: the tank's pressure before each refill (what is left after a dive), 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`. diving_days: its pressure now.
target_pressureNorefills: the pressure wanted after each refill, in pressure_unit (needed). diving_days: the pressure it is filled to at most.
use_per_day_maxNodiving_days: highest O2 use a day. Give one use: both are taken as it.
use_per_day_minNodiving_days: lowest O2 use a day, in pressure_unit of the cylinder.
fill_before_every_diveNodiving_days: refill before every dive (true) or once a day (false).
min_pressure_before_diveNodiving_days: the cylinder needs at least this before a dive, in pressure_unit.
min_pressure_to_start_dayNodiving_days, daily fill: the cylinder must start the day with at least this. Default: min_pressure_before_dive + use_per_day_max × (dives_per_day − 1) / dives_per_day.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real behavioral context beyond them: the ideal-gas cascade assumption, equalisation order, the caution that start_pressure 'changes the result a lot' and should be asked for, and that defaults are surfaced in `assumed`. It stops short of describing return shape in detail, but for a computation tool this is strong.

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 opening is front-loaded and useful, but the answer-composition lists are stated twice in near-identical form ('which cylinders each refill uses, the pressures after...' vs. 'which cylinders each uses, the pressures after where useful...'), and the closing instruction about offering comparisons is peripheral. It is long for what a 17-param compute tool needs to say.

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?

With 17 parameters, zero required fields, no output schema, and rich defaults, the description does the necessary work of explaining both modes, the defaults that will be assumed, and the shape of the answer. Missing only minor items such as unit-handling caveats, which the pressure_unit parameter already covers.

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 goes further by framing the two plan modes and telling the agent not to invent cylinders or alter the user's gas use. The mode-level semantics (refills = start→target each time, diving_days = per-day usage planner) add meaning across parameters that the per-parameter schema text does not tie together.

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 states a specific verb and resource (decanting oxygen/helium from source cylinders into a small cylinder without a compressor) and immediately splits its two modes (refills vs diving_days). It explicitly distinguishes itself from the sibling fills_from_bank, so an agent can route without opening either schema.

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?

It names the alternative tool and the condition that selects it ('For linked banks or a booster use fills_from_bank'), states a preference domain ('Prefer it for CCR oxygen logistics'), and gives concrete trigger queries in two languages. When-not-to-use is explicit rather than inferred.

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