UNESCO UIS Education Statistics MCP

Name: UNESCO UIS Education Statistics MCP
Author: SidneyBissoli

Server Details

UNESCO UIS statistics (education, science, culture) with full provenance and fixed releases.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over 75 days
Last Tested: 2026-10-31 15:48
Transport: Streamable HTTP · MCP 2025-11-25
URL
Repository: SidneyBissoli/uis-mcp-server
GitHub Stars: 1
Server Listing: UNESCO UIS Education Statistics MCP

TDQS

A4.2/5.0

Scored 2026-10-28 00:50 across 5 tools

Disambiguation4/5

The set contains two parallel stacks — `search`/`fetch` for document-style catalog retrieval and `uis_search_indicators`/`uis_get_data` for actual statistical queries — which could be confused at first glance, but the descriptions explicitly route agents ('prefer the `uis_*` tools for data; this is a catalog index, not a data query'). `fetch` vs `uis_get_data` are cleanly separated (document vs raw records), and `uis_list_geo_units` is unmistakably a code-lookup tool.

Naming Consistency3/5

Two conventions coexist: bare verbs (`search`, `fetch`) required by the OpenAI Deep Research contract, and prefixed verb_noun names (`uis_search_indicators`, `uis_get_data`, `uis_list_geo_units`). The split is intentional and the `uis_` prefix usefully marks the data-query stack, but it is still a mixed convention rather than a single predictable pattern.

Tool Count5/5

Five tools is well-scoped for the purpose: a search/fetch pair, an indicator lookup, a geographic-code lookup, and the data retrieval tool. Each tool earns its place with no redundancy or filler.

Completeness4/5

The workflow is closed: find indicators (`uis_search_indicators`), resolve geo codes (`uis_list_geo_units`), pull values (`uis_get_data`), plus the Deep Research `search`/`fetch` pair. Minor gaps exist — no way to enumerate themes or browse the indicator catalogue without keywords, and no dedicated vintage/metadata tool beyond what `uis_get_data` reports inline.

Available Tools

5 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 UNESCO UIS statistics (≈5,000 indicators: education — enrolment, completion, literacy, teachers, spending, SDG 4 —, science/R&D (SDG 9.5), culture (SDG 11.4) and demographic context) catalog. Only ids returned by search are valid; an unknown id returns an error. The uis_* tools remain the tools for data queries.

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

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

Output 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	Provenance block of the portfolio. concise (default): source, source_url, data_vintage, retrieved_at, retrieval, citation, license, plus optional keys only when there is something to say (field_sources, notices, derived/derivation_note, revision); detailed: the full canonical block (dataset, dimension_key, notices, served_from_cache, ...). retrieval is the origin diagnostic of this call — requests made to the UIS Data API, 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 the UIS (catalogue or cached answer)
`attribution`	Yes	Source URLs the figures came from (the provenance source_url of each block), for linking the citation

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already cover readOnlyHint, idempotentHint and openWorldHint, so the safety profile is free. The description still adds value beyond them: an unknown id yields an error, and the text is 'a live GET against the public source when the document needs it', hinting at possible latency/fetch behavior. Does not specify caching or rate limits, so not a 5.

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 action and return shape, then constraints, then behavior. The catalog sentence enumerating UNESCO indicator domains (education, science/R&D, culture, demographics) is somewhat longer than needed for a fetch tool, but it does scope what documents exist.

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 needn't be explained, yet the description still summarizes the fields and which ones matter for citing (`url`). Precondition, error case, and relationship to siblings are all covered.

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% for the single `id` parameter, so the baseline is 3. The description earns above that by adding a semantic constraint the schema lacks: only ids produced by `search` are valid.

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') and immediately gives the return shape { id, title, text, url, metadata }. It also distinguishes itself from the uis_* siblings, which it names explicitly as 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?

Gives an explicit precondition ('Only ids returned by `search` are valid') and an explicit exclusion ('The `uis_*` tools remain the tools for data queries'). The agent knows both when to call this and when to call a sibling instead.

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 UNESCO UIS statistics (≈5,000 indicators: education — enrolment, completion, literacy, teachers, spending, SDG 4 —, science/R&D (SDG 9.5), culture (SDG 11.4) and demographic context) 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 uis_* 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.

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

