alma-corpus-mcp

fit_uv_model

Fit parametric source models directly to uv visibilities from .npz/.csv files to estimate source parameters, covariance errors, and reduced chi-squared.

Instructions

Fit a parametric source model directly to visibilities (u, v, Re, Im, weight) from .npz or .csv.

Models: point, gaussian (circular, FWHM), elliptical_gaussian (FWHM major, axis ratio, PA), uniform_disk (diameter, inclination, PA), ring (radius, Gaussian FWHM width via the thin-ring x Gaussian approximation, valid for width << radius; inclination, PA). All carry flux_jy and offsets dra_arcsec (east), ddec_arcsec. chi^2 = sum w [(Re - Re_m)^2 + (Im - Im_m)^2] with CASA WEIGHT = 1 / sigma^2 per real and per imaginary part. rescale_weights: 'none', or 'residual_scatter' (refit after scaling weights so the residual scatter of sqrt(w) (Re, Im) has unit robust std; pipeline weights are often off by factors 2-4). fixed: parameters to hold, e.g. {"dra_arcsec": 0}. uv_range_klambda: [min, max] selection. Starting offsets come from the peak of a coarse dirty map within search_radius_arcsec of the phase centre (unless given in initial); sizes, PA and inclination are grid-searched before the least-squares fit. Returns least-squares values with covariance errors (statistical only), reduced chi^2 and the weight scale; mcmc=True adds an emcee posterior (uniform priors in bounds; needs the [fit] extra). Limits: flux errors exclude the absolute flux scale (about 5-10%, add in quadrature); sizes near the resolution limit need S/N >= 8-10; the model sign convention matters for offsets (see model_visibilities).

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": {
      "vis_path": "<vis_path>"
    },
    "name": "fit_uv_model"
  }
}

Input Schema

Name	Required	Default
`mcmc`	No
`seed`	No
`fixed`	No
`model`	No	gaussian
`initial`	No
`uv_unit`	No	lambda
`freq_ghz`	No
`vis_path`	Yes
`mcmc_steps`	No
`mcmc_walkers`	No
`rescale_weights`	No	none
`uv_range_klambda`	No
`search_radius_arcsec`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 9, 2026

TDQS

A4.3/5.0

Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so thoroughly: it defines the chi^2 convention, CASA weight interpretation, weight-rescaling behavior, starting-offset strategy, grid search, return values, covariance limitations, and MCMC behavior. It also discloses important limits around absolute flux scale, resolution-limit S/N, and sign conventions.

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?

The description is dense but front-loaded, starting with the core action and supported models before moving into fitting details and limits. It is appropriately sized for a complex fitting tool, though some sentences are packed with technical detail.

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 complex 13-parameter fitting tool with no output schema and no annotations, the description is largely complete: it covers model options, fitting behavior, return values, MCMC, and key limitations. Minor gaps remain around a few parameters such as uv_unit, freq_ghz, and MCMC walker/step controls.

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 description coverage is 0%, so the description must compensate for 13 undocumented parameters. It explains the important ones well, including model, rescale_weights, fixed, uv_range_klambda, search_radius_arcsec, initial, and mcmc, though it leaves uv_unit, freq_ghz, seed, mcmc_steps, mcmc_walkers, and vis_path less explicitly described.

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: fit a parametric source model directly to visibilities from .npz or .csv. It also enumerates the supported model families, making the tool's scope unambiguous.

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?

It gives useful in-tool guidance such as model choices, rescale_weights options, fixed parameters, uv_range_klambda selection, and when mcmc is appropriate. However, it does not explicitly say when to use this tool versus sibling fitting tools or when not to use it.

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