Skip to main content
Glama
icos-mcp

icos-mcp

Official

describe_variable

Read-onlyIdempotent

Get full details for an ICOS variable, including names, unit, dataset coverage, quality flag reading, licence, DOI, and zarr axes for multi-dimensional data.

Instructions

One variable in full: names, unit, which dataset, its coverage, how its quality flag is read, licence and DOI. For a multi-dimensional variable read through zarr (access 'zarr'), its axes with their labels, the slice /query serves (prescribed) and an xarray line for any other slice.

Input Schema

NameRequiredDescriptionDefault
idYesa variable id from search_variables

Output Schema

NameRequiredDescriptionDefault
idYes
doiNo
ecvNothe GCOS Essential Climate Variable this observation contributes to; ICOS provides the observation, not the ECV product
axesNozarr variables: each extra axis and its labels
nameYes
unitNo
storeYes
accessNoquery: estimate/get_data/aggregate serve it; zarr: a multi-dimensional variable (e.g. the ONEFlux NEE cube) read with xarray -- see zarr_recipe, and `prescribed` for its /query slicequery
domainNo
licenseNo
ecv_roleNoobservation, or derived and how (gap-filled, partitioned, aggregated)
variantsNothe multi-dimensional variables this one is the PRESCRIBED slice of; their other slices are read through zarr (describe_variable on one gives the recipe)
long_nameNo
prescribedNozarr variables: the id of the preferred slice /query serves
query_kindYesstation_time (series at stations), obs_table (ship/cruise observations) or grid (gridded product)
zarr_recipeNo
ecv_relationNo'related' when the variable is outside the ECV's own variable set (NEE to the greenhouse-gas ECV)
quality_flagNo
dataset_titleYes
units_also_asNothe same quantity in other communities' units: multiply by factor (e.g. umol CO2 m-2 s-1 to gC m-2 d-1 or t CO2 km-2 yr-1)
vocabulary_uriNo
quality_controlNohow the store's QC flag is read; apply_qc=true applies the recommended rule
cf_standard_nameNothe CF standard name, given only for an exact match
time_coverage_endNo
vocabulary_issuesNoa gap or an error in CF or in the ECV vocabulary for this variable -- read it before comparing with a CF-named field elsewhere
time_coverage_startNo
vocabulary_mappingsNoSKOS mappings to NVS terms: the CF standard name (P07) as exactMatch or closeMatch with the conversion from this variable's units (factor, offset, to_units; a factor of -1 x ... is a sign flip), and the ECV (EXV) it contributes to

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description's additional content is almost entirely about what data comes back, which overlaps with the existing output schema. It adds no operational context such as cost, size limits, or failure modes for unknown ids.

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

Conciseness3/5

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

It is compact and front-loads the return contract, which is good. However, the second sentence is dense and partly opaque ('the slice /query serves (prescribed)', 'an xarray line for any other slice') and spends its weight on zarr-specific return mechanics rather than on how to call the tool.

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 one-parameter read tool with full schema coverage, an output schema and complete annotations, most required information already exists in structured fields. The description nonetheless leans on return-value detail that the output schema already supplies, while leaving agent-facing decisions such as when to prefer get_data unaddressed.

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 coverage is 100% and the single parameter is documented in the schema as 'a variable id from search_variables'. The description adds no format or validity detail beyond that. Baseline 3 applies when the schema carries the parameter semantics.

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 clear scoping statement ('One variable in full') and enumerates what is resolved: names, unit, dataset, coverage, quality flag, licence, DOI. That is a specific verb-plus-resource picture an agent can match against search_variables (which only finds ids). It never names a sibling explicitly, so differentiation is inferred rather than stated.

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 only: the schema says the id comes from search_variables, and the second sentence hints this tool is the follow-up for zarr-backed multi-dimensional variables. There is no explicit when-to-use versus get_data or aggregate, and no statement of when this tool is unnecessary.

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