ILO Statistics (ILOSTAT) MCP Server

Search ILOSTAT indicators

ilo_search_indicators

Read-onlyIdempotent

Find ILOSTAT dataflow IDs by searching 1,200 labour indicators with 2-3 keywords. Resolves everyday wording to ILO terms and ranks by relevance for use with data retrieval tools.

Instructions

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.

Input Schema

TableJSON 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

TableJSON Schema

Name	Required	Description	Default
`hint`	No
`offset`	Yes
`showing`	Yes
`has_more`	Yes
`indicators`	Yes
`provenance`	Yes
`attribution`	Yes
`next_offset`	No
`total_matches`	Yes
`vocabulary_notes`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.6.0Sep 15, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
- addedOutput schema / properties / hint
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / vocabulary_notes
```
Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
```
First observedv0.1.0Aug 19, 2026

TDQS

A4.9/5.0

Behavior5/5

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

While annotations already establish readOnly/idempotent/non-destructive behavior, the description goes well beyond them by disclosing AND semantics, case-insensitivity, synonym resolution, relevance ranking, id-shape conventions (_RT, _NB, 2-token modelled estimates), and vocabulary_notes behavior. No contradiction with annotations exists.

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?

The description is long but every sentence earns its place: purpose, query strategy, vocabulary behavior, ranking, id interpretation, and exclusions are all covered without redundancy. The core purpose is front-loaded before the detailed guidance.

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?

Given output schema exists and the tool is a read-only search, the description covers everything an agent needs: what it searches, how to construct queries, how results are ordered, how to interpret ids, and which sibling tools to use for adjacent tasks. Nothing important is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: it explains query semantics with examples, vocabulary mapping, ranking behavior, and how to interpret result ids. It doesn't add much about limit/offset/provenance_mode, but those are already fully described in 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?

The description opens with a specific verb and resource: 'Search the ILOSTAT catalogue of ~1,200 indicator dataflows by keywords in the name or id.' It also differentiates itself from siblings by explicitly stating what it does not do: no statistical values, no dimension-code search, no non-ILO sources.

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?

Usage guidance is explicit and actionable: start with 2–3 English words, drop terms on zero results, and use alternatives for other needs (ilo_get_data for values, ilo_list_dimension_values for countries). It also names sibling tools directly, so an agent knows exactly when to choose this tool.

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

Deploy Server