de en es ja ko ru zh

ILO Statistics (ILOSTAT) MCP Server

Name: ILO Statistics (ILOSTAT) MCP Server
Author: SidneyBissoli

by SidneyBissoli

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

ILO-Arbeitsstatistiken (ILOSTAT) — MCP-Server

MCP Version Tools Resources Prompts npm MCP Registry ilo-mcp-server MCP server License: MIT Status

🇧🇷 Leia em Português

Ein öffentlicher, gehosteter, Provenance-first-MCP-Server für die Statistiken der Internationalen Arbeitsorganisation (ILO) — die ILOSTAT-Datenbank — keine Installation, kein Konto, kein API-Schlüssel. Richten Sie Ihren MCP-Client auf den gehosteten Endpunkt und fragen Sie nach Arbeitslosigkeit, Beschäftigung, Löhnen, Arbeitszeit und anderen Arbeitsindikatoren nach Land, Jahr, Geschlecht und Alter. Er läuft auf Cloudflare Workers über Streamable HTTP und spricht mit der offiziellen ILOSTAT-SDMX-REST-API.

Jede Antwort enthält einen Provenance-Block (Quell-URL, Datenstand, tatsächlicher Abrufzeitstempel, Lizenz, ILO-Zitierung) — exakte Zahlen mit Prüfpfad, keine aus Trainingsdaten erratenen Zahlen.

Verwendung (gehostet — keine Einrichtung)

Richten Sie einen beliebigen MCP-Client auf den Streamable-HTTP-Endpunkt:

https://ilo.sidneybissoli.com/mcp

Claude Desktop / Claude Code und andere Clients mit nativer Remote-Unterstützung:

{
  "mcpServers": {
    "ilostat": {
      "url": "https://ilo.sidneybissoli.com/mcp"
    }
  }
}

Für Clients, die MCP-Server als Befehl starten, verwenden Sie die mcp-remote-Brücke:

{
  "mcpServers": {
    "ilostat": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://ilo.sidneybissoli.com/mcp"]
    }
  }
}

Der Hostname ilo-mcp-server.sidneybissoli.workers.dev wird ebenfalls als sekundärer Endpunkt bereitgestellt.

Related MCP server: world-bank-economic-mcp

Lokal ausführen (stdio)

Möchten Sie Abfragen nicht über einen Drittanbieter-Host leiten? Der gleiche Server läuft auch als lokaler stdio-Prozess, der direkt mit der offiziellen ILOSTAT-API spricht — gleiche 4 Tools, Ressourcen und Prompts, gleiche Grenzen, gleicher Provenance-Block, kein Cloudflare im Spiel.

Keine Installation erforderlich — das Paket ist auf npm (ilo-mcp-server, Node ≥ 20):

{
  "mcpServers": {
    "ilostat": {
      "command": "npx",
      "args": ["-y", "ilo-mcp-server"]
    }
  }
}

Oder aus dem Quellcode:

git clone https://github.com/SidneyBissoli/ilo-mcp-server
cd ilo-mcp-server
npm install
npm run build
node dist/cli.js   # serves MCP over stdio (Ctrl+C to stop)

(weisen Sie den Client dann auf node /path/to/ilo-mcp-server/dist/cli.js).

Unterschiede zum gehosteten Server, alle bedingt durch das Fehlen von Cloudflare-Bindings: Der SDMX-Cache lebt im Prozessspeicher (Strukturen und Codelists werden innerhalb einer Sitzung wiederverwendet, nicht über Sitzungen hinweg); der Suchkatalog wird bei der ersten Suche vom offiziellen Endpunkt heruntergeladen (sein tatsächliches retrieved_at wird in der Provenance angegeben); keine Nutzungsmetriken, kein Rate-Limit, keine Authentifizierung. Logs gehen an stderr — stdout transportiert nur den JSON-RPC-Stream. Das Dockerfile des Repositories baut diese Laufzeit (vom Glama-Registry verwendet).

Tools

Tool	Beschreibung	Quelle
`ilo_search_indicators`	Stichwortsuche über ~1.210 Dataflows (paginiert nach `offset`)	lokaler Katalog (kein Upstream-Aufruf)
`ilo_get_indicator_metadata`	Dimensionen, Codelists, Datenstand und Standardauswahl eines Dataflows	gecachte Struktur (Cache-Miss → Upstream)
`ilo_list_dimension_values`	gültige Codes einer Dimension (paginiert nach `offset`)	gecachte Codelist (Cache-Miss → Upstream)
`ilo_get_data`	Beobachtungen gefiltert nach Dimension und Zeitraum	1 Live-REST-Aufruf pro Abfrage