Output Schema

Name	Required	Description
`results`	Yes	Matching documents, in relevance order
`provenance`	Yes	Provenance block of the portfolio. concise (default): source, source_url, data_vintage, retrieved_at, retrieval, citation, license, plus optional keys only when there is something to say (field_sources, notices, derived/derivation_note, revision); detailed: the full canonical block (dataset, dimension_key, notices, served_from_cache, ...). retrieval is the origin diagnostic of this call — requests made to the UIS Data API, 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 the UIS (catalogue or cached answer)
`attribution`	Yes	Source URLs the figures came from (the provenance source_url of each block), for linking the citation

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover read-only, idempotent and open-world, so safety is known. The description still adds non-obvious behavior: result cap of 10, relevance ordering, the empty-list-means-no-match signal, and that the catalog is publicly sourced and memory-cached.

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 usage routing, then query and behavior notes. Three short blocks, no filler, though the Deep Research contract paragraph is somewhat verbose for an agent that already knows to call search.

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?

Annotations carry the safety profile, an output schema exists, and the single parameter is fully documented in the schema, so the description needn't restate returns. What remains — scope limits, sibling routing, empty-result semantics — is all present.

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 100% schema coverage the baseline is 3, and the description matches the schema note that accents and case are ignored. It adds meaningful semantic range by allowing either natural language or keywords in Portuguese or English, which helps an agent phrase queries.

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 UNESCO UIS statistics catalog (~5,000 indicators with named domains) and returns up to 10 matching documents. It also explicitly distinguishes itself from the sibling `uis_*` data tools by calling itself 'a catalog index, not 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 routing rules: use `search`+`fetch` for the Deep Research contract, use `fetch` to read a returned id, and prefer `uis_*` tools for direct questions and actual data values, series and rankings. When-to-use and when-to-use-something-else are both stated.

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

uis_get_dataGet UNESCO UIS dataA

Read-onlyIdempotent

Inspect

Statistical records from the UNESCO Institute for Statistics Data API, filtered by indicator codes (from uis_search_indicators, up to 25), geo unit codes (from uis_list_geo_units) and year range. Set include_footnotes for per-record source notes. Returns raw UIS records only — it does not aggregate, convert or otherwise transform values; ILO labour statistics live in the sibling ILOSTAT MCP server. Broad queries are rejected with the record count — narrow by geo unit or years. A code that does not exist is an error carrying the UIS API's own wording, never an empty result: zero rows means the codes are real and the selection has no data, and the hint then relays what the UIS reported (including the indicator's available year range). When only SOME of the requested codes exist, the matching rows are returned with warnings naming the rest. Values are those of the release named in data_vintage: a new UIS release can revise past years. On a record, magnitude says what the value shown means (e.g. NA = not applicable, shown as 0; SUPP = withheld, blank) and qualifier says how it was obtained (national or UIS estimate); the provenance notices count them in plain words; both are null when the UIS publishes no flag. The UIS publishes no unit field: the unit usually closes the indicator name in parentheses ("(%)", "(number)", "(years)"), but not always — a parenthesis can also name a parity index (GPIA), an estimate type or an education level, and some names have none.

Name	Required	Description
`end_year`	No	Last year, e.g. 2024
`geo_units`	No	Geo unit codes from uis_list_geo_units (e.g. ["BRA","ARG"]); omit for all
`indicators`	Yes	Indicator codes from uis_search_indicators (e.g. ["CR.1"])
`start_year`	No	First year, 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)
`include_footnotes`	No	Include per-record footnotes (source notes); default false

Output Schema

Name	Required	Description
`rows`	Yes	Raw UIS records, one per indicator, geo unit and year; value is untransformed
`columns`	Yes	Core fields of each row, in reading order
`provenance`	Yes	Provenance block of the portfolio. concise (default): source, source_url, data_vintage, retrieved_at, retrieval, citation, license, plus optional keys only when there is something to say (field_sources, notices, derived/derivation_note, revision); detailed: the full canonical block (dataset, dimension_key, notices, served_from_cache, ...). retrieval is the origin diagnostic of this call — requests made to the UIS Data API, 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 the UIS (catalogue or cached answer)
`rows_count`	Yes	Number of records returned
`attribution`	Yes	Source URLs the figures came from (the provenance source_url of each block), for linking the citation

