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 Labour Statistics (ILOSTAT) — MCP-сервер

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

🇧🇷 Читать на португальском

Публичный, размещённый provenance-first MCP-сервер для статистики International Labour Organization (ILO) — базы данных ILOSTAT — без установки, без аккаунта, без API-ключа. Подключите своего MCP-клиента к размещённой конечной точке и запрашивайте данные о безработице, занятости, заработной плате, рабочем времени и других показателях труда по стране, году, полу и возрасту. Он работает на Cloudflare Workers через Streamable HTTP и обращается к официальному SDMX REST API ILOSTAT.

Каждый ответ содержит provenance-блок (URL источника, редакцию данных, фактическую временную метку получения, лицензию, ссылку на ILO) — точные цифры с полной историей происхождения, а не числа, угаданные из обучающих данных.

Использование (хостинг — без настройки)

Подключите любого MCP-клиента к конечной точке Streamable HTTP:

https://ilo.sidneybissoli.com/mcp

Claude Desktop / Claude Code и другие клиенты с встроенной поддержкой удалённых серверов:

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

Для клиентов, которые запускают MCP-серверы как команду, используйте мост mcp-remote:

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

Имя хоста ilo-mcp-server.sidneybissoli.workers.dev также поддерживается как дополнительное.

Related MCP server: world-bank-economic-mcp

Локальный запуск (stdio)

Не хотите направлять запросы через сторонний хост? Тот же сервер также работает как локальный процесс stdio, который общается напрямую с официальным API ILOSTAT — те же 4 инструмента, ресурсы и промпты, те же лимиты, тот же provenance-блок, без Cloudflare в цепочке.

Установка не требуется — пакет доступен на npm (ilo-mcp-server, Node ≥ 20):

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

Или из исходного кода:

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)

(затем укажите клиенту node /path/to/ilo-mcp-server/dist/cli.js).

Отличия от размещённого сервера полностью обусловлены отсутствием привязок Cloudflare: кэш SDMX живёт в памяти процесса (структуры и списки кодов переиспользуются в рамках сессии, но не между сессиями); поисковый каталог загружается с официального endpoint при первом поиске (его фактический retrieved_at указывается в provenance); нет метрик использования, ограничения частоты запросов и авторизации. Логи выводятся в stderr — stdout передаёт только поток JSON-RPC. Файл Dockerfile в репозитории собирает этот runtime (используется реестром Glama).

Инструменты

Инструмент	Назначение	Источник
`ilo_search_indicators`	поиск по ключевым словам среди ~1,210 dataflow (с пагинацией по `offset`)	локальный каталог (без обращения к API)
`ilo_get_indicator_metadata`	измерения, списки кодов, редакция (vintage) и выборка dataflow по умолчанию	кэшированная структура (промах → API)
`ilo_list_dimension_values`	допустимые коды одного измерения (с пагинацией по `offset`)	кэшированный список кодов (промах → API)
`ilo_get_data`	наблюдения, отфильтрованные по измерению и периоду	1 прямой REST-вызов на запрос

Типичный сценарий: ilo_search_indicators → ilo_get_indicator_metadata / ilo_list_dimension_values для поиска допустимых кодов фильтров → ilo_get_data с фильтрами по стране и периоду.