Typischer Ablauf: ilo_search_indicators → ilo_get_indicator_metadata / ilo_list_dimension_values, um gültige Filtercodes zu ermitteln → ilo_get_data mit Länder- und Zeitraumfiltern.

Jede Antwort trägt den Provenance-Block v1.0 (@sbissoli/mcp-provenance, Modi concise/detailed über den provenance_mode-Parameter) auf drei Kanälen: structuredContent, namespace-basiertes _meta (com.sidneybissoli.ilostat/*) und eine Text-Fußzeile.

Ressourcen und Prompts

Drei Ressourcen (statisch, text/markdown, kein Upstream-Aufruf), die ein Client vor dem Aufruf von Tools an den Kontext anhängen kann — sie sparen die 2–3 Ermittlungsaufrufe, die die meisten Sitzungen für „welcher Dataflow, welche Codes" aufwenden:

URI	Inhalt
`ilostat://guide`	Tool-Workflow, stabile Code-Konventionen (`REF_AREA` ISO3 + `X`-Aggregate, `SEX`, `AGE`, `FREQ`, Dataflow-ID-Suffixe), Grenzen, Berichtsregeln
`ilostat://reference/key-dataflows`	verifizierte Dataflow-IDs nach Thema (Arbeitslosigkeit, Beschäftigung, Erwerbsbeteiligung, Löhne, Arbeitsstunden, Informalität, NEET, SDG 8, Produktivität)
`ilostat://reference/provenance`	Bedeutung jedes Provenance-Felds und wie die ILO zitiert wird

Drei Prompts — vorgefertigte Workflows, die die Tools verketten und mit den Zitierregeln enden (Argumente sind Strings; Zeitraum-Argumente optional):

Prompt	Argumente	Ergebnis
`ilo_country_labour_profile`	`country`, `start_period`, `end_period`	Arbeitsmarktprofil eines Landes (Arbeitslosigkeit, Erwerbsbeteiligung, Beschäftigungsquote, Informalität, NEET, Verdienste, Arbeitsstunden)
`ilo_compare_countries`	`countries`, `indicator`, `start_period`, `end_period`	Vergleichstabelle über Länder/Aggregate in einem Datenaufruf, mit Kennzeichnung von modellierten Schätzungen gegenüber gemeldeten Daten
`ilo_indicator_trend`	`indicator`, `country`, `start_period`, `end_period`	Zeitreihe eines Indikators mit erstem/letztem Wert, Höchst-/Tiefstpunkt und `OBS_STATUS`-Brüchen

Jede in den Ressourcen und Prompts genannte Dataflow-ID wird von der Testsuite gegen den Katalog-Seed geprüft, sodass die Dokumentation nicht auf eine ID verweisen kann, die die Suche nicht finden würde.

Verhalten und Grenzen

REF_AREA ist in ilo_get_data erforderlich, bis zu 30 Gebiete pro Aufruf. Das ILO-Gateway läuft bei uneingeschränkten Abfragen in einen Timeout (HTTP 504), daher sendet der Server niemals eine solche; für breite Panels teilen Sie die Gebiete in Chargen auf und/oder paginieren Sie nach Zeitraum (start_period/end_period). Die Fehlermeldung erklärt wie.
Ein Live-REST-Aufruf pro Datenabfrage. Daten werden niemals gecacht — jedes ilo_get_data-Ergebnis wird zur Anfragezeit von ILOSTAT abgerufen. Dataflow-Strukturen (TTL 24 h) und Codelists (TTL 7 Tage, über Dataflows hinweg geteilt) werden gecacht.
data_vintage ist das letzte Aktualisierungsdatum des Dataflows, wie von der ILO veröffentlicht (LAST_UPDATE-Annotation, auf ISO normalisiert).
retrieved_at ist immer der tatsächliche Zeitpunkt der Extraktion von ILOSTAT, der zusammen mit jedem gecachten Wert bewahrt wird — niemals die Build- oder Antwortzeit. Gecachte Antworten geben dies an (served_from_cache: true).
Der Indikatorkatalog ist eine lokale Momentaufnahme (~1.210 Dataflows), die regelmäßig aktualisiert wird; sein eigenes retrieved_at wird in der Provenance von ilo_search_indicators angegeben, sodass sein Alter immer sichtbar ist.
Jeder Upstream-Aufruf enthält einen identifizierbaren User-Agent (Dienst-URL + Kontakt), damit ILO-Administratoren den Betreiber erreichen können.
Sprache: Englisch; Zeitzone: UTC (ILO-Daten werden auf Englisch veröffentlicht).

Provenance-Felder

derived — true nur bei echter Transformation (Aggregation, serverseitig berechnete Rate, Interpolation, Harmonisierung), immer mit einem derivation_note; Einheitenumrechnung und Rundung zählen nicht. Dieser Server transformiert keine Werte, daher ist derived immer false.
notices — gibt die Werte von OBS_STATUS (der SDMX-Status-/Haftungsausschluss-Kanal, z. B. „Break in series") wortwörtlich und mit Zählungen wieder. Technische Attribute pro Beobachtung (DECIMALS usw.) bleiben in den Zeilen (rows[].attributes).

Datenlizenz und Namensnennung

ILOSTAT-Daten und -Metadaten: CC BY 4.0 (seit 03.05.2023; Lizenz geprüft am 04.08.2026).
ILO-Namensnennung in jeder Antwort (citation-Feld): International Labour Organization, ILOSTAT, https://ilostat.ilo.org/data/, accessed <date>.
Das ILO-Logo wird nicht verwendet. Dieser Dienst wird nicht von der ILO unterstützt.

Self-Hosting / Entwicklung

Alles unten Genannte wird nur benötigt, um eine eigene Instanz zu betreiben — es ist nicht erforderlich, um den öffentlichen Server zu nutzen.

npm install
npm run typecheck && npm test   # 96 offline tests (parsers, key, tools, output contract, resources/prompts, in-memory catalogue, eval fixtures)
npm run dev                     # http://localhost:8787/mcp (Worker)
npm run build && npm start      # stdio runtime (dist/cli.js)

# Catalogue seed (D1) — required before first use:
node scripts/seed-catalog.mjs   # downloads via curl and generates scripts/seed-catalog.sql
npx wrangler d1 execute ilostat-catalog --local  --file=scripts/seed-catalog.sql
npx wrangler d1 execute ilostat-catalog --remote --file=scripts/seed-catalog.sql

npm run deploy
node scripts/smoke-mcp.mjs      # smoke test against production (initialize → 4 tools → errors)
npm run manifest:lhm            # regenerate tools/resources/prompts in lhm.plugin.json from the real server
# (the seed also writes tests/fixtures/catalog-ids.txt — the versioned id list the tests check resources/prompts against)

Bindings (siehe wrangler.jsonc): KV SDMX_CACHE, D1 CATALOG_DB, Durable Object USAGE (SQLite-gestützte Nutzungszähler), CF_VERSION_METADATA. Optionale Bearer-Authentifizierung (wrangler secret put API_KEY); Token-Bucket-Rate-Limit pro IP.

Hinweise für Betreiber:

ILOSTAT gibt JSON nur zurück, wenn über den Accept-Header ausgehandelt (application/vnd.sdmx.{structure,data}+json); ?format= wird ignoriert und gibt XML zurück.
Das ILO-Gateway antwortet mit HTTP 500 (languageTag1) auf den Accept-Language: *-Header, den Nodes fetch (undici) standardmäßig sendet; daher setzt jeder Upstream-Aufruf Accept-Language: en explizit (Cloudflares Laufzeit sendet keinen solchen Header, sodass der Worker nie betroffen war). Es erwartet außerdem einen identifizierbaren User-Agent.
Katalog-Aktualisierung ist manuell (kein Cron): vierteljährlich oder sofort, wenn ein Dataflow, der upstream existiert, nicht in der Suche erscheint. Vorgehen: die drei Seed-Befehle oben. Datenabfragen sind immer live, sodass nur der Suchkatalog altern kann — und sein Alter wird in der Provenance offengelegt.

Evals

@sbissoli/mcp-evals: 24 Fixtures in evals/fixtures/queries.ts, offline validiert in npm test. Der Lauf mit einem echten Modell (npm run eval) verwendet die Anthropic-API und benötigt ANTHROPIC_API_KEY (ohne diesen bricht er mit Hinweisen ab). Lauf vom 07.08.2026: Top-1 100 % (24/24) — evals/results/.

End-to-End: 10 komplexe Fragen mit einer einzelnen verifizierbaren Antwort in evals/e2e/evaluation.xml, Antworten manuell gegen die Produktion validiert (evals/e2e/validacao-respostas.md). Lauf vom 07.08.2026 (Sonnet): 9/10 exakte Zeichenkette; 10/10 inhaltlich — evals/results/2026-08-07-e2e.md.

Endpunkte

Route	Zweck
`/`	Landingpage (Dienstidentität + Kontakt — öffentlich)
`/health`	Liveness-Check
`/status`	Version, Anzahl und Namen der Tools/Ressourcen/Prompts, Provenance-Vertragsversion, aktuelles Deployment (speist die README-Badges)
`/metrics`	aggregierte Nutzung (nur MCP-Endpunkt; keine IP-Adressen, keine Anfrageinhalte)
`/mcp`	MCP Streamable HTTP

Sicherheit

Snyk Agent Scan (2026-08-07): bestanden — Bericht in security/.

Lizenz

Quellcode: MIT. Daten: ILOSTAT, CC BY 4.0 (siehe „Datenlizenz und Quellenangabe“ oben).

Datenschutz

Datenschutzerklärung des gehosteten Dienstes: PRIVACY.md.

Kontakt

Sidney da S. P. Bissoli — sbissoli76@gmail.com. Dieser Dienst wird nicht von der ILO befürwortet.

Available Tools

6 tools

fetchDeep Research DocumentA

Read-onlyIdempotent

Inspect

Returns the full document for an id obtained from search, as { id, title, text, url, metadata }: text is the readable content (Markdown) and url the canonical public page to cite.

Companion of search in the OpenAI Deep Research contract, over the ILOSTAT labour statistics (≈1,200 SDMX dataflows: employment, unemployment, wages, working time, informality, SDG labour indicators) catalog. Only ids returned by search are valid; an unknown id returns an error. The ilo_* tools remain the tools for data queries.

Behavior: read-only and idempotent — a live GET against the public source when the document needs it.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Identifier of a document returned by `search`

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Unique identifier of the document on this server; what `fetch` takes
`url`	Yes	Canonical public URL of the document — ChatGPT's citation depends on it
`text`	Yes	Full readable content of the document (Markdown)
`title`	Yes	Human-readable title of the document
`metadata`	No	Additional key/value pairs about the document (kind, source, period…)
`provenance`	Yes	Portfolio provenance block. concise (default): source, source_url, data_vintage, retrieved_at, retrieval, citation, license; detailed: the full canonical block (dataset, dimension_key, notices, served_from_cache, ...). retrieval is the origin diagnostic of this call — requests made to ILOSTAT, attempts including retries, anomalies overcome (timeout, network, rate_limited, http_5xx, http_4xx, malformed_body) and unstable (true when anything had to be retried: treat the figures as obtained with difficulty); null when nothing was fetched from ILOSTAT (catalogue or cached answer). Optional keys (field_sources, notices, derived, derivation_note, revision) appear only when there is something to say
`attribution`	Yes

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, open-world and non-destructive, so safety is covered. The description earns credit by adding the error behavior on unknown ids, noting it is a live GET against the public source, and characterizing the corpus (≈1,200 SDMX dataflows) — genuine context beyond the structured fields.

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-loads the return contract, then the catalogue/contract context, then behavior — a sensible ordering. It is dense (parenthetical field list, domain aside) but each sentence carries information an agent needs; nothing is padding.

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 annotations covering safety and an output schema covering the return shape, the description supplies the remaining essentials: provenance of the id, the error case, cross-tool routing to `ilo_*`, and the live-fetch behavior. Nothing needed to call this 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 single `id` parameter is documented in the schema itself (baseline 3). The description adds real meaning by tying the id to `search` output and stating the failure mode for ids outside that set, which the schema does not convey.

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 and resource ('Returns the full document for an id obtained from `search`') and enumerates the exact return fields. It also distinguishes itself from siblings by naming `search` as its companion and declaring that 'the `ilo_*` tools remain the tools for data queries'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit conditions: only ids returned by `search` are valid, an unknown id returns an error, and data-query needs must go to the `ilo_*` tools instead. Both the when-to-use and the when-not-to-use are stated, naming the alternatives.

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

ilo_get_dataGet ILOSTAT dataA

Read-onlyIdempotent

Inspect

Statistical observations from one ILOSTAT dataflow, filtered by dimension codes (filters, e.g. {"REF_AREA": ["BRA","ARG"], "SEX": "SEX_T"}) and period (start_period/end_period, e.g. "2015"/"2024"). REF_AREA is required, maximum 30 areas per call — for broad panels, split areas into batches and/or paginate by period. Unfiltered dimensions return all their categories. Does not aggregate, convert or otherwise transform values (raw ILOSTAT data only): read each value with the unit and multiplier the ILO states in its row attributes (UNIT_MEASURE, UNIT_MULT — e.g. UNIT_MULT 3 = thousands). Read TIME_PERIOD with the FREQ column (annual, quarterly or monthly) and OBS_STATUS when present (break in series, estimated or provisional value). Values are the current release, dated by data_vintage (the dataflow LAST_UPDATE): the ILO revises published figures and re-estimates modelled series (_2 ids) at each release, past years included. Does not search indicators (use ilo_search_indicators).

ParametersJSON Schema

Name	Required	Description
`filters`	Yes	Dimension id → code or list of codes (from ilo_list_dimension_values). REF_AREA is required (up to 30 area codes); any other dimension is optional and, left out, returns all of its categories.
`dataflow`	Yes	Dataflow id from ilo_search_indicators (e.g. "DF_UNE_DEAP_SEX_AGE_RT")
`end_period`	No	Last period, e.g. "2024"
`start_period`	No	First period, e.g. "2015"
`provenance_mode`	No	Provenance verbosity: 'concise' (default — source, url, vintage, retrieval date, citation, license) or 'detailed' (full canonical block with dataset, dimension key and notices)
`last_n_observations`	No	Alternative to periods: only the latest N observations per series

Output Schema

ParametersJSON Schema

Name	Required	Description
`rows`	Yes
`columns`	Yes
`dataflow`	Yes
`provenance`	Yes	Portfolio provenance block. concise (default): source, source_url, data_vintage, retrieved_at, retrieval, citation, license; detailed: the full canonical block (dataset, dimension_key, notices, served_from_cache, ...). retrieval is the origin diagnostic of this call — requests made to ILOSTAT, attempts including retries, anomalies overcome (timeout, network, rate_limited, http_5xx, http_4xx, malformed_body) and unstable (true when anything had to be retried: treat the figures as obtained with difficulty); null when nothing was fetched from ILOSTAT (catalogue or cached answer). Optional keys (field_sources, notices, derived, derivation_note, revision) appear only when there is something to say
`rows_count`	Yes
`attribution`	Yes

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), yet the description adds substantial behavior beyond them: values are the current release dated by data_vintage, the ILO revises past years and re-estimates modelled (_2) series, no aggregation or transformation occurs, and how to read UNIT_MULT/OBS_STATUS/FREQ. This is rich, non-obvious operational context.

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 core purpose and the required-REF_AREA constraint are front-loaded, and most sentences carry distinct information (units, revisions, alternatives). It is a dense single paragraph, so slightly more structure or trimming would improve scannability, but there is little outright waste.

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, the description needn't restate return shapes, and it correctly focuses on interpretation (units, multiplier, series revisions) plus the required-parameter and batching constraints. Nothing an agent needs to call this correctly appears to be 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 description coverage is 100%, so the baseline is 3. The description still adds value with a concrete filters example, the REF_AREA-cap and batching rule, and the 'unfiltered dimensions return all categories' semantics, though it largely reinforces what the schema already states.

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 and resource — statistical observations from one ILOSTAT dataflow — and explicitly scopes what it is not ('Does not search indicators (use ilo_search_indicators)'). This lets an agent distinguish it from ilo_search_indicators and ilo_get_indicator_metadata without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete when-to-use conditions and alternatives: use ilo_search_indicators for discovery, ilo_list_dimension_values for dimension codes, and split areas into batches when exceeding the 30-area cap. It names the batching/pagination strategy for broad panels, which is exactly the operational guidance an agent needs.

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

ilo_get_indicator_metadataGet ILOSTAT indicator metadataA

Read-onlyIdempotent

Inspect

Structure of one ILOSTAT dataflow: dimensions (in SDMX key order), their codelists, the time dimension, the source's default selection and the data vintage (last update at the ILO). Use before ilo_get_data to know which filters exist. Does not return statistical values and does not list the codes themselves (use ilo_list_dimension_values).

ParametersJSON Schema

Name	Required	Description	Default
`dataflow`	Yes	Dataflow id from ilo_search_indicators (e.g. "DF_UNE_DEAP_SEX_AGE_RT")
`provenance_mode`	No	Provenance verbosity: 'concise' (default — source, url, vintage, retrieval date, citation, license) or 'detailed' (full canonical block with dataset, dimension key and notices)

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes
`name`	Yes
`version`	Yes
`dimensions`	Yes
`provenance`	Yes	Portfolio provenance block. concise (default): source, source_url, data_vintage, retrieved_at, retrieval, citation, license; detailed: the full canonical block (dataset, dimension_key, notices, served_from_cache, ...). retrieval is the origin diagnostic of this call — requests made to ILOSTAT, attempts including retries, anomalies overcome (timeout, network, rate_limited, http_5xx, http_4xx, malformed_body) and unstable (true when anything had to be retried: treat the figures as obtained with difficulty); null when nothing was fetched from ILOSTAT (catalogue or cached answer). Optional keys (field_sources, notices, derived, derivation_note, revision) appear only when there is something to say
`attribution`	Yes
`data_vintage`	Yes
`time_dimension`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower; the description still adds real behavioral boundaries by stating it 'does not return statistical values' and 'does not list the codes themselves'. It does not mention auth requirements, rate limits, or payload size, but the exclusion statements are meaningful additions beyond structured fields.

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?

Three sentences, front-loaded with the resource and its returned structure, then sequencing guidance, then exclusions. No filler or redundancy; every clause earns its place.

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?

An output schema exists, so return values need not be described in prose; the description instead supplies what the schema cannot — when to call it, what it excludes, and how it relates to sibling tools. Nothing an agent needs to invoke this correctly is missing.

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 100%, including the dataflow id format example and the provenance_mode enum semantics, so the schema does the heavy lifting and a baseline 3 applies. The description adds only indirect context about SDMX key ordering and default selection rather than per-parameter meaning.

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 names a specific resource (one ILOSTAT dataflow) and enumerates exactly what is returned: dimensions in SDMX key order, codelists, time dimension, default selection, and data vintage. It explicitly bounds scope against siblings, telling the agent it is not a value-returning or code-listing tool. An agent can distinguish this from ilo_get_data and ilo_list_dimension_values without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit sequencing instruction — 'Use before ilo_get_data to know which filters exist' — and names the alternative tool for the adjacent task ('use ilo_list_dimension_values'). Both the when and the not-when are stated, leaving nothing to inference.

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

ilo_list_dimension_valuesList valid codes of a dimensionA

Read-onlyIdempotent

Inspect

Valid codes (id + label) of one dimension of an ILOSTAT dataflow — e.g. the country/area codes of REF_AREA (ISO 3166-1 alpha-3 such as BRA, plus X-codes for aggregates such as X01 World) or the categories of SEX (SEX_T/SEX_M/SEX_F) and AGE. Use search to resolve a name to a code (e.g. search "Brazil") instead of paging through hundreds of codes; codelists are shared across dataflows, so a code found here is valid wherever the same codelist is used. Use to build correct ilo_get_data filters. Does not return statistical values, does not say which codes actually have data for a given dataflow, and is not applicable to the time dimension (filter it via start_period/end_period in ilo_get_data).

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum codes returned (default 200)
`offset`	No	Codes to skip, for pagination (default 0)
`search`	No	Case-insensitive filter on code id or label
`dataflow`	Yes	Dataflow id the dimension belongs to
`dimension`	Yes	Dimension id from ilo_get_indicator_metadata (e.g. "REF_AREA", "SEX")
`provenance_mode`	No	Provenance verbosity: 'concise' (default — source, url, vintage, retrieval date, citation, license) or 'detailed' (full canonical block with dataset, dimension key and notices)

Output Schema

ParametersJSON Schema

Name	Required	Description
`offset`	Yes
`values`	Yes
`showing`	Yes
`codelist`	Yes
`dataflow`	Yes
`has_more`	Yes
`dimension`	Yes
`provenance`	Yes	Portfolio provenance block. concise (default): source, source_url, data_vintage, retrieved_at, retrieval, citation, license; detailed: the full canonical block (dataset, dimension_key, notices, served_from_cache, ...). retrieval is the origin diagnostic of this call — requests made to ILOSTAT, attempts including retries, anomalies overcome (timeout, network, rate_limited, http_5xx, http_4xx, malformed_body) and unstable (true when anything had to be retried: treat the figures as obtained with difficulty); null when nothing was fetched from ILOSTAT (catalogue or cached answer). Optional keys (field_sources, notices, derived, derivation_note, revision) appear only when there is something to say
`attribution`	Yes
`next_offset`	No
`total_codes`	Yes

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already cover readOnly/idempotent/openWorld/destructive, so the bar is lower, yet the description adds meaningful negative-scope context: no statistical values returned, no signal of which codes actually have data, time dimension excluded. It does not mention pagination limits or default page size behavior beyond what the schema states.

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 the core definition followed by usage, alternative, and exclusions in a logical order. Dense and slightly run-on with parenthetical asides, but nearly every clause carries actionable information.

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 6-param, output-schema-backed lookup tool, the description covers purpose, alternatives, negative scope, and the relationship to downstream filtering. An agent has everything needed to call it correctly without the return shape being restated.

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 baseline is 3, but the description adds real meaning beyond the schema: what `search` does semantically (resolve a name like 'Brazil' to a code), that codelists are shared across dataflows, and example dimension ids. It says nothing extra about provenance_mode or limit/offset.

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 and resource - valid codes (id + label) of one dimension of an ILOSTAT dataflow - and grounds it with concrete examples (REF_AREA ISO 3166-1 alpha-3, SEX_T/SEX_M/SEX_F). Easily distinguished from siblings like ilo_get_data or ilo_get_indicator_metadata.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes to `search` for name-to-code resolution rather than paging, states the downstream purpose (build correct ilo_get_data filters), and gives exclusions: not statistical values, not a data-availability check, not applicable to the time dimension (use start_period/end_period instead).

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

ilo_search_indicatorsSearch ILOSTAT indicatorsA

Read-onlyIdempotent

Inspect

Search the ILOSTAT catalogue of ~1,200 indicator dataflows by keywords in the name or id (e.g. "unemployment rate sex age"). All terms must match (AND, case-insensitive), so start with 2–3 English words and drop terms if you get 0 results. Everyday and US wording is resolved to the ILO's own (labor→labour, wages/salary→earnings, informality→informal, gender→sex, productivity→output per worker); when that happens the response says so in vocabulary_notes. Results are ranked by ILO relevance weight, not by match count. Reading the id tells you the shape: suffix _RT = rate/ratio, NB = number (usually thousands); dataflows whose second token starts with 2 (e.g. DF_UNE_2EAP…) are ILO modelled estimates with full country/year coverage, the others are reported national data. Returns dataflow ids to use with ilo_get_data / ilo_get_indicator_metadata. Searches the local catalogue only — it does not return statistical values (use ilo_get_data), does not search dimension codes such as countries (use ilo_list_dimension_values) and does not cover non-ILO sources.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum results (default 20)
`query`	Yes	Keywords, matched against dataflow name and id (AND between terms)
`offset`	No	Results to skip, for pagination (default 0)
`provenance_mode`	No	Provenance verbosity: 'concise' (default — source, url, vintage, retrieval date, citation, license) or 'detailed' (full canonical block with dataset, dimension key and notices)

Output Schema

ParametersJSON Schema

Name	Required	Description
`hint`	No
`offset`	Yes
`showing`	Yes
`has_more`	Yes
`indicators`	Yes
`provenance`	Yes	Portfolio provenance block. concise (default): source, source_url, data_vintage, retrieved_at, retrieval, citation, license; detailed: the full canonical block (dataset, dimension_key, notices, served_from_cache, ...). retrieval is the origin diagnostic of this call — requests made to ILOSTAT, attempts including retries, anomalies overcome (timeout, network, rate_limited, http_5xx, http_4xx, malformed_body) and unstable (true when anything had to be retried: treat the figures as obtained with difficulty); null when nothing was fetched from ILOSTAT (catalogue or cached answer). Optional keys (field_sources, notices, derived, derivation_note, revision) appear only when there is something to say
`attribution`	Yes
`next_offset`	No
`total_matches`	Yes
`vocabulary_notes`	No

TDQS

A4.8/5.0

Behavior5/5

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

Annotations cover the safety profile (readOnly, idempotent, closed-world), and the description corroborates the closed-world hint with 'Searches the local catalogue only'. Beyond that it discloses non-obvious behavior: synonym resolution to ILO vocabulary with a vocabulary_notes signal in the response, relevance-weight ranking rather than match count, and the id-suffix encoding (_RT vs _NB, modelled estimates).

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?

Dense but front-loaded: retrieval purpose, query syntax, then result interpretation and routing, with zero filler sentences. It runs long for a search tool and the id-suffix decoding could be deferred to metadata, but every sentence carries actionable signal.

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?

Covers the query semantics, the synonym/ranking caveats an agent could otherwise misread, and the downstream tools to route to; an output schema exists so return values need not be described. Nothing required to invoke or interpret results 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 limit/offset/provenance_mode are already documented and the baseline is 3. The description still adds real meaning for the query parameter beyond the schema, specifying AND-matching across name and id, case-insensitivity, term-dropping strategy, and synonym normalization behavior.

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 and resource with scope: 'Search the ILOSTAT catalogue of ~1,200 indicator dataflows by keywords in the name or id'. It explicitly names what it is not (does not return statistical values, does not search dimension codes), so it is unambiguously separable from ilo_get_data and ilo_list_dimension_values.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives both when-to-use and when-not: use this for finding dataflow ids, then use ilo_get_data for values and ilo_list_dimension_values for dimension codes, plus an explicit exclusion of non-ILO sources. It even includes operational advice on query construction (start with 2–3 English words, drop terms on zero results).

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

searchDeep Research SearchA

Read-onlyIdempotent

Inspect

Searches the ILOSTAT labour statistics (≈1,200 SDMX dataflows: employment, unemployment, wages, working time, informality, SDG labour indicators) catalog and returns up to 10 matching documents as { id, title, url }, ordered by relevance (an empty list means nothing matched).

This tool exists for the OpenAI Deep Research contract: ChatGPT deep research, company knowledge and research workflows over the Responses API require exactly the tools search and fetch. Pass one of the returned ids to fetch to read the document. For direct questions and for data (values, series, rankings) prefer the ilo_* tools, which return the actual data with provenance — this is a catalog index, not a data query.

Query: natural language or keywords, Portuguese or English; accents and case are ignored.

Behavior: read-only and idempotent — the catalog comes from the public source and is cached in memory.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search terms, natural language or keywords (accents and case are ignored)

Output Schema

ParametersJSON Schema

Name	Required	Description
`results`	Yes	Matching documents, in relevance order
`provenance`	Yes	Portfolio provenance block. concise (default): source, source_url, data_vintage, retrieved_at, retrieval, citation, license; detailed: the full canonical block (dataset, dimension_key, notices, served_from_cache, ...). retrieval is the origin diagnostic of this call — requests made to ILOSTAT, attempts including retries, anomalies overcome (timeout, network, rate_limited, http_5xx, http_4xx, malformed_body) and unstable (true when anything had to be retried: treat the figures as obtained with difficulty); null when nothing was fetched from ILOSTAT (catalogue or cached answer). Optional keys (field_sources, notices, derived, derivation_note, revision) appear only when there is something to say
`attribution`	Yes

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so 'read-only and idempotent' largely restates structured data. However, the description adds genuinely new behavior: the catalog is public-source and cached in memory, results are capped at 10 and relevance-ordered, and an empty list is the documented no-match signal.

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 the core action and return shape, then layered with routing guidance. The Deep Research contract paragraph is slightly long but earns its place by explaining the tool's raison d'être and the required pairing with `fetch`.

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?

An output schema exists so return values need not be spelled out, yet the description still summarizes them. For a one-parameter search tool it covers scope, result semantics, failure semantics, routing alternatives, and the fetch handoff — nothing an agent needs 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?

With a single parameter at 100% schema coverage the baseline is 3, and the schema already states that accents and case are ignored. The description still adds value by clarifying that queries may be natural language or keywords and that both Portuguese and English are supported — language support is absent from the schema.

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 and resource ('searches the ILOSTAT labour statistics catalog'), quantifies the result cap (up to 10 documents) and names the exact return shape { id, title, url } with relevance ordering. It also explicitly distinguishes itself from the ilo_* sibling tools as a catalog index rather than a data query.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use (OpenAI Deep Research / Responses API contract requiring exactly `search` and `fetch`) and explicit when-not-to-use ('for direct questions and for data prefer the ilo_* tools'). It also chains usage by telling the agent to pass a returned id to `fetch`.

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