What can you do with this server?

Summary: Query official UNESCO Institute for Statistics (UIS) data — education, science/R&D, culture and demographics — from any MCP client, with a provenance/attribution block on every answer. * Find indicators (uis_search_indicators): keyword search over ~5,060 UIS indicators with theme filter, data availability (years, record count) and pagination; everyday/US words are translated to UNESCO wording (enrollment→enrolment, spending→expenditure) and reported in vocabulary_notes. * Find geo units (uis_list_geo_units): 462 country (ISO alpha-3) and regional aggregate codes, filterable by name/code/type, for use with data queries. * Retrieve statistics (uis_get_data): raw UIS records by up to 25 indicator codes, geo units and year range, optional per-record footnotes; release-pinned, capped at 5,000 records and never silently truncated; unknown codes return an explanatory error, partial matches return warnings. * Deep Research support (search + fetch): OpenAI/ChatGPT-compatible catalog search returning {id, title, url} and full indicator documents as readable Markdown with the citable UIS Data Browser page. * Context resources: uis://guide (workflow, code conventions, limits), uis://reference/key-indicators (verified codes by topic) and uis://reference/provenance (field meanings, citation, CC BY-SA obligations). * Provenance on every response (concise or detailed modes): source URL, UIS data release/vintage, real retrieval timestamp, citation, license and a retrieval diagnostic (requests, retries, anomalies, unstable). * Runs without setup: hosted Streamable HTTP endpoint (no install, account or API key), plus an identical local stdio runtime via npx uis-mcp-server. * Scope limits: answers only — no microdata, no aggregation/transformation (derived always false); labour statistics belong to the sibling ILOSTAT server, and bulk datasets to the UIS Bulk Download Service.

How do I use UNESCO Institute for Statistics (UIS) MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@UNESCO Institute for Statistics (UIS) MCP Server Get the gross enrollment ratio for primary education in France for 2019." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

UNESCO Institute for Statistics (UIS) MCP Server

by SidneyBissoli

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

UNESCO UIS Education Statistics MCP Server

MCP Version Tools npm MCP Registry uis-mcp-server MCP server License: MIT Status

🇧🇷 Leia em Português

A public, hosted, provenance-first MCP server for the statistics of the UNESCO Institute for Statistics (UIS) — education, science and R&D, culture and communication — no installation, no account, no API key. Point your MCP client at the hosted endpoint and ask about enrolment, completion, out-of-school children, literacy, education spending, researchers and R&D expenditure by country, region and year. It runs on Cloudflare Workers over Streamable HTTP and talks to the official UIS Data API.

Independent project. This is an unofficial, community-built client of the UIS's public Data API — not affiliated with or endorsed by UNESCO or the UNESCO Institute for Statistics. Data remain © UNESCO-UIS under CC BY-SA 4.0; see Data license and attribution.

Every response carries a provenance block (source URL, the UIS data release it came from, real retrieval timestamp, license, UIS citation) — exact figures with an audit trail, not numbers guessed from training data.

🇧🇷 Em português. Servidor MCP remoto e hospedado (nada para instalar, sem conta e sem chave) para as estatísticas do Instituto de Estatística da UNESCO — matrícula, conclusão, crianças fora da escola, alfabetização, gasto em educação e P&D por país, região e ano, direto no Claude, no ChatGPT ou em qualquer cliente MCP, com proveniência e citação da fonte em cada resposta: README em português.

Questions it answers

In plain language, inside the MCP client — the assistant picks the tool and the filters:

"Which UNESCO indicators track out-of-school children?" (uis_search_indicators)
"How did primary completion evolve in Brazil, Peru and Colombia after 2015?" (uis_get_data)
"Is there a UNESCO series on government expenditure on education as a share of GDP?" (uis_search_indicators → uis_get_data)
"How many researchers per million inhabitants do the BRICS countries have since 2010?" (uis_search_indicators → uis_get_data)
"What is the adult literacy rate in Argentina and Chile, by sex?" (uis_get_data)
"Which geo unit code does the UIS use for Côte d'Ivoire, and which regional aggregates exist?" (uis_list_geo_units)

Three of them — enrolment, literacy and education spending — run against the live server, with the tool calls and what came back: uis.sidneybissoli.com/examples.

Ask in your words, not UNESCO's. The UIS is worded in British statistical English, and the catalogue is matched on the indicator name — so the everyday or US word used to return nothing at all. Measured over the 5,063 indicators of the official catalogue (2026-09-16), and fixed since 0.3.0: the search expands the term to the source's wording (OR within a term, AND across terms — it only adds recall) and says it translated, in vocabulary_notes; a zero result comes with a hint on what to try next. The same table feeds the search index (Deep Research).