TDQS

A4.2/5.0

Behavior5/5

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

Annotations already declare read-only, idempotent, open-world, non-destructive; the description goes well beyond by disclosing rejection behavior for broad queries, error-vs-empty-result semantics ('a code that does not exist is an error... zero rows means the codes are real'), partial-match warnings, release revision risk via data_vintage, and how magnitude/qualifier flags render. This is exactly the extra context annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The source and filtering scope are correctly front-loaded, but the text is a single very dense paragraph of roughly 300 words mixing invocation rules, error semantics and output-flag interpretation. Much of the magnitude/qualifier and unit-parenthesis material belongs to return-value documentation (and an output schema exists), so it dilutes the call-critical content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 6-parameter filtered-read tool with full annotation coverage and an output schema, the definition covers invocation constraints, failure modes and provenance well. It is arguably over-complete on rendered-value semantics that the output schema may already describe, but nothing an agent needs in order to call it 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%, so all six parameters are already documented in the schema. The description reinforces the code-source provenance for indicators and geo_units and explains include_footnotes' purpose, but adds no syntax or format detail beyond what the schema states; baseline 3 applies.

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?

Opens with a specific verb+resource ('Statistical records from the UNESCO Institute for Statistics Data API') and enumerates the filtering dimensions (indicator codes, geo unit codes, year range). It also draws a clear boundary against the ILOSTAT MCP server for labour statistics, so an agent can distinguish it from both code-lookup siblings and the non-UIS alternative.

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

Usage Guidelines4/5

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

Gives concrete operating guidance: codes must come from uis_search_indicators / uis_list_geo_units, broad queries are rejected so narrow by geo unit or years, and it states it does not aggregate or transform values, with ILO labour data explicitly out of scope. Lacks an explicit 'use fetch/search instead when...' routing statement, so not a full 5.

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

uis_list_geo_unitsList UNESCO UIS geo unitsA

Read-onlyIdempotent

Inspect

Valid geographic codes for uis_get_data: 462 geo units — countries (NATIONAL, ISO alpha-3 codes like BRA) and regional aggregates (REGIONAL). Filter by name/code and type. Does not return statistical values; these codes apply only to uis_get_data, not to other statistical servers.

