Skip to main content
Glama

who-gho-mcp-server

by io.github.cyanheads

Query WHO GHO Indicator Data

who_query_indicator_data
Read-onlyIdempotent

Query data rows for a single WHO GHO indicator with optional spatial, temporal, and dimension filters. Returns rows with numeric values, uncertainty intervals (Low/High), and spatial/time metadata. This is the primary data-fetching tool in the find-then-query workflow: use who_search_indicators to find the indicator code, optionally call who_get_indicator_metadata to confirm which filter dimensions are valid, then call this tool. Spatial filters are mutually exclusive per call: provide only one of country_codes, region_codes, or income_group_codes — mixing them triggers an error. Omitting all spatial filters returns all geographies (may be large; use limit to cap). The sex filter only applies when the indicator uses SEX as its first cross-cutting dimension — if not, the filter returns empty rows; check who_get_indicator_metadata first if uncertain. Rows are returned in a deterministic order (most recent first by default), so a capped result is the top of a defined slice rather than an arbitrary sample; page through the rest with offset.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sexNoFilter on sex dimension: SEX_BTSX (both sexes), SEX_FMLE (female), SEX_MLE (male). Only applies when the indicator uses SEX as its first cross-cutting dimension.
sortNoRow ordering: "year_desc" (default) returns the most recent years first, "year_asc" the earliest first. Ties are broken by spatial code, then dimension, then row id.year_desc
limitNoMaximum number of data rows to return. Default 200, max 1000.
offsetNoZero-based row offset for pagination. Default 0. Pages are stable because rows are returned in a deterministic order — read hasMore and nextOffset from the response to continue. An offset at or beyond totalRows returns an empty rows array, not an error.
year_toNoEnd year (inclusive) for the time range filter, e.g. 2023.
year_fromNoStart year (inclusive) for the time range filter, e.g. 2015.
dim1_valueNoValue filter for indicators whose first cross-cutting dimension is not SEX (e.g. an AGEGROUP code like "YEARS05-14"). Ignored when sex is also provided.
region_codesNoWHO region codes to filter on, e.g. ["AFR","EUR","AMR","EMR","SEAR","WPR"]. Returns the aggregate row for each named WHO region — not per-country rows within it. To get country-level data for a region, use who_list_dimension_values with dimension="COUNTRY" and parent_code set to the region code to retrieve the ISO codes for countries in that region, then pass those to country_codes. Use who_list_dimension_values with dimension="REGION" to see all valid region codes. Mutually exclusive with country_codes and income_group_codes.
country_codesNoISO 3166-1 alpha-3 country codes to filter on, e.g. ["JPN","USA","BRA"]. Mutually exclusive with region_codes and income_group_codes.
indicator_codeYesIndicator code to query, e.g. "WHOSIS_000001". Use who_search_indicators to find codes.
income_group_codesNoWorld Bank income group codes, e.g. ["WB_HI","WB_LMI","WB_LI","WB_UMI"]. Use who_list_dimension_values with dimension="WORLDBANKINCOMEGROUP" to see all valid codes. Mutually exclusive with country_codes and region_codes.
include_uncertaintyNoInclude Low and High uncertainty interval bounds in output. Default true.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
rowsNoData rows matching the query.
errorNoPresent when the call failed. Absent on success.
noticeNoPresent when rows were withheld or the requested offset ran past the end of the result set. Explains how to reach the remaining rows.
offsetNoZero-based row offset this page started at.
hasMoreNoTrue when rows remain beyond this page. Pair with nextOffset to continue.
pageInfoNoHuman-readable page position, e.g. "offset 0, showing 200 of 12936". Use to construct the next offset.
totalRowsNoTotal row count matching the query on the server (before the limit is applied).
truncatedNoTrue when the result was capped at the requested limit.
nextOffsetNoOffset to request for the next page. Absent when this page reached the end of the result set.
totalCountNoAlias of totalRows for cross-tool consistency — total rows before the limit.
appliedFiltersNoFilters that were applied to the query.

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already carry readOnlyHint=true, idempotentHint=true, openWorldHint=false, so safety profile is covered. The description adds substantive behavior beyond that: spatial parameter mutual exclusivity with error on mixing, the sex-filter empty-rows caveat, deterministic ordering (most recent first by default) making capped results a defined slice rather than an arbitrary sample, and pagination semantics. This is rich, actionable behavioral context that annotations alone cannot provide.

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 paragraph is dense and front-loaded: core purpose first, workflow second, then constraints and behavioral notes. Every sentence earns its place. Some redundancy exists with the schema (mutual exclusivity repeated in both the description and multiple param descriptions), but for a 12-parameter tool with subtle edge cases, the length is justifiable and well-organized.

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 complex 12-parameter tool, this is complete. Return values are covered by the output schema (present, so description needn't explain them). Annotations cover safety. The description covers the workflow, spatial exclusivity, dimension-filter caveats, ordering guarantees, and pagination stability. Nothing an agent needs to select filters and 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 detailed descriptions on all 12 parameters, so baseline is 3. The description adds coherent value on top: it frames the mutual-exclusivity constraint as a cross-parameter rule, explains the sex/dim1_value dimensionality interplay ('only applies when the indicator uses SEX as its first cross-cutting dimension'), and clarifies the offset-beyond-totalRows behavior returns empty rows not an error. Minor redundancy with schema param text, but the narrative model improves parameter selection.

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 verb and resource ('Query data rows for a single WHO GHO indicator') with explicit scope (spatial, temporal, dimension filters). It positions itself as 'the primary data-fetching tool' in the find-then-query workflow, clearly distinguishing it from who_search_indicators (code lookup) and who_get_indicator_metadata (filter validation). Shows exactly how the resource is characterized.

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?

Provides explicit when-to-use guidance embedded in the workflow: use who_search_indicators to find the code, optionally call who_get_indicator_metadata to confirm valid dimensions, then call this tool. Names concrete exclusions — spatial filters are mutually exclusive per call and mixing triggers an error; the sex filter only applies when SEX is the first cross-cutting dimension and returns empty rows otherwise. It even routes to who_list_dimension_values for valid codes. No agent needs to infer usage.

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

All who-gho-mcp-server 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.5/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: browsing/searching indicators, fetching metadata, listing dimensions, listing dimension values, and querying data. There is minor overlap between listing and searching indicators, but the descriptions explicitly differentiate them (browse vs. keyword search), leaving no ambiguity.

Naming Consistency5/5

All tools follow the 'who_<verb>_<noun>' pattern (e.g., who_list_dimensions, who_query_indicator_data), with verbs like get, list, search, and query used consistently. The uniform prefix and structure create a predictable and coherent naming scheme.

Tool Count5/5

Six tools is an ideal size for this domain, covering the full WHO GHO workflow without redundancy. Each tool supports a distinct step in discovery and data retrieval, making the set well-scoped and efficient.

Completeness5/5

The tool set covers the entire necessary surface for working with WHO GHO data: discovering indicators (search/list), retrieving metadata, exploring dimensions and their values, and querying actual data with filters. No obvious gaps exist for a read-only health statistics API.

Resources