you ask	hits before	UNESCO writes	hits
`enrollment`	0	enrolment	387
`education spending`, `budget`	0	expenditure	57
`teacher wages`	0	salary	4
`university`, `college`	0	tertiary	448
`preschool`, `kindergarten`	0	pre-primary, early childhood	113
`elementary`	0	primary	886
`scientists`	0	researchers	11
`girls`, `women`	0	female	1,252
`kids`, `teenagers`	0	children, adolescents	161, 131
`graduation rate`	0	completion	342
`pupil-teacher ratio`	0	pupil-qualified teacher ratio	10
`foreign students`	249	internationally mobile students	979
`primary school completion`	0	primary education	114
`illiteracy`, `maths`, `tvet`, `phd`, `stem`	0	illiterate, mathematics, vocational, doctoral, science, technology, engineering	268, 79, 33, 24, 9

Only measured pairs go in (the asked word absent from the catalogue, the source's word present) — the table lives in src/uis/vocabulary.ts, with the counts. A term the UIS does not publish is left out and still returns zero, because an alias for data that does not exist promises what the source does not have: dropout, tuition, unemployment and labor (labour statistics belong to the sister server ilo-mcp-server; what labor matches today are 62 names containing "collaboration").

Related MCP server: BNCC MCP

Comparison with the alternatives

Anyone who already works with UIS data has good tools, and this server replaces none of them — it sits somewhere else in the chain: it answers the question at the point where the question is asked, inside the assistant, with source, data release and licence attached to the answer. Versions measured on 2026-10-02.

Tool	What it is	When to prefer it
uis-mcp-server (this)	Remote MCP server, hosted, nothing to install: 5 tools over the ~5,060 UIS indicators, with a provenance block per answer	The question is asked in an assistant (Claude, ChatGPT, Cursor, Claude Code) and the answer has to be auditable
uisapi 0.1.1 (R, CRAN)	Community R client of the UIS Data API (not by UIS staff); also lists the bulk files	You are in R and want UIS series in a data frame for analysis
unesco-reader 3.1.1 (Python, PyPI)	Community Python client of the UIS Data API	Your pipeline is Python
global-education-mcp 0.4.0 (MCP, Python)	Another MCP server: UIS Data API plus the OECD Education at a Glance API	You want UIS and OECD education data side by side in one local server
unesco-mcp (MCP, Python, PyPI)	Another MCP server over the UIS API, run locally with `uvx`; catalogue cached in SQLite, ranking and comparison tools (measured 2026-10-13)	You prefer a local server with analysis tools built in
UNESCO UIS Statistics Scraper (Apify actor)	Community actor over the same Data API, exposed as a tool by Apify's general MCP server; needs an Apify account, pay per result (US$ 0.002–0.004 per row by plan, 2026-10-13); output has source URL but no data release	You already run Apify pipelines and want UIS rows in an Apify dataset
WDI / wbstats (R), wbgapi (Python)	World Bank clients; WDI republishes many UIS education series, with a lag	You want UIS education series next to World Bank indicators
UIS Bulk Data Download Service	The UIS's own CSV files per data release (SDG and OPRI)	You need whole datasets, not answers
UIS Data API	The source itself, which this server calls — no key	You are building your own client and want full control

About SDMX: the UIS no longer serves it. Its legacy SDMX API reached end-of-life on 2020-06-23 (stated in the UIS's own February 2026 data release note) and the endpoint now answers 404 — generic SDMX clients that still list a UNESCO source (e.g. sdmx1) point at that dead URL, and the DBnomics copy of UNESCO data is a frozen 2020-era snapshot. For SDMX over labour statistics, see the sister server ilo-mcp-server, which talks to the ILOSTAT SDMX API.

Do not use this server when you need a whole dataset rather than an answer (the bulk files are the right tool), when the question is not education, science, culture or communication statistics published by the UIS (labour → ILO, national accounts → IMF/World Bank), or when you need microdata: the UIS publishes aggregates, and so does this server.

Sister servers, same design and same provenance block, for other official sources: ILOSTAT (ILO labour statistics), IBGE (Brazilian statistics), BCB (Central Bank of Brazil), Senado (Brazilian Senate open data), SIH/SUS (Brazilian hospital admissions) and medical terminologies (ICD-11, ICD-10, LOINC, RxNorm, ATC, MeSH).

Use it (hosted — no setup)

Point any MCP client at the Streamable HTTP endpoint:

https://uis.sidneybissoli.com/mcp

Claude Desktop / Claude Code and other clients with native remote support:

{
  "mcpServers": {
    "unesco-uis": {
      "url": "https://uis.sidneybissoli.com/mcp"
    }
  }
}

For clients that launch MCP servers as a command, use the mcp-remote bridge:

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

The uis-mcp-server.sidneybissoli.workers.dev hostname is also served, as a secondary.

ChatGPT (Deep Research)

ChatGPT deep research (and company knowledge, and research workflows over the Responses API) only uses an MCP server that exposes exactly search and fetch — this server does, on top of the uis_* tools. Point the connector at the hosted endpoint, no key required:

https://uis.sidneybissoli.com/mcp

search ranks the query against the full UIS catalogue (~5,060 indicators — education, science/R&D, culture, demographic context) and returns { id, title, url } (ind:<code>, e.g. ind:ROFST.1.CP); fetch returns the indicator as readable Markdown — name, theme, Data Browser group and framework, available years, a data sample (Brazil and the SDG world aggregate, last five years; one Data API call with a pinned release) and how to query it with uis_get_data — with the public UIS Data Browser page as url (https://databrowser.uis.unesco.org/view#indicatorPaths=<framework>%3A0%3A<code>), which is what ChatGPT cites. In search/fetch the text channel is the Deep Research contract's JSON (no footer); provenance travels in structuredContent and _meta. In ChatGPT's developer mode (Settings → Security and login → Developer mode) any tool is callable — the uis_* tools remain the ones to use for data.

Run locally (stdio)

Prefer not to route queries through a third-party host? The same server also runs as a local stdio process that talks directly to the official UIS Data API — same 5 tools and 3 resources, same limits, same provenance block, no Cloudflare in the loop. The surface of the two runtimes is identical by construction (CI checks it: node scripts/dump-surface.mjs --stdio).

No install needed — the package is on npm (uis-mcp-server, Node ≥ 22):

{
  "mcpServers": {
    "unesco-uis": {
      "command": "npx",
      "args": ["-y", "uis-mcp-server"]
    }
  }
}

Or from source:

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

Differences from the hosted server, all due to the absence of Cloudflare bindings:

the current data release (/versions/default) is kept in process memory: resolved once per session, not across sessions;
the indicator catalogue and the geo units are downloaded from the official endpoints on the first search (/definitions/indicators, /definitions/geounits — the same ones the hosted catalogue is seeded from; ~1 s), and the real retrieved_at of that download is what provenance reports;
the in-memory catalogue does not download the UIS Data Browser definitions (~6.7 MB), so the URL that fetch cites falls back to the Data Browser home page and the search index lacks the group name in its keywords — Deep Research talks to the hosted server, which has them;
no usage metrics, rate limit or auth.

Logs go to stderr — stdout carries only the JSON-RPC stream. The repository Dockerfile builds this runtime (used by the Glama registry).

Tools

Tool	What it does	Source
`uis_search_indicators`	keyword search over ~5,060 indicators (4 themes) with data availability; translates the user's word to UNESCO's and says so (`vocabulary_notes`); paginated by `offset`	local catalogue (no upstream call)
`uis_list_geo_units`	462 country and regional codes (NATIONAL/REGIONAL); paginated by `offset`	local catalogue (no upstream call)
`uis_get_data`	records by indicator, geo unit and years, optional footnotes	1 live Data API call per query (pinned release)
`search`	ChatGPT Deep Research contract: ranks a query against the full catalogue, returns `{ id, title, url }` (`ind:<code>`)	in-memory index built from the local catalogue (24 h)
`fetch`	ChatGPT Deep Research contract: one indicator as readable Markdown (catalogue entry + data sample) with the public Data Browser page as `url`	local catalogue + 1 Data API call (sample)

Typical flow: uis_search_indicators to find an indicator code → uis_list_geo_units for country/region codes → uis_get_data with year filters.

Every response carries the portfolio's provenance block (@sbissoli/mcp-provenance, modes concise/detailed via the provenance_mode parameter) on three channels: structuredContent, namespaced _meta (com.sidneybissoli.uis/*) and a text footer. Since 1.1.0 the block includes retrieval, the origin diagnostic of the call — how many requests went to the Data API, how many attempts they took, which anomalies were overcome and whether the answer is unstable — measured by the portfolio's common fetch (@sbissoli/mcp-upstream); null when the answer did not touch the UIS (catalogue or cached release).

Resources

Three resources (static, text/markdown, no upstream call) that a client can attach to the context before calling tools — they save the discovery calls most sessions spend on "which indicator, which code":

URI	Content
`uis://guide`	tool workflow, code conventions (indicator code families and suffixes, ISO alpha-3 geo units, themes), limits, reporting rules
`uis://reference/key-indicators`	verified indicator codes by topic (completion, out-of-school, enrolment, literacy, learning proficiency, education spending, R&D for SDG 9.5, heritage spending for SDG 11.4, population)
`uis://reference/provenance`	meaning of every provenance field and how to cite the UIS, including what CC BY-SA ShareAlike requires downstream

Behaviour and limits

Every data query pins the release. uis_get_data sends an explicit version=, resolved from /versions/default and cached for 24 h — reproducible, and it reuses the upstream's own cache. The release is the data_vintage (e.g. 20260507-91260335 (published 2026-05-08)); when the UIS publishes a new release, data queries move to it within 24 h.
5,000 records per response, at most 25 indicators per call. Above that the server returns an explanatory error with the real count — it never truncates silently, since partial data presented as complete would break the provenance contract. The UIS's own ceiling of 100,000 records comes back as the upstream's explanatory HTTP 400, passed through.
The indicator catalogue is a snapshot of a UIS release, refreshed by hand when the UIS publishes a new one (2–3 times a year); its real retrieved_at is reported in the provenance of uis_search_indicators, so its age is always visible (served_from_cache: true).
retrieved_at is always the real instant of extraction from the UIS, never the build or response time. When an answer joins parts extracted at different moments (uis_get_data: the current release, cached up to 24 h, plus the data fetched now; fetch: also the catalogue row), it is the OLDEST of them, and field_sources gives each part its own instant and cache flag (since 1.5.1).
Notices report footnote types, magnitude and qualifier, with counts; the full text of each footnote stays on the row (include_footnotes: true).
Every upstream call has a timeout and a retry policy (since 1.1.0, measured against the live API on 2026-09-27: release 1.1 s, small query 0.8 s, five whole indicators 2.9 s/3.5 MB, the 100k-cap 400 in 0.9 s): 35 s per attempt — ten times the worst legitimate case and above the 29 s of the AWS API Gateway in front of the UIS —, up to 3 attempts on 5xx, 429 (honouring Retry-After) and network errors, 45 s in total per call. Timeouts, HTTP 504, the explanatory 400 and 404 are never retried. What happened is reported in the provenance retrieval field; a timeout or network failure becomes a readable error, not a raw exception.
derived is always false — the server does not transform values.
Language: English; timezone: UTC (UIS data is published in English).

Surface fingerprint, checkable from the registry

Every release publishes, in its MCP Registry entry, the sha256 of the surface this version serves (initialize, tools, resources, prompts) and which methods answer without a credential. A surface change without a version bump fails the build; the fingerprint in the registry lets a client check the same thing on its own side. Canonical form and procedure: SPEC.md of @sbissoli/mcp-surface. To check it yourself (Node 18+, no dependencies):

curl -sO https://raw.githubusercontent.com/SidneyBissoli/mcp-br-commons/main/packages/mcp-surface/exemplos/verify.mjs
node verify.mjs io.github.SidneyBissoli/uis-mcp-server

Data license and attribution

UIS data: CC BY-SA 4.0 (terms of the UIS Data Browser, which govern the Data API; license verified 2026-08-04).
UIS attribution in every response (citation field), with the full URL and the extraction date: Source: UNESCO Institute for Statistics (UIS), <URL>, date of extraction <date>.
ShareAlike: anything you redistribute that is built on these data must keep the CC BY-SA 4.0 license — the uis://reference/provenance resource spells it out.
The UNESCO logo is not used and no endorsement is implied; that is why the server is called uis-mcp-server and not "unesco-mcp-server". The ILOSTAT data (CC BY 4.0) live in a separate server, so the two licences never share a response.

Self-hosting / development

Everything below is only needed to run your own instance — it is not required to use the public server.

npm install
npm run typecheck && npm test   # offline suite (tools, framework, vocabulary, in-memory catalogue, eval fixtures)
npm run dev                     # http://localhost:8787/mcp (Worker)
npm run build                   # stdio runtime → dist/cli.js (what ships to npm)
node scripts/dump-surface.mjs --stdio   # offline smoke of the build: initialize → tools/resources/prompts

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

npm run deploy
node scripts/smoke-mcp.mjs      # smoke test against production (initialize → tools/list == /status → uis_* → search/fetch → errors)

Notes for operators:

Catalogue refresh is manual, once per UIS data release (no cron). The production smoke prints the current Data API release; when it differs from the seed's release, re-seed with the three commands above. Data queries follow the default release on their own, so only the catalogue can age — and its age is exposed in provenance.
The UIS Data API accepts Node's fetch as is (no header workaround needed, unlike the ILO gateway).
Optional Bearer auth (wrangler secret put API_KEY); token-bucket rate limit per IP.

Evals

@sbissoli/mcp-evals: 22 fixtures in evals/fixtures/queries.ts, validated offline in npm test. The run with a real model (npm run eval) uses the Anthropic API and needs ANTHROPIC_API_KEY (without it, it exits with instructions). Run of 2026-08-07: top-1 100% (20/20) — evals/results/.

End-to-end: 10 complex questions with a single verifiable answer in evals/e2e/evaluation.xml, answers validated manually against production (evals/e2e/validacao-respostas.md). Run of 2026-08-07 (Sonnet): 10/10 — evals/results/2026-08-07-e2e.md.

Endpoints

Route	Purpose
`/`	landing page (service identity + contact — public)
`/health`	liveness
`/status`	version, tool count and names, current deploy (feeds the README badges)
`/metrics`	aggregated usage (MCP endpoint only; no IPs, no query content)
`/.well-known/mcp/server-card.json`	MCP server card for directory scanners (derived from the live `initialize` + lists — public)
`/mcp`	MCP Streamable HTTP

Security

Snyk Agent Scan (2026-08-07, before search and fetch were added): passed — report in security/.

License

Code: MIT. Data: UIS, CC BY-SA 4.0 (see "Data license and attribution" above).

Privacy

Contact

Sidney da Silva Pereira Bissoli — sbissoli76@gmail.com. This service is not endorsed by UNESCO.

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.

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	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

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 the safety profile is covered; the description's restatement of 'read-only and idempotent' adds little. However it contributes genuinely new behavior: a live GET against the public source when needed, and an error on unknown ids.

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 purpose and return shape, then the contract, then behavior. Dense but every sentence carries information; the annotation-restating clause is the only mild redundancy.

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, yet the description still gives enough about the document shape, source, and error mode for an agent to call it correctly. Nothing material is missing for a single-parameter read tool.

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?

Only one parameter with 100% schema coverage, so the baseline is 3. The description adds provenance semantics beyond the schema — the id must originate from `search`, not just be any string.

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 even enumerates the return shape fields. It is clearly distinguishable from siblings `search` and the `uis_*` data tools.

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 names the prerequisite (only ids from `search` are valid, unknown ids error) and routes data-query needs to the alternative ('The `uis_*` tools remain the tools for data queries'). Both when-to-use and when-not-to-use are covered.

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.

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	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

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, and the description reinforces rather than contradicts them. Beyond that, it adds real operational context: max 10 results ordered by relevance, an empty list meaning no match, and that the catalog is public-source and cached in memory.

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 purpose and return shape, then routed to siblings and the fetch workflow. Slightly padded by the Deep Research-contract explanation and the redundant restatement of read-only/idempotent behavior, but no sentence is expendable.

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 purpose, result format, empty-result semantics, language handling, the sibling routing rule, and the fetch handoff. With an output schema present and annotations covering safety, nothing an agent needs to select or invoke this tool 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?

The single parameter is fully documented in the schema (100% coverage), so the baseline is high. The description still adds meaning beyond it: the query accepts natural language or keywords, works in Portuguese or English, and ignores accents and case.

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 (searches) and resource (UNESCO UIS statistics catalog), names the approx. 5,000-indicator scope and the return shape { id, title, url }. It explicitly distinguishes itself from siblings: 'this is a catalog index, not a data query' and directs data questions to the uis_* tools.

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 when-to-use (OpenAI Deep Research contract requiring exactly `search` and `fetch`), what to do next (pass a returned id to `fetch`), and when NOT to use it (direct questions and data values/series/rankings belong to the uis_* tools). No inference required.

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, and qualifier/magnitude on a record flag how the value was obtained (e.g. UIS estimate).

ParametersJSON Schema

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

ParametersJSON Schema

Name	Required	Description
`rows`	Yes
`columns`	Yes
`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
`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 (read-only, idempotent, non-destructive, open-world), and the description adds substantial behavior beyond them: no aggregation/transformation, rejection of broad queries, an error-vs-empty-result distinction, partial-code `warnings`, and revision/`qualifier`/`magnitude` semantics tied to data_vintage. This is exactly the extra context the 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.

Conciseness4/5

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

Purpose is front-loaded in the first clause and every sentence carries distinct behavioral information rather than restating schema fields. It is on the long side, and the error/warning discussion is dense, but nothing is clearly 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?

An output schema exists, so return structure need not be narrated; what the description does supply is the non-obvious failure and partial-success semantics an agent needs for correct follow-up behavior. For a 6-parameter, read-only, open-world tool this is complete.

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; the description still adds meaning the schema does not, such as the 25-indicator ceiling rationale, the origin of the code vocabularies, and the per-record footnote and vintage/qualifier interpretation. It stops short of explaining provenance_mode's two values.

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 immediately scopes it by the three filters. It explicitly names the sibling tools that supply codes (uis_search_indicators, uis_list_geo_units) and separates itself from the ILOSTAT MCP server, so an agent can distinguish it from every sibling without opening a 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?

States how to use it (codes drawn from the two sibling discovery tools, up to 25 indicators), what to avoid (broad queries are rejected; narrow by geo unit or years), and where to go for a related dataset (ILOSTAT). Routing conditions are explicit rather than implied.

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.

ParametersJSON Schema

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

ParametersJSON Schema

Name	Required	Description
`offset`	Yes
`showing`	Yes
`has_more`	Yes
`geo_units`	Yes
`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
`next_offset`	No
`total_matches`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive, closed-world behavior. The description adds genuinely new context: the result is a code catalog rather than statistical values, the count (462), and the scope restriction to uis_get_data. Pagination behavior is left to the schema, which is acceptable.

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 tight sentences: resource and count first, then filtering capability, then the critical scope limitation. Every sentence carries distinct information and nothing is padded.

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?

An output schema exists, so return values need not be explained, and the description covers purpose, scope, and filter intent adequately. Minor gap: it does not hint at result volume or paging expectations, which matters for a 462-item catalog.

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%, so the schema already documents type, limit, offset, search, and provenance_mode in detail. The description only restates the name/code and type filters and adds no format or edge-case semantics beyond the schema; baseline 3 is correct.

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 resource (462 UIS geographic codes) with concrete detail: NATIONAL/ISO alpha-3 countries and REGIONAL aggregates. It explicitly distinguishes itself from uis_get_data by declaring it returns no statistical values and that the codes apply only to that sibling.

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?

Clearly frames this as the code-lookup companion to uis_get_data and warns the codes do not apply to other statistical servers. It stops short of an explicit 'call this before uis_get_data' instruction or any comparison to uis_search_indicators, so guidance is clear but not fully prescriptive.

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.

ParametersJSON Schema

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

ParametersJSON Schema

Name	Required	Description
`hint`	No
`offset`	Yes
`showing`	Yes
`has_more`	Yes
`indicators`	Yes
`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
`next_offset`	No
`total_matches`	Yes
`vocabulary_notes`	No

TDQS

A4.9/5.0

Behavior5/5

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial behavior beyond them: AND/case-insensitive matching semantics, the everyday→UIS vocabulary normalization with the vocabulary_notes response signal, and the fact that results include data availability rather than values. 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.

Conciseness5/5

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

One dense paragraph, front-loaded with purpose then constraints then routing, with no filler sentences. Every clause (AND semantics, vocabulary mapping, return shape, sibling disambiguation) carries information the agent needs.

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, yet the description still usefully summarizes the return shape (indicator codes, data availability, vocabulary_notes). Combined with the routing guidance and query strategy, nothing an agent needs 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 baseline is 3; the description earns above baseline by explaining the query matching model (AND, case-insensitive, matched against name and code) and the vocabulary resolution that affects what query terms actually do. It does not add meaning for limit/offset/provenance_mode beyond what the schema already documents.

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 (search), resource (UNESCO Institute for Statistics catalogue of ~5,000 indicators), and scope (education, science/R&D, culture, communication, by name or code). It explicitly distinguishes itself from the sibling uis_get_data and from the ILOSTAT server, so an agent can route correctly without opening either 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?

Explicit when-to-use (catalogue lookup), when-not (statistical values → uis_get_data; labour statistics → ILOSTAT MCP), and a concrete query strategy ('start with 2–3 words and drop terms if you get 0 results'). Alternative tools are named with the condition that selects them.

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 updatesv1.6.0Oct 15, 2026

Changedfetch2 fields changed