Skip to main content
Glama

eso_seeing

Retrieve real-time seeing and atmospheric data from ESO Paranal Observatory for the past 12–48 hours to check VLT observing conditions and water vapor.

Instructions

ESO パラナル天文台(チリ, VLT)のリアルタイム大気・シーイング観測データを返す。

例:「パラナル天文台のシーイング」「VLTの観測コンディション」「赤外線観測の水蒸気」

Args: hours: 過去何時間分を取得するか(既定 12、最大 48)。 fields: カンマ区切りの観測フィールド。省略で主要フィールド。

Input Schema

NameRequiredDescriptionDefault
hoursNo
fieldsNodimm_paranal-fwhm,lhatpro_paranal-pwv0,meteo_paranal-temp1,meteo_paranal-rhum1,meteo_paranal-wind_speed1,meteo_paranal-press_inst

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.41.4
    • removedInput schema / properties / fields / title
      Removed value: -"Fields"
    • removedInput schema / properties / hours / title
      Removed value: -"Hours"
    • removedInput schema / title
      Removed value: -"eso_seeingArguments"
  2. Addedv0.25.2

TDQS

B3.4/5.0
Behavior2/5

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

With no annotations, the description carries the full behavioral burden. It discloses that data is real-time and that the lookback is capped at 48 hours, but it does not describe return format, units, permissions, rate limits, or data freshness beyond 'real-time'—significant gaps for an unannotated data-retrieval tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: purpose first, then concrete examples, then parameter notes. Every sentence contributes useful selection or invocation context.

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 low-complexity, two-parameter retrieval tool, the description covers purpose and parameter usage well enough to invoke it. However, with no output schema and no annotations, it does not explain the shape or meaning of returned observations, leaving a meaningful contextual gap.

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, and it does for both parameters: hours is explained as past hours with default 12 and max 48, and fields is explained as comma-separated observation fields with omission falling back to main fields. It does not enumerate valid field names beyond the schema default, but the added semantics are substantial.

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 states a specific verb and resource: returns real-time atmospheric/seeing observation data from ESO Paranal Observatory (Chile, VLT). The examples reinforce the scope. It does not explicitly distinguish this from possibly related siblings such as astronomy_weather or cadc_observations, so it stops short of a 5.

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?

The examples imply when the tool is useful (Paranal seeing, VLT conditions, infrared water vapor), but there is no explicit when-to-use/when-not-to-use guidance or named alternative. Usage is inferable rather than stated.

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