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 UIS Education Statistics MCP?

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 UIS Education Statistics MCP 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 UIS Education Statistics MCP

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.

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 updatesv1.9.0Oct 29, 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 updatev1.8.0Oct 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 updatesv1.6.0Oct 15, 2026

Changedfetch2 fields changed