Name	Required	Description
`type`	No	Only countries (NATIONAL) or only regional aggregates
`limit`	No	Maximum results (default 100)
`offset`	No	Results to skip, for pagination (default 0)
`search`	No	Case-insensitive filter on name, or exact code (e.g. "BRA")
`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

Name	Required	Description
`offset`	Yes	Results skipped before this page
`showing`	Yes	Geo units returned in this page
`has_more`	Yes	True when more matches remain after this page
`geo_units`	Yes	Geo units: id is the code for uis_get_data, type is NATIONAL or REGIONAL
`provenance`	Yes	Provenance block of the portfolio. concise (default): source, source_url, data_vintage, retrieved_at, retrieval, citation, license, plus optional keys only when there is something to say (field_sources, notices, derived/derivation_note, revision); detailed: the full canonical block (dataset, dimension_key, notices, served_from_cache, ...). retrieval is the origin diagnostic of this call — requests made to the UIS Data API, 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 the UIS (catalogue or cached answer)
`attribution`	Yes	Source URLs the figures came from (the provenance source_url of each block), for linking the citation
`next_offset`	No	Offset for the next page; present only when has_more is true
`total_matches`	Yes	Geo units matching the filters, across every page

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the description only needs to add domain behaviour — and it does, clarifying that the output is a code vocabulary rather than data, plus the total count of 462 units. It does not discuss pagination behaviour despite offset/limit existing, which keeps it just short of a 5.

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?

Three sentences, zero filler, with the identity/purpose front-loaded and the scoping caveat placed last where it is easy to retain. Slightly dense with em-dash packing, but every clause carries information the agent needs to route correctly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless-required, read-only enumeration tool with an output schema and full schema coverage, the description supplies the essential framing: what the records are, how to filter them, and that they are a dependency of uis_get_data. Return shape and pagination defaults are legitimately left to the structured fields.

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%, so the baseline is 3. The description reinforces the two domain-relevant filters ('filter by name/code and type') and explains why alpha-3 codes matter, but adds nothing about limit/offset or provenance_mode beyond what the schema already spells out.

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 (list the 462 valid geographic codes), enumerates the two code families with concrete examples (NATIONAL + ISO alpha-3 like BRA; REGIONAL aggregates), and explicitly names the consuming sibling uis_get_data. An agent can distinguish it from fetch/search/uis_search_indicators 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?

Frames the tool as a prerequisite step for uis_get_data and states the exclusion directly: it 'does not return statistical values' and these codes apply 'only to uis_get_data, not to other statistical servers.' That is explicit when-to-use and when-not-to-use guidance with the alternative named.

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

uis_search_indicatorsSearch UNESCO UIS indicatorsA

Read-onlyIdempotent

Inspect

Search the UNESCO Institute for Statistics catalogue of ~5,000 indicators — education, science/R&D, culture and communication — by keywords in the name or code, optionally filtered by theme. All terms must match (AND, case-insensitive), so start with 2–3 words and drop terms if you get 0 results. Everyday and US wording is resolved to the UIS's own (enrollment→enrolment, spending→expenditure, preschool→pre-primary, university→tertiary, graduation→completion, girls/boys→female/male); when that happens the response says so in vocabulary_notes. Returns indicator codes to use with uis_get_data, plus each indicator's data availability (years, record count). Searches the catalogue only — it does not return statistical values (use uis_get_data); ILO labour statistics live in the sibling ILOSTAT MCP server.

Name	Required	Description
`limit`	No	Maximum results (default 20)
`query`	Yes	Keywords, matched against indicator name and code, AND between terms (e.g. "literacy rate youth")
`theme`	No	Restrict to one UIS theme
`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

Name	Required	Description
`hint`	No	What to do next: how to narrow or page, or why nothing matched
`offset`	Yes	Results skipped before this page
`showing`	Yes	Indicators returned in this page
`has_more`	Yes	True when more matches remain after this page
`indicators`	Yes	Matching indicators, largest record count first; use code with uis_get_data
`provenance`	Yes	Provenance block of the portfolio. concise (default): source, source_url, data_vintage, retrieved_at, retrieval, citation, license, plus optional keys only when there is something to say (field_sources, notices, derived/derivation_note, revision); detailed: the full canonical block (dataset, dimension_key, notices, served_from_cache, ...). retrieval is the origin diagnostic of this call — requests made to the UIS Data API, 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 the UIS (catalogue or cached answer)
`attribution`	Yes	Source URLs the figures came from (the provenance source_url of each block), for linking the citation
`next_offset`	No	Offset for the next page; present only when has_more is true
`total_matches`	Yes	Indicators matching all terms, across every page
`vocabulary_notes`	No	Translations applied from everyday or US wording to UIS terms (e.g. enrollment → enrolment)

TDQS

A4.3/5.0

Behavior3/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, but the description adds genuinely non-obvious behavior: everyday and US wording is silently resolved to UIS terms (enrollment→enrolment, spending→expenditure) with the substitution disclosed in vocabulary_notes. That is valuable transparency an agent could not infer from any structured field.

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?

Dense but every sentence carries information: scope first, query mechanics, synonym resolution, return contents, then boundaries. No redundancy despite the length.

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 and the description still pre-announces what matters for chaining — indicator codes for uis_get_data, data availability (years, record count), and vocabulary_notes. Nothing an agent needs to call or follow up on 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 coverage is 100% and enum values for theme and provenance_mode are fully documented in the schema, so the description adds little: it restates the AND/case-insensitive matching already in the query parameter's description. limit, offset and provenance_mode semantics are left entirely to the schema — appropriate, but no added value.

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?

