Skip to main content
Glama

Unofficial WHO MCP Server

A Model Context Protocol (MCP) server that provides access to the World Health Organization's Global Health Observatory (GHO) data via the OData API. This server enables AI assistants and applications to search, retrieve, and analyze comprehensive health indicators, country statistics, and regional data from WHO's extensive health database.

Features

  • Global Health Data: Access WHO's comprehensive health indicators and statistics

  • Rich Health Metrics: Life expectancy, mortality rates, disease burden, health systems data

  • Advanced Search: Find health indicators by keywords and topics

  • Country-Specific Data: Retrieve health data for specific countries and regions

  • Time Series Data: Access historical health trends and time-based analysis

  • WHO Regions: Filter data by WHO regional classifications

  • OData Protocol: Built on WHO's modern OData API for efficient data access

Related MCP server: OECD MCP Server

Usage

{
  "mcpServers": {
    "who-mcp-server": {
      "command": "node",
      "args": ["/path/to/who-mcp-server/build/index.js"]
    }
  }
}

API Reference

The server provides a single unified tool who-health with six methods for accessing WHO health data:

1. Get Dimensions (get_dimensions)

List all available data dimensions in the WHO database.

Parameters:

  • method: "get_dimensions"

Example:

{
  "method": "get_dimensions"
}

2. Get Dimension Codes (get_dimension_codes)

Retrieve codes for a specific dimension (countries, regions, years, etc.).

Parameters:

  • method: "get_dimension_codes"

  • dimension_code (required): Dimension to retrieve (e.g., "COUNTRY", "REGION")

Example:

{
  "method": "get_dimension_codes",
  "dimension_code": "COUNTRY"
}

3. Search Indicators (search_indicators)

Find health indicators using keywords and natural language queries.

Parameters:

  • method: "search_indicators"

  • keywords (required): Search terms for health indicators

Example:

{
  "method": "search_indicators",
  "keywords": "life expectancy maternal mortality"
}

4. Get Health Data (get_health_data)

Retrieve comprehensive health indicator data with filtering options.

Parameters:

  • method: "get_health_data"

  • indicator_code (required): WHO health indicator code

  • top (optional): Maximum number of records to return

  • filter (optional): OData filter expression for advanced filtering

Example:

{
  "method": "get_health_data",
  "indicator_code": "WHOSIS_000001",
  "filter": "SpatialDim eq 'USA' and TimeDim eq 2020",
  "top": 100
}

5. Get Country Data (get_country_data)

Retrieve health data for specific countries, regions, or time periods.

Parameters:

  • method: "get_country_data"

  • indicator_code (required): WHO health indicator code

  • country_code (optional): ISO 3-letter country code

  • region_code (optional): WHO region code

  • year (optional): Specific year or year range

  • sex (optional): Sex dimension filter

  • top (optional): Maximum number of records

Example:

{
  "method": "get_country_data",
  "indicator_code": "WHOSIS_000001",
  "country_code": "USA",
  "year": "2015:2020"
}

6. Get Cross Table (get_cross_table)

Generate tabular views of health data across countries and time periods.

Parameters:

  • method: "get_cross_table"

  • indicator_code (required): WHO health indicator code

  • countries (optional): Comma-separated list of country codes

  • years (optional): Year range or specific year

  • sex (optional): Sex dimension filter

Example:

{
  "method": "get_cross_table",
  "indicator_code": "WHOSIS_000001",
  "countries": "USA,GBR,CHN",
  "years": "2015:2020"
}

Health Indicators

The WHO database contains hundreds of health indicators covering:

  • Demographics: Life expectancy, population statistics, mortality rates

  • Disease Burden: HIV/AIDS, tuberculosis, malaria, non-communicable diseases

  • Health Systems: Health expenditure, health workforce, hospital beds

  • Risk Factors: Tobacco use, alcohol consumption, obesity, air pollution

  • Maternal & Child Health: Maternal mortality, infant mortality, vaccination coverage

  • Mental Health: Suicide rates, mental health services

  • Environmental Health: Water, sanitation, air quality

Common Indicator Codes

  • WHOSIS_000001: Life expectancy at birth

  • MDG_0000000001: Maternal mortality ratio

  • GHED_CHE_pc_PPP_INT: Current health expenditure per capita

  • M_Est_smk_curr_std: Smoking prevalence

  • SA_0000001688: Suicide mortality rate

WHO Regions

The system supports WHO's six regional classifications:

  • AFR: African Region

  • AMR: Region of the Americas

  • SEAR: South-East Asia Region

  • EUR: European Region

  • EMR: Eastern Mediterranean Region

  • WPR: Western Pacific Region

OData Query Examples

Basic Filtering

SpatialDim eq 'USA' and TimeDim eq 2020

Time Range Filtering

TimeDim ge 2015 and TimeDim le 2020

Sex Disaggregation

Dim1 eq 'MLE'  // Male
Dim1 eq 'FMLE' // Female
Dim1 eq 'BTSX' // Both sexes

Date Functions

date(TimeDimensionBegin) ge 2011-01-01 and date(TimeDimensionBegin) lt 2012-01-01

Null Checks

Dim1 ne null  // Has disaggregation data
Dim1 eq null  // No disaggregation data

