Skip to main content
Glama

UNESCO UIS — Education, Science & Culture Statistics (provenance-first)

by io.github.SidneyBissoli

Get UNESCO UIS data

uis_get_data
Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
end_yearNoLast year, e.g. 2024
geo_unitsNoGeo unit codes from uis_list_geo_units (e.g. ["BRA","ARG"]); omit for all
indicatorsYesIndicator codes from uis_search_indicators (e.g. ["CR.1"])
start_yearNoFirst year, e.g. 2015
provenance_modeNoProvenance verbosity: 'concise' (default — source, url, vintage, retrieval date, citation, license) or 'detailed' (full canonical block with dataset, dimension key and notices)
include_footnotesNoInclude per-record footnotes (source notes); default false

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
rowsYes
columnsYes
provenanceYes
rows_countYes
attributionYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Discloses that the tool returns raw records only with no aggregation/transformation, that broad queries are rejected, and that ILO data is not included. These behaviors go beyond the read-only/idempotent annotations and help an agent set expectations.

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?

Four short sentences, each with distinct value: purpose/filter, footnote toggle, raw-only transformation stance, and rejection/narrowing advice. No filler or repetition of schema.

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

Completeness5/5

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

Given the output schema exists and annotations provide safety profile, the description covers what the tool returns, limits, error behavior (broad query rejection), and relationship to ILOSTAT. This is sufficient for an agent to invoke correctly.

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 covers all six params at 100%, and the description adds useful cross-references (indicator codes from uis_search_indicators, geo codes from uis_list_geo_units, max 25 indicators) and explains include_footnotes purpose. Not as deep as a full param walkthrough, but schema already does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action: retrieve statistical records from the UNESCO Institute for Statistics Data API, filtered by indicator codes, geo unit codes, and year range. It clearly differentiates from sibling tools by referencing them as code sources rather than data retrieval alternatives.

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 instructs how to use: source codes from uis_search_indicators and uis_list_geo_units; use include_footnotes for source notes; if query too broad, narrow by geo unit or years; ILO stats should go to ILOSTAT sibling. This gives clear when-to-use and exclusion guidance.

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

All UNESCO UIS — Education, Science & Culture Statistics (provenance-first) toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0
Disambiguation4/5

The uis_* tools form a clearly separated data workflow: search indicators, list geo units, and get data each have distinct roles, while search/fetch are a distinct document-retrieval pair. The generic names search and fetch could be confused with uis_search_indicators and uis_get_data at first glance, but the descriptions explicitly clarify the boundary.

Naming Consistency4/5

The three data tools follow a consistent uis_<verb>_<noun> pattern, while search and fetch are bare verbs tied to the Deep Research contract. This is a visible naming deviation, but the two groups are internally consistent and the prefix convention remains strong.

Tool Count5/5

Five tools is well-scoped for this server: two document-retrieval tools for the Deep Research contract and three tightly linked data tools for indicator discovery, geographic lookup, and data extraction. None of the tools feel redundant or excessive.

Completeness5/5

The tool surface covers the full query workflow: find indicators, resolve geo units, retrieve data with provenance, and fetch full documents from search results. There are no dead ends or obvious missing operations for the stated statistics domain.

Resources