Skip to main content
Glama

In Da Mix

by com.divingtechnics.indamix
OverviewDiscussionsAdmin

What If: add gas and see the mix

what_if
Read-onlyIdempotent

What mix you get when you add given pressures of oxygen, helium and/or air to what is in the tank (the app's What If): the pressure after each addition, the resulting mix, its MOD, EAD, END and gas density. Use for "what if" additions: "I have 50 bar of air, what do I get if I add 30 bar of O2 and top up with 120 bar of air", "what if I add 40 bar of helium", "što dobijem ako dodam 30 bara kisika", "dodam 40 bara helija, što dobijem". what_if: given additions -> the resulting mix; blend: a target mix -> how to make it. Pass only the additions and the tank's start the user gave. Answer: the start, the additions in order, the final pressure, the resulting O2 and He, and its MOD by the settings. Then ask whether to check its complete MOD or to adjust the additions for a target mix (blend).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
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.
add_airNoPressure of air added, in pressure_unit.
languageNoLanguage of the texts in the answer: en (English) or hr (Croatian). Use the user's language.en
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
add_heliumNoPressure of pure helium added, in pressure_unit.
add_oxygenNoPressure of pure oxygen added, in pressure_unit.
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`.
helium_firstNoPartial pressure: add helium before oxygen (trimix, heliox).
target_depthNoDepth for the gas density, in depth_unit. Default 30 m.
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
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`.
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

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations cover read-only/idempotent/non-destructive, but the description adds substantial behavior: the full result set (MOD, EAD, END, density), the 'assumed' fallback for missing start pressure, and a mandated follow-up (ask whether to check MOD or switch to blend). For a read-only calculation tool this is rich, non-redundant disclosure.

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 core purpose, examples, and sibling contrast. It is somewhat sprawling, with bilingual example queries and some repetition ('the app's What If', restating outputs), but every section is functional and nothing is irrelevant.

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 16 optional parameters, no output schema, and no required fields, the description compensates well: it names the return values, the units/assumption behavior, the missing-input edge case, and the conversational next step. An agent has everything needed to invoke and follow up correctly.

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% and the 16 parameters carry detailed per-field docs (units, defaults, semantics), so the schema does the heavy lifting. The description reinforces only the high-level rule ('pass only the additions and the tank's start') and the start_pressure caveat, adding little beyond the schema's own text. Baseline 3 is appropriate.

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+resource: computes the resulting mix from adding given O2/He/air pressures to the tank's existing contents. It also names the outputs (pressure after each addition, mix, MOD, EAD, END, density), so an agent knows exactly what it produces and can distinguish it from siblings.

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?

Explicitly says 'Use for "what if" additions' and contrasts with the blend sibling: 'what_if: given additions -> the resulting mix; blend: a target mix -> how to make it.' It even instructs what to pass and to ask before calling when start pressure is unknown, closing the main failure mode.

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