Specific verb+resource with scope (~5,000 indicators across education, science/R&D, culture and communication) and clear differentiation from siblings: it searches the catalogue but returns no statistical values, and ILO labour data belongs to the ILOSTAT server. An agent can immediately tell this apart from uis_get_data.

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 routing: 'use uis_get_data' for values, ILOSTAT for labour statistics. Adds concrete query strategy — start with 2–3 words, drop terms on zero results — and states all terms are AND-matched and case-insensitive.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesOct 28, 2026

Changedfetch1 field changed

addedOutput schema / properties / attribution / description

Added value: +"Source URLs the figures came from (the provenance source_url of each block), for linking the citation"

Changedsearch1 field changed

addedOutput schema / properties / attribution / description

Added value: +"Source URLs the figures came from (the provenance source_url of each block), for linking the citation"

Changeduis_get_data4 fields changed

addedOutput schema / properties / attribution / description

Added value: +"Source URLs the figures came from (the provenance source_url of each block), for linking the citation"

addedOutput schema / properties / columns / description

Added value: +"Core fields of each row, in reading order"

addedOutput schema / properties / rows / description

Added value: +"Raw UIS records, one per indicator, geo unit and year; value is untransformed"

addedOutput schema / properties / rows_count / description
```
Added value: +"Number of records returned"
```

Changeduis_list_geo_units7 fields changed

addedOutput schema / properties / attribution / description

Added value: +"Source URLs the figures came from (the provenance source_url of each block), for linking the citation"

addedOutput schema / properties / geo_units / description

Added value: +"Geo units: id is the code for uis_get_data, type is NATIONAL or REGIONAL"

addedOutput schema / properties / has_more / description

Added value: +"True when more matches remain after this page"

addedOutput schema / properties / next_offset / description

Added value: +"Offset for the next page; present only when has_more is true"

addedOutput schema / properties / offset / description
```
Added value: +"Results skipped before this page"
```
addedOutput schema / properties / showing / description
```
Added value: +"Geo units returned in this page"
```

addedOutput schema / properties / total_matches / description

Added value: +"Geo units matching the filters, across every page"

Changeduis_search_indicators9 fields changed

addedOutput schema / properties / attribution / description

Added value: +"Source URLs the figures came from (the provenance source_url of each block), for linking the citation"

addedOutput schema / properties / has_more / description

Added value: +"True when more matches remain after this page"

addedOutput schema / properties / hint / description

Added value: +"What to do next: how to narrow or page, or why nothing matched"

addedOutput schema / properties / indicators / description

Added value: +"Matching indicators, largest record count first; use code with uis_get_data"

addedOutput schema / properties / next_offset / description

Added value: +"Offset for the next page; present only when has_more is true"

addedOutput schema / properties / offset / description
```
Added value: +"Results skipped before this page"
```
addedOutput schema / properties / showing / description
```
Added value: +"Indicators returned in this page"
```

addedOutput schema / properties / total_matches / description

Added value: +"Indicators matching all terms, across every page"

addedOutput schema / properties / vocabulary_notes / description

Added value: +"Translations applied from everyday or US wording to UIS terms (e.g. enrollment → enrolment)"

1 tool updateOct 16, 2026

Changeduis_get_data3 fields changed

addedOutput schema / properties / rows / items / properties

Added value: +{
+  "geo_unit": {
+    "type": "string"
+  },
+  "indicator": {
+    "type": "string"
+  },
+  "magnitude": {
+    "type": [
+      "string",
+      "null"
+    ]
+  },
+  "qualifier": {
+    "type": [
+      "string",
+      "null"
+    ]
+  },
+  "value": {
+    "type": [
+      "number",
+      "null"
+    ]
+  },
+  "year": {
+    "type": "number"
+  }
+}

removedOutput schema / properties / rows / items / propertyNames
```
Removed value: -{
-  "type": "string"
-}
```

addedOutput schema / properties / rows / items / required

Added value: +[
+  "indicator",
+  "geo_unit",
+  "year",
+  "value",
+  "magnitude",
+  "qualifier"
+]

5 tool updatesOct 8, 2026

Changedfetch2 fields changed