In Da Mix

Maximum operating depth

mod

Read-onlyIdempotent

Use whenever the user asks how deep a gas can go or checks an existing breathing gas (nitrox, trimix, CCR diluent) against a depth, even if they don't mention In Da Mix; never work a MOD out by hand. Maximum operating depth of a breathing gas: the MOD by the ppO2 limit (as on a cylinder label), and for hypoxic gases the minimum depth. With complete: true also the complete MOD, the deepest depth within the ppO2, END and gas density limits together, with the limit that sets it. Call it with only the gas (o2_percent, he_percent) and the dive mode: leave ppo2_bar out unless the user gave one, so the In Da Mix setting is used. Answer: the gas and its MOD, the ppO2 limit used and the dive mode (and the minimum depth for a hypoxic gas); nothing else, no table of other ppO2 values, no ppO2 recommendation of your own. Then ask whether to also calculate the complete MOD within the END and gas density limits; if yes, call it again with complete: true (same gas and mode). Only when the user asks for END, density or all the limits, call with complete: true at once, and answer: the complete MOD and the limit that sets it, the MOD by ppO2, END and gas density at the complete MOD, and the limits used; report limits_check as it is (a value at its limit complies). Use for "what is the MOD of EAN32", "max depth for NX38", "how deep can I take 18/45", "can I take air to 50 m", "can I use 10/70 at 65 m", "is this diluent OK for 70 m", "koja je maksimalna dubina za NX38", "koliko duboko mogu s 18/45", "je li 12/65 dobar za 65 metara".

Input Schema

TableJSON Schema

Name	Required	Description	Default
`max_end`	No	Maximum END for the complete MOD, in depth_unit. Default from the In Da Mix settings for the dive mode; the value used is listed in `assumed`.
`complete`	No	Also the complete MOD (within the END and gas density limits too). Leave it out at first; set true only when the user says yes to it. Giving max_end or max_density_g_per_l turns it on.
`language`	No	Language of the texts in the answer: en (English) or hr (Croatian). Use the user's language.	en
`ppo2_bar`	No	ppO2 limit, bar. Default from the In Da Mix settings for the dive mode; the value used is listed in `assumed`.
`dive_mode`	No	Open 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_unit`	No	Unit of every depth in the question and the answer.	m
`he_percent`	No	Helium in the gas, percent (0 for nitrox).
`o2_percent`	Yes	Oxygen in the gas, percent (32 for EAN32, 18 for trimix 18/45).
`o2_narcotic`	No	Count O2 as narcotic in the END. Default from the In Da Mix settings for the dive mode; the value used is listed in `assumed`.
`include_steps`	No	Also 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.
`max_density_g_per_l`	No	Maximum gas density for the complete MOD, g/L. Default from the In Da Mix settings for the dive mode; the value used is listed in `assumed`.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 18, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: defaults come from the 'In Da Mix' settings and are echoed in `assumed`, how limits_check should be reported, and how the follow-up complete-MOD call behaves. This is well past the annotation bar.

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?

It is front-loaded with the trigger condition and organized into invocation and answer rules, and the multilingual example queries aid matching. It is nonetheless a long block with the answer-format rules restated for the complete mode, so some sentences are near-duplicative.

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 no output schema, the description carries the burden of describing returns and does so precisely: the gas and MOD, the ppO2 limit and dive mode, minimum depth for hypoxic gases, and for complete mode the limiting factor plus limits_check semantics.

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% with enums documented, so the baseline is 3, but the description adds real invocation guidance: 'Call it with only the gas (o2_percent, he_percent) and the dive mode: leave ppo2_bar out unless the user gave one,' which the schema alone does not convey.

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 names a specific verb and resource: 'Maximum operating depth of a breathing gas: the MOD by the ppO2 limit ... and for hypoxic gases the minimum depth.' It also distinguishes the two output modes (ppO2 MOD vs complete MOD), so an agent can tell exactly what this tool computes versus siblings like best_mix or blend.

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?

Usage conditions are explicit and even prescriptive: 'Use whenever the user asks how deep a gas can go or checks an existing breathing gas ... never work a MOD out by hand,' plus when to pass complete: true and when not to. It stops short of naming sibling alternatives (e.g. best_mix for gas selection), which keeps it from a 5.

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 tools Inspect

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

Need Help?