alma-corpus-mcp

spectral_index

Computes spectral index alpha from flux densities at two or more frequencies, returning uncertainty and optional dust-corrected beta.

Instructions

Spectral index alpha (S_nu proportional to nu^alpha) from two or more frequencies.

Two points: alpha = ln(S2/S1) / ln(nu2/nu1), sigma_alpha = sqrt((s1/S1)^2 + (s2/S2)^2) / |ln(nu2/nu1)|. More points: weighted least squares of ln S on ln nu. Each flux error is the statistical error (+) the per-band flux calibration fraction (default 10%) in quadrature, so the absolute alpha error is calibration dominated (about 0.4 for 10% per band on nearby bands). Also returns beta = alpha - 2 (optically thin Rayleigh-Jeans) and, if t_dust_k is given, beta corrected for the Planck curvature: beta = alpha - dlnB/dlnnu. Limits: needs matched uv ranges / beams across bands; optical depth and scattering lower alpha (mimicking grain growth); non-simultaneous data on variable sources bias it.

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": {
      "freq_ghz": "<freq_ghz>",
      "flux_mjy": "<flux_mjy>"
    },
    "name": "spectral_index"
  }
}

Input Schema

Name	Required	Description	Default
`flux_mjy`	Yes
`freq_ghz`	Yes
`t_dust_k`	No
`flux_err_mjy`	No
`flux_cal_frac`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 9, 2026

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations supplied, the description carries the full behavioral burden and does well: it discloses the error model (statistical error plus per-band calibration fraction in quadrature, default 10%), quantifies the typical outcome (absolute alpha error ~0.4, calibration dominated), states secondary outputs (beta = alpha - 2, Planck-corrected beta), and lists physical caveats. It stops short of stating output shape/naming or failure behavior for mismatched array lengths.

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 definition and the two-point formula before generalizing to weighted least squares, so a reader can stop early. The math is dense but each clause earns its place (error model, beta derivation, limits); minor cost is the lack of headings making the caveat/limit material easy to skim past.

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?

No output schema exists, so the description must describe returns, and it does enumerate alpha, sigma_alpha, beta, and the temperature-corrected beta. Combined with the disclosed default calibration fraction and the stated physical limitations, an agent has enough to call it correctly; only input validation edge cases and exact return field names remain unstated.

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 0% across five parameters, so the description must compensate, and it largely does: freq_ghz and flux_mjy are tied to the nu/S symbols in the formula, flux_err_mjy maps to the s1/s2 statistical errors, flux_cal_frac to the per-band calibration fraction (default 10%), and t_dust_k to the temperature used for the Planck curvature correction. It does not clarify that flux_cal_frac may be scalar or per-band array, nor validate length-matching requirements.

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 description opens with a specific verb-and-resource statement: compute spectral index alpha (S_nu proportional to nu^alpha) from two or more frequencies. That is unambiguous about what is computed, though it never names a sibling such as fit_modified_blackbody, which also models dust SED shape, so an agent must infer the boundary between them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied by the 'Limits' sentence (needs matched uv ranges/beams, optical depth and scattering bias alpha low, non-simultaneous data on variables bias it), which tells the agent when the result is untrustworthy. However there is no explicit 'use this instead of X when Y' routing versus fit_modified_blackbody or dust_mass_from_flux, so selection guidance is only partial.

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