A
licenseA
qualityA
maintenanceProvides AI assistants access to international education data from UNESCO UIS (4,000+ indicators) and OECD Education at a Glance via SDMX, with no API keys required.
10
1
MIT
UNESCO UIS — Education, Science & Culture Statistics (provenance-first)
Server Details
UNESCO UIS statistics (education, science, culture) with full provenance and fixed releases.
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- SidneyBissoli/uis-mcp-server
- GitHub Stars
- 1
- Server Listing
- uis-mcp-server
Available Tools
5 toolsfetchDeep Research DocumentARead-onlyIdempotentInspect
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 | |
| attribution | Yes |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint; the description adds beyond that by explaining the live GET behavior against the public source and the error condition for unknown ids. This gives the agent practical expectations without contradicting the annotations.
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?
The description is front-loaded with the primary action and return contract, followed by domain context, error behavior, and routing guidance. Each sentence provides distinct value, though the catalog context sentence adds length and density.
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?
For a one-parameter fetch tool with an output schema, the description covers the return shape, id provenance, error behavior, behavioral traits, and sibling distinctions. Nothing needed for the agent to invoke it 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% with the id description, so the baseline is 3. The description adds meaningful extra context by stating that only ids from `search` are valid and that an unknown id errors, reinforcing validation rules beyond the schema's simple field description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Returns the full document for an id obtained from `search`', and details the exact return shape ({ id, title, text, url, metadata }). It also distinguishes itself from the `uis_*` data query tools, so an agent can immediately tell this is the document-retrieval companion to `search`.
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?
It explicitly states that only ids returned by `search` are valid and that unknown ids return an error, giving clear input constraints. It also directs data queries to the `uis_*` tools, providing an unambiguous 'when not to use this tool and what to use instead' rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchDeep Research SearchARead-onlyIdempotentInspect
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 | |
| attribution | Yes |
TDQS
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although read-only and idempotent are already in annotations, the description adds valuable behavioral detail: up to 10 results, relevance ordering, empty list meaning no match, and the fact that the catalog comes from a public source and is cached in memory. This goes well beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core behavior and return format, then efficiently covers contract context, alternatives, query expectations, and behavior in separate short sections. Each sentence adds practical value.
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?
For a single-parameter catalog search tool, the description is complete: it defines the result contract, ordering, empty-result behavior, language support, and how to continue the workflow via `fetch`. Nothing invocation-critical 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 schema already fully documents the `query` parameter, so the baseline is 3. The description adds meaningful extra context by specifying supported languages ('Portuguese or English') and reiterating that natural language or keywords are acceptable.
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 clearly states a specific verb ('Searches'), a specific resource ('UNESCO UIS statistics catalog'), and the exact result shape ('{ id, title, url }'). It also differentiates itself from the uis_* 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?
The description explicitly tells the agent when to use this tool versus alternatives: pass returned ids to `fetch`, and prefer `uis_*` tools for direct data questions. This is highly actionable and leaves no ambiguity about tool selection.
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 dataARead-onlyIdempotentInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| 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 | |
| rows_count | Yes | |
| attribution | Yes |
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.
uis_list_geo_unitsList UNESCO UIS geo unitsARead-onlyIdempotentInspect
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 | Default |
|---|---|---|---|
| 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 | |
| attribution | Yes | |
| next_offset | No | |
| total_matches | Yes |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds valuable behavioral context: it says the tool does not return statistical values, codes apply only to uis_get_data, and lists the dataset size (462 units) and categories. It does not discuss pagination or edge cases, but the schema covers those.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and every clause adds distinct information. It avoids redundancy and is highly scannable.
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?
The tool is simple, read-only, and has an output schema, so the description need not cover return structure. It explains the tool's role in the larger workflow (providing codes for uis_get_data), its filtering options, and its narrow applicability. Given the annotations and schema, this is fully complete for reliable agent use.
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 baseline is 3. The description adds meaning beyond schema by explaining that search can be a name containing string or an exact code (with example 'BRA'), and clarifies NATIONAL vs REGIONAL types. It frames the parameters as 'filter by name/code and type', giving a cohesive mental model.
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 clearly states the tool's function: 'Valid geographic codes for uis_get_data' and explicitly enumerates what it returns (462 geo units, countries and regional aggregates). It also distinguishes itself from siblings by noting it 'Does not return statistical values' and applies only to uis_get_data, not other statistical servers.
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?
The description strongly implies usage: it is a prerequisite for uis_get_data, providing valid codes. It clarifies that it does not return statistical values, which excludes a class of alternatives. However, it stops short of explicitly stating 'use this before uis_get_data' or naming when not to use it, leaving the workflow slightly implicit.
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 indicatorsARead-onlyIdempotentInspect
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. 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 | Default |
|---|---|---|---|
| limit | No | Maximum results (default 20) | |
| query | Yes | Keywords, matched against indicator name and code (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 |
|---|---|---|
| offset | Yes | |
| showing | Yes | |
| has_more | Yes | |
| indicators | Yes | |
| provenance | Yes | |
| attribution | Yes | |
| next_offset | No | |
| total_matches | Yes |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds valuable behavioral context by stating it searches the catalogue only, does not return statistical values, and returns availability metadata such as years and record counts. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler: the main purpose is front-loaded, the return value and downstream consumer (uis_get_data) are made explicit, and the key exclusions (no statistical values, ILO data elsewhere) are stated efficiently. Every sentence earns its place.
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?
For a 5-parameter search tool with a rich output schema and read-only annotations, this description is complete: it covers scope, themes, match behavior, output nature, and routing to related tools. The output schema supplies return-value details, so the description does not need to enumerate 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 schema already documents all parameters. The description adds only modest semantic context by mentioning keyword matching against name/code and optional theme filtering, which aligns with the query and theme parameters but does not substantially extend the schema's own descriptions.
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 names a specific verb ('Search'), a concrete resource ('UNESCO Institute for Statistics catalogue of ~5,000 indicators'), and the supported domains and match behavior (keywords in name or code, optional theme filter). It also distinguishes itself from siblings by clarifying that it returns catalogue metadata and indicator codes, not statistical values.
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?
The description explicitly routes the agent: use this tool for catalogue searches and indicator-code lookup, use uis_get_data for statistical values, and use the ILOSTAT MCP server for ILO labour statistics. The when-not-to-use guidance is unambiguous, and the intended downstream use with uis_get_data is stated directly.
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. Dates show when Glama detected each change.
2 tool updates
- Added
fetch - Added
search
1 tool update
- Changed
uis_search_indicators8 fields changed- removed
Output schema / properties / indicators / items / properties / geo_types / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / indicators / items / properties / geo_types / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / indicators / items / properties / last_data_update / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / indicators / items / properties / last_data_update / typeAdded value: +[ + "string", + "null" +] - removed
Output schema / properties / indicators / items / properties / records / anyOfRemoved value: -[ - { - "type": "number" - }, - { - "type": "null" - } -] - added
Output schema / properties / indicators / items / properties / records / typeAdded value: +[ + "number", + "null" +] - removed
Output schema / properties / indicators / items / properties / years / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Output schema / properties / indicators / items / properties / years / typeAdded value: +[ + "string", + "null" +]
3 tool updates
- First observed
uis_get_data - First observed
uis_list_geo_units - First observed
uis_search_indicators
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
ILOSTAT labour statistics with provenance (source, vintage, license). 6 tools incl. search/fetch.
611World Bank World Development Indicators: curated country-year economy, health, education and more.
UK Office for National Statistics dataset catalogue + Beta JSON API
UN Sustainable Development Goal indicators for all 17 goals, curated by country and year. Free.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceEnables natural language queries to UNESCO Institute for Statistics data via Pipeworx gateway.18MIT
- AlicenseAqualityCmaintenanceA Model Context Protocol server that connects AI assistants to UNESCO Institute for Statistics data, enabling natural language search, retrieval, and comparison of indicators across countries.133MIT
- AlicenseAqualityCmaintenanceQuery 2,500+ verified public datasets (World Bank, IMF, Eurostat, OECD, WHO) from your AI agent. Search, analyze, and visualize data, and publish charts — with verified SEC + official source data.284101MIT
Try in Browser
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.