Skip to main content
Glama

alma_search

Search ALMA radio telescope observation metadata by object name or coordinates, filter by band and data product type, and retrieve public calibrated data links.

Instructions

ALMA(アルマ望遠鏡, 電波干渉計)の観測データを検索する(認証不要)。

ALMA Science Archive(NAOJ 東アジア鏡, IVOA TAP)の観測メタデータを ADQL で検索する。
mm/サブmm電波観測なので、赤外・可視の望遠鏡とは異なる低温ガス・塵の観測が特徴。

例:「アルマで観測されたM100」「HL Tau のALMA観測(バンド7)」「アルマのキューブデータ」

天体名は **表記ゆれを自動で吸収**する("HL Tau" / "HL_Tau" / "HLTau" 等。アーカイブは
観測者の入力そのままの名前を持つため完全一致だけでは 0 件になりやすい)。それでも
0 件のときは推測せず、アーカイブにある候補名を提示して停止する。

Args:
    object_name: 天体名(例 "M100", "HL Tau", "TW Hya", "Orion")。
    ra: 赤経(度)。object_name 省略時、dec と併用(円錐検索)。
    dec: 赤緯(度)。
    radius: 座標検索の半径(度, 既定 0.3)。
    band: ALMA 受信バンドで絞り込み(1〜10。3≈100GHz帯, 6≈230GHz帯, 7≈345GHz帯)。
    product_type: "cube"(三次元分光データ)/ "image"(二次元画像)/ "visibility" /
        "all"(既定)。obscore は校正済み製品のみを収録する。
    public_only: True で公開データ(data_rights=Public)だけに絞る。
    with_products: True で datalink を引き、実データ製品(校正済み tar・生データ ASDM・
        README・パイプライン製品)の URL 一覧を先頭3件まで添える。
        content にはアイコン付きのクリック可能リンクとして出す。
    limit: 返す件数(既定 8、最大 20)。

メタデータ検索は認証不要。FITS 本体のダウンロードは data_rights=Public のみ可
(Restricted はプロポーザル権限が必要)。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
raNo
decNo
bandNo
limitNo
radiusNo
object_nameNo
public_onlyNo
product_typeNo
with_productsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.27.0
    • addedInput schema / properties / product_type
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Product Type"
      +}
    • addedInput schema / properties / public_only
      Added value: +{
      +  "default": false,
      +  "title": "Public Only",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / with_products
      Added value: +{
      +  "default": false,
      +  "title": "With Products",
      +  "type": "boolean"
      +}
  2. Addedv0.25.2

TDQS

A4.7/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 richly: metadata search needs no auth, FITS download works only for data_rights=Public (Restricted needs proposal rights), obscore contains only calibrated products, name matching auto-absorbs spelling variants, and with_products appends datalink URLs (top 3) as clickable content links.

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?

Purpose, protocol, and a query example are front-loaded before args and caveats. It is dense rather than padded, though the multi-paragraph layout with a long Args block is somewhat heavier than strictly necessary for an agent.

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?

For a 9-parameter, no-annotation, no-output-schema tool, the description covers purpose, all parameters, auth/permission boundaries, zero-result handling, and the with_products enrichment path. Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/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 and it does for all 9 parameters: object_name examples, ra/dec pairing for cone search, radius default 0.3, band 1–10 with frequency mapping (3≈100GHz, 6≈230GHz, 7≈345GHz), product_type enum meanings (cube/image/visibility/all), public_only, with_products, and limit default 8 / max 20.

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 (ALMA 観測データ / ALMA Science Archive 観測メタデータ) and even identifies the access protocol (IVOA TAP, ADQL). It distinguishes ALMA from infrared/optical telescopes by noting mm/submm radio capability, which separates it from siblings like cadc_observations or jaxa_dataset_search.

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?

It gives concrete query examples (M100, HL Tau band 7, cube data) and clarifies the object_name-vs-ra/dec alternative for coordinate cone search. It also defines the 0-result fallback (present candidate names, do not guess). It stops short of explicitly naming when to prefer a different archive sibling, so not a full 5.

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