alma-corpus-mcp

dust_mass_from_flux

Computes optically thin dust mass from measured flux using Hildebrand 1983, including redshift, CMB contrast/heating, and opacity options.

Instructions

Optically thin dust mass (Hildebrand 1983): M = S_nu D^2 / (kappa_nu B_nu(T_d)).

At redshift z (freq_ghz is the observed frequency): M = S_obs D_L^2 / ((1 + z) kappa(nu_rest) B(nu_rest, T_d)). The full Planck function is used, never the Rayleigh-Jeans 1/T form. kappa_nu = kappa0 (nu / nu0)^beta per gram of dust unless kappa_includes_gas=True (then the result is a gas+dust mass and the dust mass is that divided by gas_to_dust). cmb: 'none', 'contrast' (divide by 1 - B(T_CMB(z))/B(T_d), da Cunha 2013 eq. 18) or 'heating_and_contrast' (t_dust_k is then the z = 0 temperature and is heated by the CMB first, da Cunha 2013 eq. 12). Never apply heating twice. Limits: optically thick emission makes the mass a lower limit; kappa is uncertain by about 25% to a factor 3-5 and is NOT propagated; interferometers can resolve out extended flux.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "flux_mjy": "<flux_mjy>",
      "freq_ghz": "<freq_ghz>"
    },
    "name": "dust_mass_from_flux"
  }
}

Input Schema

Name	Required	Default
`cmb`	No	none
`beta`	No
`nu0_ghz`	No
`flux_mjy`	Yes
`freq_ghz`	Yes
`redshift`	No
`t_dust_k`	No
`distance_pc`	No
`gas_to_dust`	No
`flux_err_mjy`	No
`kappa0_cm2_g`	No
`kappa_preset`	No	beckwith1990
`t_dust_err_k`	No
`flux_cal_frac`	No
`kappa_includes_gas`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 9, 2026

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does disclose substantial behavior: the CMB contrast/heating corrections, that kappa uncertainty (25% to 3-5x) is NOT propagated, and that optically thick or resolved-out flux biases the result low. It does not state what the return value looks like or whether flux_err_mjy/t_dust_err_k produce a propagated uncertainty.

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 defining equation, and each subsequent sentence adds either a formula variant, a parameter rule, or a caveat rather than filler. Some redundancy between the z=0 and redshift forms and the dense math make it heavier than ideal, but the density is earned.

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 15-parameter, annotation-free tool with no output schema, the description supplies the physics model, the redshift and CMB handling rules, and the dominant systematic caveats. Missing pieces are the error/calibration parameters and any statement of return structure, so it is close to complete but not fully.

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?

At 0% schema coverage and 15 parameters, the description meaningfully defines the physics inputs: freq_ghz as observed frequency, redshift's role in the (1+z) and nu_rest terms, the kappa0/nu0/beta scaling, kappa_includes_gas with gas_to_dust, and cmb's three modes including its reinterpretation of t_dust_k. However, flux_err_mjy, t_dust_err_k, flux_cal_frac, and kappa_preset receive no explanation, which is a notable gap for a 15-param tool.

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 opening clause plus equation ('Optically thin dust mass (Hildebrand 1983): M = S_nu D^2 / (kappa_nu B_nu(T_d))') states a specific verb and resource, and the gas+dust note implicitly separates it from gas-mass tools. It stops short of naming a sibling (e.g. fit_modified_blackbody or co_gas_mass) as the alternative, so differentiation must be inferred.

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?

The description gives real when-not conditions: optically thick emission yields only a lower limit, interferometers can resolve out flux, and heating must never be applied twice. It does not tell the agent when to prefer this single-band estimate over a full modified-blackbody fit, so alternative selection is left implicit.

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