who-gho-mcp-server
Server Details
WHO Global Health Observatory — 3,059 indicators across 194 member states.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- cyanheads/who-gho-mcp-server
- GitHub Stars
- 1
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.6/5 across 6 of 6 tools scored.
Each tool has a clearly distinct purpose: listing dimensions, dimension values, indicators, searching indicators, fetching indicator metadata, and querying data. There is no ambiguity or overlap between the six tools.
All tool names follow a consistent pattern: 'who_' prefix + verb_noun in snake_case (e.g., who_list_dimensions, who_query_indicator_data). No mixing of conventions.
With 6 tools, the server is well-scoped for a data query API. It covers discovery, metadata, and data retrieval without being bloated or too sparse.
The tool surface covers the full workflow: browse/search indicators, inspect metadata, list dimensions and values, and query data. No obvious gaps for a read-only API.
Available Tools
6 toolswho_get_indicator_metadataGet WHO GHO Indicator MetadataARead-onlyIdempotentInspect
Fetch metadata for one or more WHO GHO indicator codes: the full indicator name and the dimensions it supports (e.g. COUNTRY, REGION, SEX, YEAR, WORLDBANKINCOMEGROUP, AGEGROUP). Call this before querying data with who_query_indicator_data to confirm which filter dimensions are valid for a given indicator. Accepts up to 10 codes per call. Codes with no metadata are reported in the notFound array rather than causing an error.
| Name | Required | Description | Default |
|---|---|---|---|
| indicator_codes | Yes | One to ten indicator codes, e.g. ["WHOSIS_000001", "MDG_0000000026"]. |
Output Schema
| Name | Required | Description |
|---|---|---|
| notFound | Yes | Indicator codes that returned no metadata — they may not exist in the GHO catalog. |
| indicators | Yes | Metadata for each code that returned results. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds behavioral context: a limit of 10 codes per call and how missing codes are reported (notFound array), which supplements 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences convey all necessary information without redundancy. The description is front-loaded with the main purpose, then provides usage context and behavioral details in a compact format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but signaled), the description need not detail return values. It covers the essential: what metadata is returned (name, dimensions), the limit, and error handling, making it fully adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a description for 'indicator_codes'. The tool's description adds meaning by clarifying the parameter's purpose (indicator codes), giving examples, and specifying the limit (up to 10), going beyond the schema's brief description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fetch metadata' and identifies the resource as 'WHO GHO indicator codes'. It details the output (full indicator name and dimensions) and distinguishes from sibling tools by noting it's a prerequisite before querying data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states to call this before 'who_query_indicator_data' to confirm valid filter dimensions, providing clear when-to-use guidance and referencing a sibling tool. It also explains error handling via 'notFound' array, setting expectations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
who_list_dimensionsList GHO Dimension TypesARead-onlyIdempotentInspect
List all dimension type codes and human-readable titles available in the WHO Global Health Observatory API. Use this to discover valid dimension codes before calling who_list_dimension_values. Common dimensions include COUNTRY, REGION, SEX, WORLDBANKINCOMEGROUP, and AGEGROUP, but many additional types exist — this tool exposes them all.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| dimensions | Yes | All available dimension types in the GHO catalog. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the tool's safety is clear. The description adds useful context such as the exhaustive listing and common dimension examples, enhancing understanding beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and each sentence earns its place by stating purpose and providing actionable guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, an existing output schema, and informative annotations, the description fully covers what an agent needs: what it returns, why it's useful, and example codes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With no parameters and 100% schema coverage, the description adds value by explicitly confirming the tool takes no parameters and lists all dimensions, reinforcing the schema's implication.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all dimension type codes and titles from the WHO GHO API, with specific verb and resource. It distinguishes itself from the sibling who_list_dimension_values by explicitly mentioning its role as a prerequisite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance to use this tool before who_list_dimension_values and lists common dimensions, but lacks explicit when-not-to-use or alternatives beyond the specified sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
who_list_dimension_valuesList GHO Dimension ValuesARead-onlyIdempotentInspect
List valid codes and labels for a WHO GHO dimension type such as COUNTRY, REGION, SEX, WORLDBANKINCOMEGROUP, or AGEGROUP. Use this to discover valid filter values before calling who_query_indicator_data, or to confirm the correct ISO code for a country. Use who_list_dimensions to discover all available dimension type codes.
| Name | Required | Description | Default |
|---|---|---|---|
| dimension | Yes | Dimension type code. Use who_list_dimensions to discover all available codes. Common values: COUNTRY, REGION, SEX, WORLDBANKINCOMEGROUP, AGEGROUP. |
Output Schema
| Name | Required | Description |
|---|---|---|
| values | Yes | Valid values for this dimension type. |
| dimension | Yes | The requested dimension type code. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and idempotent. The description adds that it returns 'valid codes and labels' and mentions ISO code confirmation, but does not elaborate on response format or limitations. Still adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each with a distinct role: purpose, usage context, sibling reference. No fluff, efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema exists, annotations provided), the description fully covers purpose, usage, and parameter discovery. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes the dimension parameter with common values (100% coverage). The description parallels this but doesn't add new semantic depth; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List valid codes and labels for a WHO GHO dimension type' with concrete examples like COUNTRY, REGION, SEX. It distinguishes from siblings by referencing who_list_dimensions and who_query_indicator_data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use this 'before calling who_query_indicator_data, or to confirm the correct ISO code for a country.' Also directs to who_list_dimensions for discovering dimension codes, providing clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
who_list_indicatorsList WHO GHO IndicatorsARead-onlyIdempotentInspect
Browse the WHO Global Health Observatory indicator catalog with pagination. Use when you want to explore indicators without a keyword, or to page through the full catalog. Use who_search_indicators when you have a keyword to narrow the results.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of indicators to return per page. Default 50, max 500. | |
| offset | No | Zero-based offset for pagination. Default 0. |
Output Schema
| Name | Required | Description |
|---|---|---|
| hasMore | Yes | True when more indicators exist beyond the current page. |
| pageInfo | Yes | Human-readable page position, e.g. "offset 0, showing 50 of 3059". Use to construct the next offset. |
| indicators | Yes | Indicators for the requested page. |
| totalCount | Yes | Total number of indicators in the GHO catalog. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds minimal behavioral context beyond pagination, which is already in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, then usage guidelines. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple paginated list tool with annotations covering safety and idempotency, an output schema, and complete parameter documentation, the description is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter descriptions are clear; the tool description does not add additional meaning beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Browse the WHO Global Health Observatory indicator catalog with pagination' and distinguishes from the sibling tool 'who_search_indicators' by specifying when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'Use when you want to explore indicators without a keyword, or to page through the full catalog. Use who_search_indicators when you have a keyword.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
who_query_indicator_dataQuery WHO GHO Indicator DataARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| sex | No | Filter 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. | |
| limit | No | Maximum number of data rows to return. Default 200, max 1000. | |
| year_to | No | End year (inclusive) for the time range filter, e.g. 2023. | |
| year_from | No | Start year (inclusive) for the time range filter, e.g. 2015. | |
| dim1_value | No | Value 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_codes | No | WHO 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 filter by parentCode 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_codes | No | ISO 3166-1 alpha-3 country codes to filter on, e.g. ["JPN","USA","BRA"]. Mutually exclusive with region_codes and income_group_codes. | |
| indicator_code | Yes | Indicator code to query, e.g. "WHOSIS_000001". Use who_search_indicators to find codes. | |
| income_group_codes | No | World 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_uncertainty | No | Include Low and High uncertainty interval bounds in output. Default true. |
Output Schema
| Name | Required | Description |
|---|---|---|
| rows | Yes | Data rows matching the query. |
| notice | No | Present when the limit was reached and not all rows were returned. Explains how to retrieve additional rows. |
| totalRows | Yes | Total row count matching the query on the server (before the limit is applied). |
| truncated | No | True when the result was capped at the requested limit. |
| totalCount | Yes | Alias of totalRows for cross-tool consistency — total rows before the limit. |
| appliedFilters | Yes | Filters that were applied to the query. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), description warns about error from mixing spatial filters, large result sets when omitting spatial filters, and empty rows for sex filter when irrelevant. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise at ~5 sentences, front-loaded with purpose, then workflow, then specific warnings. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description covers all necessary context: workflow steps, filter caveats, edge cases (sex dimension applicability, empty results). Complete for a complex tool with 10 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and already includes detailed descriptions, so baseline is 3. The tool description does not add new parameter-specific semantics beyond workflow context and mutual exclusivity notes already present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries data for a single indicator with optional filters and specifies return fields. It distinguishes itself from sibling tools by naming the workflow and noting that who_search_indicators and who_get_indicator_metadata are used before this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes the find-then-query workflow, names predecessor tools, and provides detailed when-to-use guidance including mutual exclusivity of spatial filters and conditions for the sex filter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
who_search_indicatorsSearch WHO GHO IndicatorsARead-onlyIdempotentInspect
Search the WHO Global Health Observatory indicator catalog by keyword in the indicator name. Returns indicator codes and names for use with who_query_indicator_data. The search uses a substring match on indicator names — try terms like "life expectancy", "immunization", "mortality", "diabetes", or "HIV". If results are truncated, refine the query or use who_list_indicators to browse by offset.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of indicators to return. Default 20, max 100. | |
| query | Yes | Keyword to search in indicator names, e.g. "life expectancy" or "tuberculosis". |
Output Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Present when the limit was reached and more results exist. Suggests how to get additional results. |
| indicators | Yes | Matching indicators up to the requested limit. |
| totalCount | Yes | Total indicators matching the query in the catalog, before the limit is applied. |
| effectiveQuery | Yes | Keyword used for the catalog search, as received by the server. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only and idempotent; description adds substring match behavior, return type (codes and names), and truncation hint. Adds value without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, no wasted words; front-loaded with purpose, each sentence adds distinct value (purpose, usage, behavior, fallback). Efficient and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, description need not detail return structure; it covers search behavior, parameters, and alternative tool usage. Complete for a search tool in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage for both parameters; description adds meaning with substring match explanation, example search terms, and connection to who_list_indicators for browsing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it searches the WHO GHO indicator catalog by keyword in indicator name, returns codes and names, and distinguishes from sibling tool who_list_indicators by specifying its search functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit context: to search by keyword, suggests example terms, and provides guidance if results truncated (refine query or use who_list_indicators). Lacks explicit when-not-to-use but alternatives are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!