Somewhere in the documentation for the United Nations' new MCP server there is a note that almost no vendor would publish. One of the six tools, get_multi_entity_observations, "has no applicable target on this instance." The backend rejects every entity filter it sends with the error unsupported SDMX component filter "donor". The docs go further and tell you what not to do about it: no variable from outside the corpus should be substituted to make the tool answer [3].
That is a working MCP server telling an AI client, in writing, which of its own capabilities is currently furniture.
The launch coverage on 17 September was about something else. Google and the UN system announced the UN System Data Commons, an open-source platform that unifies statistics from across UN entities into one searchable knowledge graph at data.un.org, built on Data Commons by Google with support from Google.org to the UN Foundation [1]. The site's own counter reads 26 UN system entities [2], and the stated goal is 80% of the UN system's statistical datasets by 2027 [1]. The natural-language search is the demo, and it is genuinely good.
The part worth an engineer's afternoon is underneath: a public MCP endpoint at https://unsd-datacommons.gcp.un-icc.cloud/mcp, speaking Streamable HTTP, with six tools, three research playbooks served as MCP resources, and a manual that documents its own failure modes more honestly than most internal runbooks [3][4].
What is actually exposed
The six tools form a pipeline rather than a menu [3]:
| Tool | Role |
|---|---|
search_indicators |
Find topics and statistical variables matching a natural-language concept, optionally checking availability for named places |
search_child_indicators |
Find indicators with data across the child places of a parent geography, tested against a sample |
get_variable_metadata |
Definitions, source facets, date coverage, provenance and entity coverage, before you retrieve anything |
get_observations |
Observations for one place |
get_child_observations |
Observations across the places inside a parent geography |
get_multi_entity_observations |
Relationships between entities, such as donor and recipient |
Note the shape. Search returns names, retrieval takes DCIDs, and a qualification step sits between them on purpose. An agent that skips get_variable_metadata can retrieve a number without its provenance, which for UN statistics is most of the number's meaning.
Then there are the resources: three SKILL.md playbooks, served by the server itself, which the docs describe as mattering "as much as the tools", because the tool descriptions point clients at the playbook to read first [3]. The server is not shipping an API surface and hoping. It ships the operating procedure with the endpoint and expects the client to follow it.
This is the most interesting design decision in the whole release, and it is a direct answer to the problem we covered when MCP's roadmap put identity and richer primitives on the table: tool descriptions alone do not tell an agent how to do research properly. A playbook resource does.
The failure modes, published
Here is where the UN's documentation leaves the industry norm behind. Each of these is in the manual, dated, with the evidence linked [3]:
A tool with nothing to operate on. get_multi_entity_observations expects variables that carry entity roles at the observation level. This corpus models a counterpart, origin or destination as a constraint baked into the variable's identity instead. Relationship data from UNHCR, the SDG database and UNICEF exists, but it is reached as one single-place variable per counterpart. The docs call this "a modelling and capability mismatch, not a missing example" [3].
Upstream examples that silently return nothing. Two of the three playbooks come from the wider Data Commons project, and their examples use identifiers from that larger graph: Count_Person, geoId/06, UnemploymentRate_Person. On this instance those places resolve but carry no observations, so the call succeeds and returns no variables [3]. The docs tell you to read that as the current geographic scope rather than as the concept being missing, and to obtain variables through the search tools instead of copying identifiers.
Place names that look correct and fail. The search tools take plain English names resolved against the server's own index. A name it cannot match falls through to a Google Maps legacy geocoder that is not enabled for the project, and the call fails with 500: failed to resolve place names: maps: REQUEST_DENIED. In practice: "Turkey" and "Iran" resolve; "Türkiye", "Turkiye" and "Islamic Republic of Iran" do not. "Small Island Developing States" works as a parent place; "Least Developed Countries" does not, though the tool accepts that grouping's DCID if you find it another way [3].
Read that list again as an agent developer. Two of the three are not errors. They are successful calls that return nothing, and an agent that treats empty as absent will confidently report that the UN has no data on something it publishes.
The escape hatch, and its boundary
The same documentation adds a second interface with a deliberately narrow brief. The knowledge graph behind the server answers plain HTTP requests, and the docs publish exactly five structural recipes for it: the other governed slices of a statistical family, the vocabulary a constraint draws on, the groupings a place belongs to, the thematic organisation of the corpus, and the governed comparison set a variable belongs to. These are the questions the current MCP flattens or does not expose at all [3].
What keeps this from becoming a shadow API is the framing. Each recipe starts from an identifier the MCP workflow already established, inspects only the structure that question needs, and hands back to the MCP for the statistical work. The docs state plainly that it is not a second research workflow and not a fallback for a search that disappointed you [3]. That is a boundary most projects discover they needed two years after someone wired an agent straight into the database.
Worth noting the lineage too. Google released the Data Commons MCP server publicly in September 2025, pitching it as a way for agents to consume public data natively and reduce hallucination, with the ONE Campaign's health-financing agent as the first real deployment [5]. The UN instance is that pattern applied to intergovernmental statistics, which is why its playbooks arrive with upstream examples that do not fit the new corpus.
Why this beats a status page
The docs say the site is rebuilt against the live server on every release, that its pipeline compares the tool names, parameters, resources and prompt count the server reports against what the pages claim before a release is cut, and that the walkthroughs execute real calls [3]. Walkthrough C exists specifically to re-run the entity-role check that proves the multi-entity tool still has nothing to work on.
That is documentation as a test suite. The interesting consequence is that the manual cannot quietly drift from the server, which is the normal fate of every MCP README written once at launch. It also means the "cannot do" list is falsifiable: the day a UN variable starts carrying entity roles, the check changes and the note goes away.
Compare that with the state of the wider ecosystem. When we looked at the MCP server benchmark numbers, the gap between what servers advertise and what they deliver under test was the whole story. Here the server publishes the gap itself, with a build job to keep it current.
What this changes for people building agents
The UN part matters. An agent that needs a life-expectancy figure, a maternal-mortality series or school-completion rates across small island states can now fetch them from the body that compiles them, with provenance attached, instead of from whatever a search index surfaced. Google's post lists the kind of question the platform is built for, such as how access to clean water in rural areas affects school attendance [1], and the MCP endpoint answers that class of question programmatically [3].
But read the last line of Google's own announcement carefully: "Even with grounded, verified data, review the underlying sources before citing critical figures" [1]. That sentence, in a launch post about making data AI-ready, is the tell. Grounding an agent in an authoritative source removes the invention problem. It does not remove the selection problem, the vintage problem, or the "this variable does not mean what its name suggests" problem, which is exactly why get_variable_metadata is a distinct step in the pipeline.
Three things to take into your own work:
- If you build an MCP server, publish the scope and the dead ends. A tool that returns empty for a whole class of input is a documentation obligation, not an embarrassment. Every hour a client spends discovering it by trial is an hour your server's reputation pays for.
- Ship the playbook as a resource, not as prose in a README. The UN server serves
SKILL.mdfiles that tell a client how to sequence discovery, qualification and retrieval. Any server with more than three tools needs the same, because tool descriptions cannot carry a workflow. - Treat an empty result as an unknown, not as a zero. This is the single most transferable lesson here. Design your agent so "no rows" triggers a scope check, not a confident negative statement. The UN's docs had to say this out loud because their own upstream examples fail that way.
The honest server is the useful one
There is a version of this launch where the MCP endpoint ships with a cheerful README, the multi-entity tool stays in the tool list, and agents spend the next year quietly producing empty reports about donor flows while nobody can tell whether the data is missing or the query is wrong.
The UN Statistics Division published the map instead, with the roads that do not connect marked as not connecting. For an ecosystem where the usual failure is a server that claims more than it does, an institution saying "this tool has nothing to operate on here, and do not fake it with a variable from somewhere else" is worth more than another thousand tools in a registry.
Point your agent at https://unsd-datacommons.gcp.un-icc.cloud/mcp and read the playbooks before you write a single prompt. Then go and write down what your own server cannot do.
References
[1] Prem Ramaswami, Google: Google and UN system launch new global data platform. Blog
[2] United Nations: UN System Data Commons. Documentation
[3] United Nations Statistics Division: UN System Data Commons MCP server. Documentation
[4] United Nations: Connect to UN System Data Commons. Documentation
[5] Keyur Shah, Google: Introducing the Data Commons Model Context Protocol (MCP) Server. Blog