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

Servidor MCP de Estadísticas Laborales de la OIT (ILOSTAT)

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

🇧🇷 Leia em Português

Un servidor MCP público, alojado y con prioridad de procedencia para las estadísticas de la Organización Internacional del Trabajo (OIT) — la base de datos ILOSTAT — sin instalación, sin cuenta, sin clave API. Apunta tu cliente MCP al endpoint alojado y pregunta sobre desempleo, empleo, salarios, tiempo de trabajo y otros indicadores laborales por país, año, sexo y edad. Se ejecuta en Cloudflare Workers sobre Streamable HTTP y se comunica con la API REST oficial de ILOSTAT SDMX.

Cada respuesta incluye un bloque de procedencia (URL de origen, antigüedad de los datos, marca de tiempo real de recuperación, licencia, cita de la OIT) — cifras exactas con un rastro de auditoría, no números adivinados a partir de datos de entrenamiento.

Úsalo (alojado — sin configuración)

Apunta cualquier cliente MCP al endpoint Streamable HTTP:

https://ilo.sidneybissoli.com/mcp

Claude Desktop / Claude Code y otros clientes con soporte remoto nativo:

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

Para clientes que lanzan servidores MCP como un comando, usa el puente mcp-remote:

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

El nombre de host ilo-mcp-server.sidneybissoli.workers.dev también se sirve, como secundario.

Related MCP server: world-bank-economic-mcp

Ejecutar localmente (stdio)

¿Prefieres no enrutar consultas a través de un host de terceros? El mismo servidor también se ejecuta como un proceso stdio local que se comunica directamente con la API oficial de ILOSTAT — las mismas 4 herramientas, recursos y prompts, los mismos límites, el mismo bloque de procedencia, sin Cloudflare en el camino.

No se necesita instalación — el paquete está en npm (ilo-mcp-server, Node ≥ 20):

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

O desde el código fuente:

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)

(luego apunta el cliente a node /path/to/ilo-mcp-server/dist/cli.js).

Diferencias con el servidor alojado, todas debidas a la ausencia de bindings de Cloudflare: la caché SDMX vive en la memoria del proceso (las estructuras y listas de códigos se reutilizan dentro de una sesión, no entre sesiones); el catálogo de búsqueda se descarga del endpoint oficial en la primera búsqueda (su retrieved_at real se informa en la procedencia); sin métricas de uso, límite de tasa ni autenticación. Los registros van a stderr — stdout lleva solo el flujo JSON-RPC. El Dockerfile del repositorio construye este runtime (usado por el registro Glama).

Herramientas

Herramienta	Qué hace	Fuente
`ilo_search_indicators`	búsqueda por palabras clave en ~1,210 dataflows (paginada por `offset`)	catálogo local (sin llamada upstream)
`ilo_get_indicator_metadata`	dimensiones, listas de códigos, antigüedad y selección predeterminada de un dataflow	estructura en caché (fallo → upstream)
`ilo_list_dimension_values`	códigos válidos de una dimensión (paginado por `offset`)	lista de códigos en caché (fallo → upstream)
`ilo_get_data`	observaciones filtradas por dimensión y período	1 llamada REST en vivo por consulta

Flujo típico: ilo_search_indicators → ilo_get_indicator_metadata / ilo_list_dimension_values para descubrir códigos de filtro válidos → ilo_get_data con filtros de país y período.