Data Sources

This server accesses data from:

  • WHO Global Health Observatory: Primary source for health statistics

  • OData API: Modern REST API with standardized querying

  • Official WHO Data: Verified and quality-assured health indicators

  • Real-time Updates: Data synchronized with WHO releases

Rate Limits & Guidelines

  • Respect WHO's API rate limits and usage policies

  • Cache responses when appropriate to reduce API calls

  • Use appropriate $top parameters to limit large data sets

  • Monitor API performance and adjust queries as needed

Available Tools

1 tool
who-healthC

Unified tool for WHO Global Health Observatory operations: access health indicators, country statistics, and regional data via the modern OData API. Provides access to comprehensive health data from the World Health Organization covering topics like life expectancy, disease burden, health systems, and risk factors using standard OData query syntax.

ParametersJSON Schema
NameRequiredDescriptionDefault
methodYesThe operation to perform: get_dimensions (list all data dimensions), get_dimension_codes (list codes for a dimension), get_health_data (retrieve indicator data), search_indicators (find health indicators), get_country_data (country-specific data), or get_cross_table (tabular data view)
dimension_codeNoFor get_dimension_codes: The dimension code to retrieve (e.g., "COUNTRY" for countries, "REGION" for WHO regions)
indicator_codeNoFor get_health_data, get_country_data, get_cross_table: WHO health indicator code (e.g., "WHOSIS_000001" for life expectancy)
keywordsNoFor search_indicators: Search terms for finding health indicators (e.g., "life expectancy", "mortality", "diabetes", "vaccination")
topNoFor get_health_data, get_country_data: Maximum number of records to return (OData $top parameter)
filterNoFor get_health_data: OData filter expression to limit results. Supports country/time filtering, disaggregation checks (null/not null), and date functions.
country_codeNoFor get_country_data: ISO 3-letter country code (e.g., "USA", "GBR", "CHN")
region_codeNoFor get_country_data: WHO region code (e.g., "EUR" for Europe, "AMR" for Americas)
yearNoFor get_country_data: Specific year or year range for data (e.g., "2020", "2015:2020")
countriesNoFor get_cross_table: Comma-separated list of country codes to include
yearsNoFor get_cross_table: Year range (YYYY:YYYY) or specific year (YYYY)
sexNoFor get_cross_table, get_country_data: Sex dimension filter

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'Provides access to comprehensive health data' and mentions OData API usage, but fails to disclose critical traits: whether it's read-only or mutative, authentication requirements, rate limits, error handling, or response formats. For a tool with 12 parameters and no output schema, this is a significant gap in transparency.

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 appropriately sized and front-loaded, starting with the unified purpose and key features. Both sentences earn their place by explaining the tool's scope and technical approach. However, it could be slightly more concise by integrating the OData mentions more seamlessly, but overall it's efficient with minimal waste.

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

Completeness2/5

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

Given the tool's complexity (12 parameters, no annotations, no output schema), the description is incomplete. It lacks details on behavioral traits, usage guidelines, and output expectations, which are crucial for an agent to invoke it correctly. While it covers the purpose and data scope, it doesn't compensate for the missing structured information, leaving significant gaps in understanding.

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 thoroughly. The description adds marginal value by mentioning 'OData query syntax' and examples of data topics, but doesn't provide additional parameter semantics beyond what's in the schema. This meets the baseline for high schema coverage without compensating with extra insights.

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

Purpose4/5

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

The description clearly states the tool's purpose: 'access health indicators, country statistics, and regional data via the modern OData API' and specifies it's for WHO Global Health Observatory operations. It distinguishes the scope ('comprehensive health data from the World Health Organization') and examples of topics covered. However, with no sibling tools mentioned, it doesn't need to differentiate from alternatives, so it's not a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives or any prerequisites. It mentions 'via the modern OData API' and 'using standard OData query syntax,' which gives some technical context, but lacks explicit usage scenarios, exclusions, or comparisons to other methods. This leaves the agent with minimal direction on appropriate application.

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.

  1. 1 tool update
    • First observedwho-health

TDQS

B3.2/5.0
Disambiguation5/5

With only one tool, there is no possibility of ambiguity or overlap between tools. The single tool 'who-health' has a clearly defined purpose focused on WHO Global Health Observatory operations, making it impossible for an agent to misselect between non-existent alternatives.

Naming Consistency5/5

A single tool inherently exhibits perfect naming consistency as there are no other tools to compare against. The name 'who-health' follows a clear and descriptive pattern that aligns with the server's purpose, with no deviations or mixed conventions present.

Tool Count2/5

A single tool is generally too few for a server's purpose unless it is extremely narrow, but here the tool description suggests broad capabilities (access health indicators, country statistics, regional data, etc.). This likely represents a significant under-scoping, as typical data access servers benefit from multiple specialized tools for different query types or operations.

Completeness3/5

The tool claims to provide comprehensive access via OData queries, which could theoretically cover many operations, but having only one tool may create gaps in usability or functionality. For example, there are no dedicated tools for common actions like listing available datasets, filtering by specific criteria, or managing queries, which might hinder agent workflows despite the broad OData coverage.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/openpharma-org/who-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server