alma-corpus-mcp

largest_angular_scale

Compute maximum recoverable angular scale and resolution from baseline lengths or visibility data, using ALMA Handbook formulas for both legacy and current conventions.

Instructions

Maximum recoverable scale (MRS) and angular resolution from baseline lengths.

Gives both conventions: the older ALMA Technical Handbook / Wilner and Welch (1994) form theta_MRS ~ 0.6 lambda / B_min, and the current Handbook form theta_MRS ~ 0.983 lambda / L05 with L05 the 5th percentile baseline; resolution ~ 0.574 lambda / L80 (80th percentile). The Handbook percentiles are over unique antenna pairs. Input: baselines_m (one projected length in metres per antenna pair), or a visibility file (u, v; with antenna id columns ant1/ant2 the percentiles use each pair's mean length, otherwise they are over visibility rows and say so), or just b_min_m (then only the 0.6 form). Limits: these are rules of thumb for smooth structure; flux on scales near the MRS is already partly lost (use flux_recovery for a model estimate) and the actual MRS depends on uv coverage and imaging.

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>"
    },
    "name": "largest_angular_scale"
  }
}

Input Schema

Name	Required	Default
`b_min_m`	No
`uv_unit`	No	lambda
`freq_ghz`	Yes
`vis_path`	No
`baselines_m`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 9, 2026

TDQS

A4.2/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 burden and does so: it states both formula conventions, defines L05/L80 as 5th/80th percentile baselines, specifies that percentiles are over unique antenna pairs versus visibility rows depending on input, and flags that results are rules of thumb degraded by uv coverage and imaging. This is substantive behavioral context an agent could not infer from the schema.

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 text is front-loaded with the purpose, then the conventions, then the input modes, then the limits — a sensible order with almost no filler. It is dense to the point of being terse in places (percentile semantics packed into a parenthetical), but every clause carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-annotation, no-output-schema tool with five parameters, the description is unusually complete on method and caveats but leaves real gaps: the units of the returned angles are never stated, the return structure is unaddressed, and uv_unit is undocumented. An agent could call it correctly on the main path but would be guessing about output interpretation and non-default uv units.

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 0% across five parameters, and the description compensates for three of them (baselines_m, vis_path including the ant1/ant2 column expectation, and b_min_m including its reduced-output consequence). It never explains uv_unit, whose default 'lambda' silently determines how u,v are interpreted, and freq_ghz is only implicit in the lambda notation.

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 first sentence names the two exact quantities computed (maximum recoverable scale and angular resolution) and the input they derive from (baseline lengths). It also explicitly routes flux-on-marginal-scales questions to flux_recovery, so the agent can distinguish this from that sibling without opening a schema.

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 a clear decision path over the three input modes: a list of baselines_m, a vis_path file (with behaviour differing by whether ant1/ant2 are present), or a bare b_min_m which yields only the 0.6 form. It also names a concrete alternative (flux_recovery) for model-based flux estimates, but does not say when to use this versus resolution-oriented siblings such as beam_and_brightness.

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