ilostat-mcp-server

Describe an ILOSTAT dataset

ilostat_describe_indicator

Read-onlyIdempotent

Explain one ILOSTAT dataset before comparing numbers: its definition, unit and multiplier, frequency variants and coverage, the sex and breakdown codes in use across its frequencies (the total code of each breakdown marked), the reference areas it covers, whether it carries World/regional/income-group aggregates, and how its observations are classed as reported, modelled, or projected. Accepts a dataset ID (UNE_DEAP_SEX_AGE_RT_A) or a bare indicator code (UNE_DEAP_SEX_AGE_RT), which describes every frequency. An unknown code returns found: false with guidance.

Input Schema

Name	Required	Description	Default
`dataset_id`	Yes	One dataset ID (indicator code plus _A, _Q, or _M, e.g. UNE_DEAP_SEX_AGE_RT_A) or a bare indicator code (UNE_DEAP_SEX_AGE_RT), as ilostat_search_indicators returns them. Case-insensitive; a DF_ prefix (the SDMX dataflow form) is stripped.

Output Schema

Name	Required	Description
`cap`	No	The most related indicators listed.
`unit`	No	Unit of the values, already in the multiplier scale; absent when unresolved.
`error`	No	Present when the call failed. Absent on success.
`found`	No	False when no dataset or indicator has the code.
`label`	No	Indicator label as ILOSTAT publishes it.
`shown`	No	Related indicators listed.
`notice`	No	Where to find breakdown codes and units when the structure service did not supply them, and how to list every related indicator when the list is cut — whichever apply, joined.
`measure`	No	Measure (the quantity measured, shared by breakdown variants) code and label.
`subject`	No	Subject code and label.
`database`	No	Source database code and label.
`datasets`	No	Every frequency variant of the indicator, annual first.
`guidance`	No	On a miss: how to find a valid dataset ID.
`indicator`	No	Indicator code.
`ref_areas`	No	Reference areas the indicator covers across its frequencies, from ILOSTAT's structure service; absent when structure_status is unavailable.
`truncated`	No	True when related_datasets lists fewer than related_total.
`basis_rule`	No	How observations are classed reported, modelled_estimate, or projection.
`breakdowns`	No	Breakdown codes in use, from ILOSTAT's structure service; absent when structure_status is unavailable.
`dataset_id`	No	The dataset requested, when a dataset ID (not a bare indicator code) was given.
`definition`	No	ILOSTAT definition of the indicator, HTML stripped; links kept as "text (url)".
`attribution`	No	Citation to keep with any use of the data.
`catalog_as_of`	No	ISO timestamp the catalog was last confirmed current.
`default_slice`	No	The dataset's total codes from its default view — the slice ilostat_compare_geographies uses when sex, classif1, or classif2 is omitted; a breakdown with no total (deciles) is left out.
`related_total`	No	How many other indicators share this measure. ilostat_search_indicators with measure set to measure.code lists them all.
`has_aggregates`	No	Whether the requested dataset (or, for an indicator code, any of its datasets) carries World, regional, or income-group rows.
`related_datasets`	No	The first 20 other indicators sharing this measure under other breakdowns, by code; related_total counts all of them.
`structure_status`	No	unavailable when ILOSTAT's structure service has no entry for the indicator or cannot be reached; breakdowns, default_slice, unit, and ref_areas are then absent.

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedOct 15, 2026

addedOutput schema / properties / cap

Added value: +{
+  "description": "The most related indicators listed.",
+  "type": "number"
+}

changedOutput schema / properties / notice / description

Previous value: -"Where to find breakdown codes and units when the structure service did not supply them."New value: +"Where to find breakdown codes and units when the structure service did not supply them, and how to list every related indicator when the list is cut — whichever apply, joined."

changedOutput schema / properties / related_datasets / description

Previous value: -"Up to 20 other indicators sharing this measure under other breakdowns."New value: +"The first 20 other indicators sharing this measure under other breakdowns, by code; related_total counts all of them."

addedOutput schema / properties / related_total

Added value: +{
+  "description": "How many other indicators share this measure. ilostat_search_indicators with measure set to measure.code lists them all.",
+  "type": "number"
+}

addedOutput schema / properties / shown

Added value: +{
+  "description": "Related indicators listed.",
+  "type": "number"
+}

addedOutput schema / properties / truncated

Added value: +{
+  "description": "True when related_datasets lists fewer than related_total.",
+  "type": "boolean"
+}

First observedOct 4, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well beyond the readOnly/idempotent/openWorld annotations: it discloses the metadata categories returned, the total-code marking of breakdowns, and the error contract ('an unknown code returns found: false with guidance'). It also explains code-form handling (ID vs bare code, DF_ prefix stripping), which the annotations cannot convey.

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?

Front-loaded with purpose and error behavior in two sentences with no filler. The first sentence is a dense enumeration of return categories, which is long but each clause carries information an agent needs to decide whether to call it.

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?

With an output schema present and safety annotations covering the read-only/idempotent profile, the description only needs to add purpose, input-form semantics, and error handling — all of which it does. Nothing needed to invoke it correctly is missing.

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 coverage is 100%, so the baseline is 3, but the description adds real semantics: a bare indicator code 'describes every frequency' versus a suffixed dataset ID describing one, and the failure behavior for unknown codes. That meaning is not present in the schema description.

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?

States a specific verb (explain/describe) and resource (one ILOSTAT dataset) and enumerates exactly what the response covers: definition, unit/multiplier, frequency variants, breakdown codes, reference areas, aggregates, and observation status. This is clearly distinguishable from data-fetching siblings like ilostat_query_indicator and lookup siblings like ilostat_search_indicators.

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 opening clause 'before comparing numbers' implies a workflow position but never names alternatives (e.g. use ilostat_query_indicator for values, ilostat_search_indicators to find codes) or states exclusions. Usage is implied rather than explicit.

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

All ilostat-mcp-server tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.