Cada respuesta lleva el bloque de procedencia v1.0 (@sbissoli/mcp-provenance, modos concise/detailed mediante el parámetro provenance_mode) en tres canales: structuredContent, _meta con espacio de nombres (com.sidneybissoli.ilostat/*) y un pie de página de texto.

Recursos y prompts

Tres recursos (estáticos, text/markdown, sin llamada upstream) que un cliente puede adjuntar al contexto antes de llamar a las herramientas — ahorran las 2–3 llamadas de descubrimiento que la mayoría de las sesiones gastan en "qué dataflow, qué códigos":

URI	Contenido
`ilostat://guide`	flujo de trabajo de las herramientas, convenciones de códigos estables (`REF_AREA` ISO3 + agregados `X`, `SEX`, `AGE`, `FREQ`, sufijos de id de dataflow), límites, reglas de reporte
`ilostat://reference/key-dataflows`	ids de dataflows verificados por tema (desempleo, empleo, participación, salarios, horas, informalidad, NEET, ODS 8, productividad)
`ilostat://reference/provenance`	significado de cada campo de procedencia y cómo citar a la OIT

Tres prompts — flujos de trabajo listos que encadenan las herramientas y terminan con las reglas de cita (los argumentos son cadenas; los argumentos de período son opcionales):

Prompt	Argumentos	Resultado
`ilo_country_labour_profile`	`country`, `start_period`, `end_period`	perfil del mercado laboral de un país (desempleo, participación, tasa de empleo, informalidad, NEET, ingresos, horas)
`ilo_compare_countries`	`countries`, `indicator`, `start_period`, `end_period`	tabla comparativa entre países/agregados en una sola llamada de datos, señalando estimaciones modeladas frente a datos reportados
`ilo_indicator_trend`	`indicator`, `country`, `start_period`, `end_period`	serie temporal de un indicador con primero/último, pico/valle y rupturas de `OBS_STATUS`

Cada id de dataflow citado en los recursos y prompts se verifica contra la semilla del catálogo mediante el conjunto de pruebas, por lo que la documentación no puede apuntar a un id que la búsqueda no encontraría.

Comportamiento y límites

REF_AREA es obligatorio en ilo_get_data, hasta 30 áreas por llamada. La pasarela de la OIT agota el tiempo (HTTP 504) en consultas sin restricciones, por lo que el servidor nunca emite una; para paneles amplios, divide las áreas en lotes y/o pagina por período (start_period/end_period). El mensaje de error explica cómo.
Una llamada REST en vivo por consulta de datos. Los datos nunca se almacenan en caché — cada resultado de ilo_get_data se obtiene de ILOSTAT en el momento de la solicitud. Las estructuras de dataflow (TTL 24 h) y las listas de códigos (TTL 7 días, compartidas entre dataflows) se almacenan en caché.
data_vintage es la fecha de última actualización del dataflow publicada por la OIT (anotación LAST_UPDATE, normalizada a ISO).
retrieved_at es siempre el instante real de extracción de ILOSTAT, conservado junto con cualquier valor en caché — nunca el tiempo de compilación o de respuesta. Las respuestas en caché lo indican (served_from_cache: true).
El catálogo de indicadores es una instantánea local (~1,210 dataflows), actualizada periódicamente; su propio retrieved_at se informa en la procedencia de ilo_search_indicators, por lo que su antigüedad siempre es visible.
Cada llamada upstream lleva un User-Agent identificable (URL del servicio + contacto), para que los administradores de la OIT puedan contactar al operador.
Idioma: inglés; zona horaria: UTC (los datos de la OIT se publican en inglés).

Campos de procedencia

derived — true solo para transformación real (agregación, tasa calculada por el servidor, interpolación, armonización), siempre con una derivation_note; la conversión de unidades y el redondeo no cuentan. Este servidor no transforma valores, por lo que derived siempre es false.
notices — reproduce los valores de OBS_STATUS (el canal de estado/descargo de responsabilidad de SDMX, p. ej. "Break in series"), textualmente y con recuentos. Los atributos técnicos por observación (DECIMALS, etc.) permanecen en las filas (rows[].attributes).

Licencia de datos y atribución

Datos y metadatos de ILOSTAT: CC BY 4.0 (desde 2023-05-03; licencia verificada 2026-08-04).
Atribución de la OIT en cada respuesta (campo citation): International Labour Organization, ILOSTAT, https://ilostat.ilo.org/data/, accessed <date>.
El logotipo de la OIT no se utiliza. Este servicio no está respaldado por la OIT.

Autoalojamiento / desarrollo

Todo lo siguiente solo es necesario para ejecutar tu propia instancia — no es necesario para usar el servidor público.

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 (ver wrangler.jsonc): KV SDMX_CACHE, D1 CATALOG_DB, Durable Object USAGE (contadores de uso respaldados por SQLite), CF_VERSION_METADATA. Autenticación Bearer opcional (wrangler secret put API_KEY); límite de tasa de token-bucket por IP.

Notas para operadores:

ILOSTAT devuelve JSON solo cuando se negocia mediante el encabezado Accept (application/vnd.sdmx.{structure,data}+json); ?format= se ignora y devuelve XML.
La pasarela de la OIT responde HTTP 500 (languageTag1) al encabezado Accept-Language: * que el fetch de Node (undici) envía por defecto; por lo tanto, cada llamada upstream establece explícitamente Accept-Language: en (el runtime de Cloudflare no envía tal encabezado, por lo que el Worker nunca se vio afectado). También espera un User-Agent identificable.
La actualización del catálogo es manual (sin cron): trimestral, o inmediatamente si un dataflow que existe upstream no aparece en la búsqueda. Procedimiento: los tres comandos de semilla anteriores. Las consultas de datos siempre están en vivo, por lo que solo el catálogo de búsqueda puede envejecer — y su antigüedad se expone en la procedencia.

Evaluaciones

@sbissoli/mcp-evals: 24 fixtures en evals/fixtures/queries.ts, validadas sin conexión en npm test. La ejecución con un modelo real (npm run eval) usa la API de Anthropic y necesita ANTHROPIC_API_KEY (sin ella, sale con instrucciones). Ejecución del 2026-08-07: top-1 100% (24/24) — evals/results/.

De extremo a extremo: 10 preguntas complejas con una única respuesta verificable en evals/e2e/evaluation.xml, respuestas validadas manualmente contra producción (evals/e2e/validacao-respostas.md). Ejecución del 2026-08-07 (Sonnet): 9/10 cadena exacta; 10/10 sustancial — evals/results/2026-08-07-e2e.md.

Endpoints

Ruta	Propósito
`/`	página de aterrizaje (identidad del servicio + contacto — público)
`/health`	comprobación de vida
`/status`	versión, recuentos y nombres de herramientas/recursos/prompts, versión del contrato de procedencia, despliegue actual (alimenta las insignias del README)
`/metrics`	uso agregado (solo endpoint MCP; sin IP, sin contenido de consulta)
`/mcp`	MCP Streamable HTTP

Seguridad

Snyk Agent Scan (2026-08-07): superado — informe en security/.

Licencia

Código: MIT. Datos: ILOSTAT, CC BY 4.0 (consulte "Licencia de datos y atribución" más arriba).

Privacidad

Política de privacidad del servicio alojado: PRIVACY.md.

Contacto

Sidney da S. P. Bissoli — sbissoli76@gmail.com. Este servicio no está respaldado por la OIT.

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.