WHO Global Health Observatory — 3,059 indicators across 194 member states.
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.
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.
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.
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.
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. Many valid indicators have no dimension listing upstream — those return an empty dimensions array with a dimensionsNote, not a not-found. Only codes absent from the catalog are reported in the notFound array, and that is reported rather than raised as an error.
| Name | Required | Description | Default |
|---|---|---|---|
| indicator_codes | Yes | One to ten indicator codes, e.g. ["WHOSIS_000001", "MDG_0000000026"]. |
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| notFound | No | Indicator codes that resolved to neither a catalog name nor any dimension rows — they do not exist in the GHO catalog. |
| indicators | No | Metadata for each code that resolved to a catalog entry. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral context beyond the annotations. It explains that valid indicators may return an empty dimensions array with a dimensionsNote rather than an error, and that only codes absent from the catalog appear in the notFound array, reported rather than raised. This goes well beyond the readOnly and idempotent hints, covering error handling and return semantics that an agent needs to correctly interpret results.
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 concise and front-loaded with the core purpose, then adds necessary edge-case and usage guidance. It is a few sentences with no redundant fluff. It could be slightly tightened (e.g., the example codes are duplicated in the schema), but it is appropriately structured and efficient for the information it conveys.
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 has a single parameter, full schema coverage, and an output schema (which covers return structure), the description sufficiently addresses all functional aspects: what it fetches, when to call it, the 10-code limit, and the important edge cases around empty dimensions and notFound. There is no missing information an agent needs to invoke it correctly or interpret results.
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 a complete parameter description with an example, min/max items, and format guidance (e.g., ['WHOSIS_000001', 'MDG_0000000026']). Schema coverage is 100%, so the baseline is 3. The description adds little beyond the schema—it repeats the 10-code limit and mentions the codes are WHO GHO codes, but these are already in the schema. No extra semantic value is provided.
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 specific verb 'Fetch metadata' and the resource 'WHO GHO indicator codes', including the content (indicator name and supported dimensions). It does not explicitly contrast itself with siblings like who_list_indicators or who_search_indicators, but it does reference the downstream who_query_indicator_data, which helps situate it. This is clear but not fully differentiating from all alternatives.
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 gives an explicit when-to-use instruction: 'Call this before querying data with who_query_indicator_data to confirm which filter dimensions are valid.' It also covers edge cases (empty dimensions array vs notFound) and the call limit. However, it does not state when not to use this tool or mention alternatives such as who_list_dimensions or who_list_indicators, so it lacks the explicit exclusionary guidance needed for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | |||
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| dimensions | No | All available dimension types in the GHO catalog. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnlyHint=true and idempotentHint=true, so the safety profile is covered by structured data. The description adds one useful behavioral signal — 'this tool exposes them all' — indicating the response is the complete set of dimensions rather than a paginated or filtered subset. This is helpful context but not extensive.
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, all earning their place: the main purpose is front-loaded, the workflow guidance follows, and the examples close it out. Nothing is wasted, and the structure is scannable.
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 zero-parameter, read-only list tool with an output schema present and safety annotations provided, the description covers everything an agent needs: what it returns, how to use it in context, and what to expect. Nothing material is missing.
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 tool takes zero parameters and the schema is an empty object, so the baseline of 4 applies. There are no parameter semantics for the description to clarify, and it does not attempt to invent any.
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 states a specific verb (List) with an explicit resource (dimension type codes and human-readable titles) scoped to the WHO GHO API. It also clarifies the tool's role in the discovery workflow and gives concrete examples (COUNTRY, REGION, SEX), making it immediately distinguishable from siblings like who_list_indicators.
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 is given: 'Use this to discover valid dimension codes before calling who_list_dimension_values,' which pins down the tool's position in the expected workflow and names the downstream sibling. It lacks an explicit 'when not to use' statement, hence not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. Results are paged in a deterministic order — narrow hierarchical dimensions with parent_code (e.g. the countries in one WHO region), and page the rest with offset.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of values to return per page. Default 100, max 500. | |
| offset | No | Zero-based offset into the values for this dimension and filter. Default 0. Read hasMore and nextOffset from the response to continue paging. An offset at or beyond totalCount returns an empty values array, not an error. | |
| dimension | Yes | Dimension type code. Use who_list_dimensions to discover all available codes. Common values: COUNTRY, REGION, SEX, WORLDBANKINCOMEGROUP, AGEGROUP. | |
| parent_code | No | Restrict results to values under one parent, e.g. dimension="COUNTRY" with parent_code="EUR" for the countries in the WHO European Region. Only hierarchical dimensions carry a parent; a filter that matches nothing returns an empty page, not an error. |
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| notice | No | Present when values were withheld, the parent_code filter matched nothing, or the requested offset ran past the end. Explains what to do next. |
| offset | No | Zero-based offset this page started at. |
| values | No | Valid values for this dimension type, for the requested page. |
| hasMore | No | True when more values remain beyond this page. Pair with nextOffset to continue. |
| pageInfo | No | Human-readable page position, e.g. "offset 0, showing 100 of 234". Use to construct the next offset. |
| dimension | No | The requested dimension type code. |
| nextOffset | No | Offset to request for the next page. Absent when this page reached the end of the values. |
| totalCount | No | Total values for this dimension and filter, before the limit is applied. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds valuable behavior beyond them: it notes paging is deterministic, explains that hierarchical dimensions use parent_code, and clarifies that offsets beyond totalCount return an empty array rather than an error. This gives the agent confidence in edge-case behavior.
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-loading the core purpose and target dimensions, then immediately providing paging guidance. Every sentence earns its place with no fluff or repetition.
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 moderate complexity (4 params, one optional filter), the description covers discovery, paging, and edge cases (empty arrays). Since an output schema exists, the description is not required to explain return values, and it doesn't need to—the offset parameter in the schema already mentions hasMore and nextOffset. All essential guidance is present.
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% with each parameter described, so the baseline is 3. The description enriches this by giving a concrete example of using dimension='COUNTRY' with parent_code='EUR', which clarifies how parent_code works for hierarchical dimensions. This adds meaning beyond the schema's individual descriptions.
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 names a specific verb ('List') and a specific resource ('valid codes and labels for a WHO GHO dimension type'), and explicitly lists example dimension types (COUNTRY, REGION, etc.). It distinguishes itself from siblings by stating it is used to discover filter values before calling who_query_indicator_data and to confirm ISO codes, which differentiates it from who_list_dimensions (which lists dimension type codes).
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?
It clearly states when to use the tool: 'Use this to discover valid filter values before calling who_query_indicator_data, or to confirm the correct ISO code for a country.' It also refers the user to who_list_dimensions for discovering dimension type codes, providing an alternative. It does not explicitly state when not to use it, but the guidance is clear and contextual.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. |
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| hasMore | No | True when more indicators exist beyond the current page. |
| pageInfo | No | Human-readable page position, e.g. "offset 0, showing 50 of 3059". Use to construct the next offset. |
| indicators | No | Indicators for the requested page. |
| totalCount | No | Total number of indicators in the GHO catalog. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and idempotentHint=true, covering safety and idempotency. The description adds the pagination behavior and clarifies it's a catalog browser, but doesn't elaborate on response format or other traits. Since annotations cover the core behavioral profile, the description's additional value is moderate.
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 the action and scope, followed by a clear routing directive. Zero filler, every sentence earns its place.
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 paginated list tool with full schema coverage, an output schema (present), and rich annotations, the description is complete. It covers the purpose, usage context, and distinguishes from the sibling, and nothing essential is missing.
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% – both limit and offset have detailed descriptions including defaults and ranges. The tool description adds no extra meaning about parameters beyond what the schema already provides, so the baseline of 3 for high coverage 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 uses a specific verb ('Browse') and resource ('WHO Global Health Observatory indicator catalog') and explicitly mentions pagination. It differentiates from the sibling who_search_indicators by stating it's for exploring without a keyword, making the purpose unmistakable.
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 provides explicit usage context: use when exploring without a keyword or paging through the full catalog, and explicitly names the alternative who_search_indicators for keyword-based narrowing. This is ideal routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| 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. | |
| sort | No | Row 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 |
| limit | No | Maximum number of data rows to return. Default 200, max 1000. | |
| offset | No | Zero-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_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 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_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. |
| Name | Required | Description |
|---|---|---|
| rows | No | Data rows matching the query. |
| error | No | Present when the call failed. Absent on success. |
| notice | No | Present when rows were withheld or the requested offset ran past the end of the result set. Explains how to reach the remaining rows. |
| offset | No | Zero-based row offset this page started at. |
| hasMore | No | True when rows remain beyond this page. Pair with nextOffset to continue. |
| pageInfo | No | Human-readable page position, e.g. "offset 0, showing 200 of 12936". Use to construct the next offset. |
| totalRows | No | 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. |
| nextOffset | No | Offset to request for the next page. Absent when this page reached the end of the result set. |
| totalCount | No | Alias of totalRows for cross-tool consistency — total rows before the limit. |
| appliedFilters | No | Filters that were applied to the query. |
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.
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.
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.
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.
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.
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.
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 page further into the same filtered result set with 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". | |
| offset | No | Zero-based offset into the matches for this query. Default 0. Read hasMore and nextOffset from the response to continue paging. An offset at or beyond totalCount returns an empty indicators array, not an error. |
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| notice | No | Present when matches were withheld or the requested offset ran past the end of the result set. Explains how to reach the remaining matches. |
| offset | No | Zero-based offset this page started at. |
| hasMore | No | True when more matches remain beyond this page. Pair with nextOffset to continue. |
| pageInfo | No | Human-readable page position, e.g. "offset 0, showing 20 of 3003". Use to construct the next offset. |
| indicators | No | Matching indicators up to the requested limit. |
| nextOffset | No | Offset to request for the next page. Absent when this page reached the end of the matches. |
| totalCount | No | Total indicators matching the query in the catalog, before the limit is applied. |
| effectiveQuery | No | Keyword used for the catalog search, as received by the server. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description correctly avoids repeating those. It adds meaningful behavior: substring match semantics, pagination via offset with hasMore/nextOffset, and the fact that an out-of-range offset returns an empty array rather than an error. This is rich disclosure beyond the structured 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, front-loaded with the primary purpose, followed by usage examples and a pagination caveat. No redundant language, and every sentence adds useful context.
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 search tool with a full output schema (hasMore/nextOffset referenced), the description covers purpose, usage, matching behavior, pagination, and failure modes. An agent has everything needed to call it correctly without ambiguity.
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%, so parameters are already documented. The description adds value by providing concrete example search terms (e.g., life expectancy, immunization) and clarifying offset behavior beyond the schema note (e.g., reading hasMore/nextOffset, empty result behavior). This goes beyond the baseline but does not fully rewrite parameter docs.
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 states a specific verb (search), resource (WHO GHO indicator catalog), and criterion (keyword in indicator name). It differentiates from siblings like who_list_indicators by emphasizing the substring search and by explicitly linking the returned codes to who_query_indicator_data, making the tool's role clear.
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 clear context: the tool is for finding indicator codes/names to pass to who_query_indicator_data. It offers example keywords and explains pagination refinement for truncated results. However, it does not explicitly contrast with sibling tools like who_list_indicators or when to prefer one over the other, so it stops short of a full when/when-not comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
who_get_indicator_metadata6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "indicators",
+ "notFound"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode. Declared by this tool: `all_not_found`: No requested indicator code resolved to a catalog entry. Other values are possible when a failure originates below the handler.",
+ "examples": [
+ "all_not_found"
+ ],
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "indicators",
- "notFound"
-]who_list_dimension_values6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "dimension",
+ "values",
+ "totalCount",
+ "offset",
+ "hasMore",
+ "pageInfo"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode. Declared by this tool: `dimension_not_found`: An unfiltered lookup of the dimension code returned no values at all — it does not exist in the GHO catalog. `malformed_identifier`: dimension carries an unpaired UTF-16 surrogate, so it cannot be encoded into the request URL. Other values are possible when a failure originates below the handler.",
+ "examples": [
+ "dimension_not_found",
+ "malformed_identifier"
+ ],
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "dimension",
- "values",
- "totalCount",
- "offset",
- "hasMore",
- "pageInfo"
-]who_list_dimensions6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "dimensions"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode.",
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "dimensions"
-]who_list_indicators6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "indicators",
+ "totalCount",
+ "hasMore",
+ "pageInfo"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode.",
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "indicators",
- "totalCount",
- "hasMore",
- "pageInfo"
-]who_query_indicator_data6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "rows",
+ "appliedFilters",
+ "totalRows",
+ "totalCount",
+ "offset",
+ "hasMore",
+ "pageInfo"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode. Declared by this tool: `indicator_not_found`: The indicator code returned HTTP 404 from the GHO API. `no_data`: The indicator exists but no data rows matched the applied filters. `ambiguous_spatial_filter`: More than one of country_codes, region_codes, or income_group_codes were provided. `invalid_year_range`: year_from is greater than year_to, so the time filter can match no rows. `invalid_query`: The GHO API rejected the generated OData query because a supplied filter value is not a valid literal. `malformed_identifier`: indicator_code carries an unpaired UTF-16 surrogate, so it cannot be encoded into the request URL. Other values are possible when a failure originates below the handler.",
+ "examples": [
+ "indicator_not_found",
+ "no_data",
+ "ambiguous_spatial_filter",
+ "invalid_year_range",
+ "invalid_query",
+ "malformed_identifier"
+ ],
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "rows",
- "appliedFilters",
- "totalRows",
- "totalCount",
- "offset",
- "hasMore",
- "pageInfo"
-]who_search_indicators6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "indicators",
+ "effectiveQuery",
+ "totalCount",
+ "offset",
+ "hasMore",
+ "pageInfo"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode. Declared by this tool: `no_results`: No indicators matched the query keyword. Other values are possible when a failure originates below the handler.",
+ "examples": [
+ "no_results"
+ ],
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "indicators",
- "effectiveQuery",
- "totalCount",
- "offset",
- "hasMore",
- "pageInfo"
-]who_get_indicator_metadata4 fields changedOutput schema / properties / indicators / descriptionPrevious value: -"Metadata for each code that returned results."New value: +"Metadata for each code that resolved to a catalog entry."Output schema / properties / indicators / items / properties / dimensions / descriptionPrevious value: -"Dimensions this indicator supports for filtering in who_query_indicator_data."New value: +"Dimensions this indicator supports for filtering in who_query_indicator_data. Empty when the GHO dimension table lists none for this code — see dimensionsNote."Output schema / properties / indicators / items / properties / dimensionsNoteAdded value: +{
+ "description": "Present only when dimensions is empty: explains that the listing is missing upstream rather than the indicator being absent, and how to recover the dimensions from a sample data row.",
+ "type": "string"
+}Output schema / properties / notFound / descriptionPrevious value: -"Indicator codes that returned no metadata — they may not exist in the GHO catalog."New value: +"Indicator codes that resolved to neither a catalog name nor any dimension rows — they do not exist in the GHO catalog."who_list_dimension_values11 fields changedInput schema / properties / limitAdded value: +{
+ "default": 100,
+ "description": "Number of values to return per page. Default 100, max 500.",
+ "maximum": 500,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / offsetAdded value: +{
+ "default": 0,
+ "description": "Zero-based offset into the values for this dimension and filter. Default 0. Read hasMore and nextOffset from the response to continue paging. An offset at or beyond totalCount returns an empty values array, not an error.",
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+}Input schema / properties / parent_codeAdded value: +{
+ "description": "Restrict results to values under one parent, e.g. dimension=\"COUNTRY\" with parent_code=\"EUR\" for the countries in the WHO European Region. Only hierarchical dimensions carry a parent; a filter that matches nothing returns an empty page, not an error.",
+ "minLength": 1,
+ "type": "string"
+}Output schema / properties / hasMoreAdded value: +{
+ "description": "True when more values remain beyond this page. Pair with nextOffset to continue.",
+ "type": "boolean"
+}Output schema / properties / nextOffsetAdded value: +{
+ "description": "Offset to request for the next page. Absent when this page reached the end of the values.",
+ "type": "number"
+}Output schema / properties / noticeAdded value: +{
+ "description": "Present when values were withheld, the parent_code filter matched nothing, or the requested offset ran past the end. Explains what to do next.",
+ "type": "string"
+}Output schema / properties / offsetAdded value: +{
+ "description": "Zero-based offset this page started at.",
+ "type": "number"
+}Output schema / properties / pageInfoAdded value: +{
+ "description": "Human-readable page position, e.g. \"offset 0, showing 100 of 234\". Use to construct the next offset.",
+ "type": "string"
+}Output schema / properties / totalCountAdded value: +{
+ "description": "Total values for this dimension and filter, before the limit is applied.",
+ "type": "number"
+}Output schema / properties / values / descriptionPrevious value: -"Valid values for this dimension type."New value: +"Valid values for this dimension type, for the requested page."Output schema / requiredPrevious value: -[
- "dimension",
- "values"
-]New value: +[
+ "dimension",
+ "values",
+ "totalCount",
+ "offset",
+ "hasMore",
+ "pageInfo"
+]who_query_indicator_data4 fields changedInput schema / properties / region_codes / descriptionPrevious value: -"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."New value: +"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 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."Output schema / properties / rows / items / properties / parentLocationAdded value: +{
+ "description": "Name of the WHO region this row sits under, e.g. \"Western Pacific\" for a JPN row. Not a label for spatialDim itself — the upstream row carries no name for its own spatial entity. Absent when spatialDim is already a region or income group.",
+ "type": "string"
+}Output schema / properties / rows / items / properties / parentLocationCodeAdded value: +{
+ "description": "Code of the WHO region this row sits under, e.g. \"WPR\". Pass to region_codes to query that region's own aggregate rows. Absent alongside parentLocation.",
+ "type": "string"
+}Output schema / properties / rows / items / properties / spatialLabelRemoved value: -{
- "description": "Human-readable spatial label, e.g. WHO region name for a country row.",
- "type": "string"
-}who_query_indicator_data10 fields changedInput schema / properties / offsetAdded value: +{
+ "default": 0,
+ "description": "Zero-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.",
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+}Input schema / properties / sortAdded value: +{
+ "default": "year_desc",
+ "description": "Row 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.",
+ "enum": [
+ "year_desc",
+ "year_asc"
+ ],
+ "type": "string"
+}Output schema / properties / appliedFilters / properties / orderingAdded value: +{
+ "description": "Row ordering applied to the query, e.g. \"most recent first (year_desc)\".",
+ "type": "string"
+}Output schema / properties / appliedFilters / requiredPrevious value: -[
- "indicatorCode"
-]New value: +[
+ "indicatorCode",
+ "ordering"
+]Output schema / properties / hasMoreAdded value: +{
+ "description": "True when rows remain beyond this page. Pair with nextOffset to continue.",
+ "type": "boolean"
+}Output schema / properties / nextOffsetAdded value: +{
+ "description": "Offset to request for the next page. Absent when this page reached the end of the result set.",
+ "type": "number"
+}Output schema / properties / notice / descriptionPrevious value: -"Present when the limit was reached and not all rows were returned. Explains how to retrieve additional rows."New value: +"Present when rows were withheld or the requested offset ran past the end of the result set. Explains how to reach the remaining rows."Output schema / properties / offsetAdded value: +{
+ "description": "Zero-based row offset this page started at.",
+ "type": "number"
+}Output schema / properties / pageInfoAdded value: +{
+ "description": "Human-readable page position, e.g. \"offset 0, showing 200 of 12936\". Use to construct the next offset.",
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "rows",
- "appliedFilters",
- "totalRows",
- "totalCount"
-]New value: +[
+ "rows",
+ "appliedFilters",
+ "totalRows",
+ "totalCount",
+ "offset",
+ "hasMore",
+ "pageInfo"
+]who_search_indicators7 fields changedInput schema / properties / offsetAdded value: +{
+ "default": 0,
+ "description": "Zero-based offset into the matches for this query. Default 0. Read hasMore and nextOffset from the response to continue paging. An offset at or beyond totalCount returns an empty indicators array, not an error.",
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+}Output schema / properties / hasMoreAdded value: +{
+ "description": "True when more matches remain beyond this page. Pair with nextOffset to continue.",
+ "type": "boolean"
+}Output schema / properties / nextOffsetAdded value: +{
+ "description": "Offset to request for the next page. Absent when this page reached the end of the matches.",
+ "type": "number"
+}Output schema / properties / notice / descriptionPrevious value: -"Present when the limit was reached and more results exist. Suggests how to get additional results."New value: +"Present when matches were withheld or the requested offset ran past the end of the result set. Explains how to reach the remaining matches."Output schema / properties / offsetAdded value: +{
+ "description": "Zero-based offset this page started at.",
+ "type": "number"
+}Output schema / properties / pageInfoAdded value: +{
+ "description": "Human-readable page position, e.g. \"offset 0, showing 20 of 3003\". Use to construct the next offset.",
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "indicators",
- "effectiveQuery",
- "totalCount"
-]New value: +[
+ "indicators",
+ "effectiveQuery",
+ "totalCount",
+ "offset",
+ "hasMore",
+ "pageInfo"
+]who_query_indicator_data3 fields changedOutput schema / properties / totalCountAdded value: +{
+ "description": "Alias of totalRows for cross-tool consistency — total rows before the limit.",
+ "type": "number"
+}Output schema / properties / truncatedAdded value: +{
+ "description": "True when the result was capped at the requested limit.",
+ "type": "boolean"
+}Output schema / requiredPrevious value: -[
- "rows",
- "appliedFilters",
- "totalRows"
-]New value: +[
+ "rows",
+ "appliedFilters",
+ "totalRows",
+ "totalCount"
+]who_query_indicator_data2 fields changedOutput schema / properties / rows / items / properties / year / descriptionPrevious value: -"Year of the data point."New value: +"Year of the data point. Absent when the upstream row has no TimeDim (time-independent entries)."Output schema / properties / rows / items / requiredPrevious value: -[
- "indicatorCode",
- "year"
-]New value: +[
+ "indicatorCode"
+]who_list_indicators4 fields changedOutput schema / properties / pageInfoAdded value: +{
+ "description": "Human-readable page position, e.g. \"offset 0, showing 50 of 3059\". Use to construct the next offset.",
+ "type": "string"
+}Output schema / properties / totalRemoved value: -{
- "description": "Total number of indicators in the GHO catalog.",
- "type": "number"
-}Output schema / properties / totalCountAdded value: +{
+ "description": "Total number of indicators in the GHO catalog.",
+ "type": "number"
+}Output schema / requiredPrevious value: -[
- "indicators",
- "total",
- "hasMore"
-]New value: +[
+ "indicators",
+ "totalCount",
+ "hasMore",
+ "pageInfo"
+]who_query_indicator_data5 fields changedOutput schema / properties / appliedFiltersAdded value: +{
+ "additionalProperties": false,
+ "description": "Filters that were applied to the query.",
+ "properties": {
+ "dim1Value": {
+ "description": "dim1_value filter applied, if any.",
+ "type": "string"
+ },
+ "indicatorCode": {
+ "description": "Indicator code that was queried.",
+ "type": "string"
+ },
+ "sex": {
+ "description": "Sex filter value applied, if any.",
+ "type": "string"
+ },
+ "spatialFilter": {
+ "description": "Active spatial filter summary, e.g. \"country_codes: JPN,USA\" or \"region_codes: EUR\".",
+ "type": "string"
+ },
+ "yearRange": {
+ "description": "Applied year range, e.g. \"2015–2023\". Absent when no year filter was set.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "indicatorCode"
+ ],
+ "type": "object"
+}Output schema / properties / noticeAdded value: +{
+ "description": "Present when the limit was reached and not all rows were returned. Explains how to retrieve additional rows.",
+ "type": "string"
+}Output schema / properties / truncatedRemoved value: -{
- "description": "True when totalRows exceeds the limit and not all rows were returned.",
- "type": "boolean"
-}Output schema / properties / truncatedNoteRemoved value: -{
- "description": "Present when truncated is true. Explains how to retrieve additional rows, e.g. by narrowing filters or increasing the limit.",
- "type": "string"
-}Output schema / requiredPrevious value: -[
- "rows",
- "totalRows",
- "truncated"
-]New value: +[
+ "rows",
+ "appliedFilters",
+ "totalRows"
+]who_search_indicators6 fields changedOutput schema / properties / effectiveQueryAdded value: +{
+ "description": "Keyword used for the catalog search, as received by the server.",
+ "type": "string"
+}Output schema / properties / noteRemoved value: -{
- "description": "Present when the limit was reached and more results exist. Suggests how to get additional results.",
- "type": "string"
-}Output schema / properties / noticeAdded value: +{
+ "description": "Present when the limit was reached and more results exist. Suggests how to get additional results.",
+ "type": "string"
+}Output schema / properties / totalCountAdded value: +{
+ "description": "Total indicators matching the query in the catalog, before the limit is applied.",
+ "type": "number"
+}Output schema / properties / totalMatchesRemoved value: -{
- "description": "Total count of indicators matching the query, before the limit is applied.",
- "type": "number"
-}Output schema / requiredPrevious value: -[
- "indicators",
- "totalMatches"
-]New value: +[
+ "indicators",
+ "effectiveQuery",
+ "totalCount"
+]who_get_indicator_metadatawho_list_dimension_valueswho_list_dimensionswho_list_indicatorswho_query_indicator_datawho_search_indicatorsClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity – fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge – works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge – works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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.
No comments yet. Be the first to start the discussion!
WHO GHO MCP — World Health Organization Global Health Observatory (free, no auth)
UN Sustainable Development Goal indicators for all 17 goals, curated by country and year. Free.
World Bank World Development Indicators: curated country-year economy, health, education and more.
490+ economic & demographic indicators for 218 countries from IMF, World Bank, UN, FRED.
Add one secure layer between your agents and this server.
