Who Gho

Get Data

get_data

Read-onlyIdempotent

Get World Health Organization health statistics for a country and year — life expectancy, immunization coverage, mortality, disease burden, risk factors and health system measures from the Global Health Observatory. Accepts a plain indicator name such as "measles immunization coverage" and a plain country name such as "Kenya"; both are resolved to WHO codes and the response says what it resolved to. If the requested year has no data it returns the latest year that does, and says which.

Input Schema

TableJSON Schema

Name	Required	Description
`year`	No	Year, e.g. "2020". If that year has no data the latest available year is returned instead, flagged as year_fallback.
`country`	No	Country NAME ("Kenya", "United States") or ISO3 code ("KEN", "USA").
`indicator`	Yes	Indicator NAME ("measles immunization coverage", "life expectancy at birth") or a GHO code ("mslv", "WHOSIS_000001"). Names are resolved — do not invent a code.

Output Schema

TableJSON Schema

Name	Required	Description
`data`	Yes	Array of data values (max 100 returned)
`total`	Yes	Total number of data values found
`returned`	Yes	Number of data values actually returned (max 100)
`indicator`	Yes	The requested indicator code

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedAug 7, 2026

changedInput schema / examples

Previous value: -[
-  {
-    "country": "USA",
-    "indicator": "WHOSIS_000001",
-    "year": "2020"
-  },
-  {
-    "country": "GBR",
-    "indicator": "WHOSIS_000015"
-  }
-]New value: +[
+  {
+    "country": "Kenya",
+    "indicator": "measles immunization coverage",
+    "year": "2022"
+  },
+  {
+    "country": "Japan",
+    "indicator": "life expectancy at birth"
+  }
+]

changedInput schema / properties / country / description

Previous value: -"ISO 3-letter country code (e.g., \"USA\", \"GBR\", \"JPN\")"New value: +"Country NAME (\"Kenya\", \"United States\") or ISO3 code (\"KEN\", \"USA\")."

changedInput schema / properties / indicator / description

Previous value: -"WHO indicator code (e.g., \"WHOSIS_000001\" for life expectancy)"New value: +"Indicator NAME (\"measles immunization coverage\", \"life expectancy at birth\") or a GHO code (\"mslv\", \"WHOSIS_000001\"). Names are resolved — do not invent a code."

changedInput schema / properties / year / description

Previous value: -"Year to filter by (e.g., \"2020\")"New value: +"Year, e.g. \"2020\". If that year has no data the latest available year is returned instead, flagged as year_fallback."

First observedJun 26, 2026

TDQS

A4.6/5.0

Behavior5/5

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

While annotations already declare readOnly, openWorld, idempotent, and non-destructive hints, the description adds significant behavioral context: it discloses the name-resolution process, states that the response echoes what it resolved to, and details the year-fallback behavior with a flag. These are not present in the annotations, making the tool's runtime behavior more predictable.

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 long, front-loaded with the tool's core purpose, then input details, then fallback behavior. Every sentence carries useful information without fluff or repetition, achieving high information density in a compact structure.

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?

With an output schema, rich annotations, and a detailed description covering name resolution and year fallback, the tool is well-specified. A minor gap exists: the schema marks only 'indicator' as required, but the description implies a country and year are always used without explaining behavior when they are omitted. This slight ambiguity prevents a perfect score.

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 provides 100% coverage with descriptions for all three parameters, so the baseline is 3. The description adds extra value by clarifying that plain names are accepted and resolved (e.g., 'measles immunization coverage' → a GHO code) and that the response says what it resolved to, which goes beyond the schema's simple 'name or code' statements.

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-resource pair: 'Get World Health Organization health statistics for a country and year,' and enumerates the types of statistics (life expectancy, immunization coverage, etc.). This clearly distinguishes it from sibling tools like get_indicators or list_countries, which would list available indicators or countries rather than fetch actual data.

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 provides clear usage context by explaining that plain indicator and country names are accepted and resolved to WHO codes, and that a year fallback occurs when no data exists. It does not explicitly name alternative tools or state when not to use it, but the cited input patterns and fallback behavior strongly imply the intended use case.

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

All Who Gho tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.