Каждый ответ содержит provenance-блок v1.0 (@sbissoli/mcp-provenance, режимы concise/detailed через параметр provenance_mode) в трёх каналах: structuredContent, _meta с пространством имён (com.sidneybissoli.ilostat/*) и текстовый нижний колонтитул.

Ресурсы и промпты

Три ресурса (статические, text/markdown, без обращения к API), которые клиент может подключить к контексту перед вызовом инструментов, — они экономят 2–3 поисковых вызова, которые большинство сессий тратят на выяснение «какой dataflow, какие коды»:

URI	Содержимое
`ilostat://guide`	порядок работы с инструментами, устоявшиеся правила кодирования (`REF_AREA` ISO3 + `X`-агрегаты, `SEX`, `AGE`, `FREQ`, суффиксы идентификаторов dataflow), лимиты, правила отчётности
`ilostat://reference/key-dataflows`	проверенные идентификаторы dataflow по темам (безработица, занятость, участие в рабочей силе, заработная плата, часы работы, неформальная занятость, NEET, ЦУР 8, производительность труда)
`ilostat://reference/provenance`	значение каждого поля provenance и как цитировать ILO

Три промпта — готовые сценарии, которые соединяют инструменты в цепочку и завершаются правилами цитирования (аргументы — строки; аргументы периода необязательны):

Промпт	Аргументы	Результат
`ilo_country_labour_profile`	`country`, `start_period`, `end_period`	профиль рынка труда одной страны (безработица, участие в рабочей силе, уровень занятости, неформальная занятость, NEET, заработки, часы работы)
`ilo_compare_countries`	`countries`, `indicator`, `start_period`, `end_period`	сравнительная таблица по странам/агрегатам в одном вызове данных с указанием модельных оценок и отчётных данных
`ilo_indicator_trend`	`indicator`, `country`, `start_period`, `end_period`	временной ряд одного показателя с первым/последним значениями, пиком/минимумом и разрывами `OBS_STATUS`

Каждый идентификатор dataflow, указанный в ресурсах и промптах, проверяется тестовым набором на соответствие seed-каталогу, поэтому документация не может ссылаться на идентификатор, который поиск не найдёт.

Поведение и ограничения

В ilo_get_data обязательно указывать REF_AREA; до 30 территорий за вызов. Шлюз ILO завершает запрос по таймауту (HTTP 504) при неограниченных запросах, поэтому сервер никогда их не отправляет; для широких панелей разбивайте территории на пакеты и/или используйте пагинацию по периоду (start_period/end_period). В сообщении об ошибке объясняется, как это сделать.
Один прямой REST-вызов на каждый запрос данных. Данные никогда не кэшируются — каждый результат ilo_get_data загружается из ILOSTAT в момент запроса. Кэшируются структуры dataflow (TTL 24 ч) и списки кодов (TTL 7 дней, общие для всех dataflow).
data_vintage — дата последнего обновления dataflow, опубликованная ILO (аннотация LAST_UPDATE, нормализованная к ISO).
retrieved_at — всегда фактический момент извлечения из ILOSTAT, сохраняется вместе с любым кэшированным значением — никогда не время сборки или ответа. Кэшированные ответы сообщают об этом (served_from_cache: true).
Каталог показателей — это локальный снимок (~1,210 dataflow), который периодически обновляется; его собственный retrieved_at указывается в provenance у ilo_search_indicators, поэтому его возраст всегда виден.
Каждый внешний вызов содержит идентифицируемый User-Agent (URL сервиса + контакт), чтобы администраторы ILO могли связаться с оператором.
Язык: английский; часовой пояс: UTC (данные ILO публикуются на английском).

Поля provenance

derived — true только при реальном преобразовании (агрегация, вычисление показателя на сервере, интерполяция, гармонизация), всегда с derivation_note; перевод единиц измерения и округление не учитываются. Этот сервер не преобразует значения, поэтому derived всегда false.
notices — дословно воспроизводит значения OBS_STATUS (канал статусов/дисклеймеров SDMX, например «Разрыв в ряду») с подсчётом. Технические атрибуты наблюдений (DECIMALS и т. д.) остаются в строках (rows[].attributes).

Лицензия на данные и атрибуция

Данные и метаданные ILOSTAT: CC BY 4.0 (с 2023-05-03; лицензия проверена 2026-08-04).
Атрибуция ILO в каждом ответе (поле citation): International Labour Organization, ILOSTAT, https://ilostat.ilo.org/data/, accessed <date>.
Логотип ILO не используется. Этот сервис не одобрен ILO.

Самостоятельный хостинг / разработка

Всё, что описано ниже, нужно только для запуска собственного экземпляра — для использования публичного сервера это не требуется.

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)

Привязки (см. wrangler.jsonc): KV SDMX_CACHE, D1 CATALOG_DB, Durable Object USAGE (счётчики использования на базе SQLite), CF_VERSION_METADATA. Необязательная Bearer-аутентификация (wrangler secret put API_KEY); ограничение частоты запросов для каждого IP по алгоритму token bucket.

Примечания для операторов:

ILOSTAT возвращает JSON только при согласовании через заголовок Accept (application/vnd.sdmx.{structure,data}+json); ?format= игнорируется, и возвращается XML.
Шлюз ILO отвечает HTTP 500 (languageTag1) на заголовок Accept-Language: *, который fetch в Node (undici) отправляет по умолчанию; поэтому каждый внешний вызов явно задаёт Accept-Language: en (среда выполнения Cloudflare не отправляет такой заголовок, поэтому Worker никогда не был затронут). Он также ожидает идентифицируемый User-Agent.
Обновление каталога выполняется вручную (без cron): раз в квартал либо немедленно, если dataflow, существующий в источнике, не появляется в поиске. Процедура: три указанные выше seed-команды. Запросы данных всегда выполняются в реальном времени, поэтому устаревать может только поисковый каталог — и его возраст указывается в provenance.

Оценки

@sbissoli/mcp-evals: 24 фикстуры в evals/fixtures/queries.ts, проверяются офлайн в npm test. Запуск с реальной моделью (npm run eval) использует Anthropic API и требует ANTHROPIC_API_KEY (без неё он завершается с инструкциями). Результат запуска от 2026-08-07: top-1 100% (24/24) — evals/results/.

Сквозное тестирование: 10 сложных вопросов с одним проверяемым ответом в evals/e2e/evaluation.xml, ответы проверены вручную на соответствие продакшну (evals/e2e/validacao-respostas.md). Прогон от 2026-08-07 (Sonnet): 9/10 точных совпадений строк; 10/10 по существу — evals/results/2026-08-07-e2e.md.

Конечные точки

Маршрут	Назначение
`/`	целевая страница (идентификация сервиса + контакты — публично)
`/health`	проверка работоспособности
`/status`	версия, количество и названия инструментов/ресурсов/подсказок, версия контракта происхождения, текущий деплой (питает бейджи README)
`/metrics`	агрегированная статистика использования (только конечная точка MCP; без IP-адресов, без содержимого запросов)
`/mcp`	MCP Streamable HTTP

Безопасность

Сканирование Snyk Agent (2026-08-07): пройдено — отчёт в security/.

Лицензия

Код: MIT. Данные: ILOSTAT, CC BY 4.0 (см. «Лицензия на данные и атрибуция» выше).

Конфиденциальность

Политика конфиденциальности размещённого сервиса: PRIVACY.md.

Контакты

Сидней да С. П. Биссоли — sbissoli76@gmail.com. Этот сервис не одобрен МОТ.

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.