who-gho-mcp-server

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.

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.

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.

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

Annotations already provide readOnlyHint and idempotentHint, indicating safe read operation. Description adds no additional behavioral context, but annotations suffice. Score reflects baseline given annotation coverage.

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: first states purpose, second gives usage guidance. No unnecessary words, front-loaded with key 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 need not explain return values. Annotations cover behavior, schema covers parameters. Description is complete for a paginated list tool with good structured metadata.

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?

Input schema has 100% coverage with clear descriptions for limit and offset. Description does not add parameter meaning beyond schema, so baseline score applies.

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?

Description clearly states 'Browse the WHO Global Health Observatory indicator catalog with pagination,' specifying both verb and resource, and distinguishes from sibling tool who_search_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?

Explicitly states when to use this tool (no keyword, browsing full catalog) and when to use alternative (keyword search via who_search_indicators). No room for confusion.

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

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

Discloses beyond annotations: mutual exclusivity of spatial filters (error if mixed), conditionality of sex filter, and that omitting spatial filters returns all geographies (potentially large). Annotations already indicate readOnly and idempotent, which align.

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 yet informative. Every sentence adds value. Front-loaded with core purpose, then details and caveats. No wasted words.

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 10 parameters, 1 required, and output schema exists, the description covers workflow, filters, mutual exclusivity, and pitfalls. Comprehensive for a complex tool.

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 covers all 10 parameters (100% coverage). The description adds value by explaining relationships (mutual exclusivity, sex filter condition) not in schema, but does not elaborate on each parameter individually. Baseline 3; adds meaningful context, so 4.

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 queries data rows for a single WHO GHO indicator with filters and describes return fields. It distinguishes itself as the primary data-fetching tool in the workflow, contrasting with sibling tools.

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 provides workflow guidance: use who_search_indicators first, then optionally who_get_indicator_metadata, then this tool. Also warns about mutually exclusive spatial filters and sex filter applicability.

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

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

Beyond the annotations (readOnlyHint, idempotentHint), the description discloses the substring match behavior, which is not captured in the schema. It also explains what the results contain and how they can be used (as input to who_query_indicator_data). There is no contradiction with annotations; in fact, the description reinforces the read-only and idempotent nature of the operation.

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 with three well-structured sentences. The first sentence states the purpose and output, the second explains the matching behavior with examples, and the third provides guidance on handling truncation and alternative tools. Every sentence adds necessary information without redundancy.

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 (2 parameters, read-only, with output schema), the description covers all essential aspects: what the tool does, how the search works, what parameters mean, what results look like, and how to proceed if results are insufficient. The presence of an output schema means return values do not need description, and the tool is complete as is.

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?

Input schema has 100% coverage with descriptions for both parameters (query and limit). The description adds value by clarifying the matching mechanism (substring match on indicator names) and providing example search terms, which is not in the schema. The limit parameter's default and maximum are already in schema but are reinforced. Overall, the description adds meaningful context beyond schema 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 explicitly states the tool's purpose: 'Search the WHO Global Health Observatory indicator catalog by keyword in the indicator name.' It also specifies the output: 'Returns indicator codes and names for use with who_query_indicator_data.' It distinguishes from the sibling 'who_list_indicators' by suggesting it for browsing by offset if results are truncated, making the purpose very clear and specific.

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 clear guidance on when to use the tool (when searching by keyword in indicator names), gives example search terms like 'life expectancy' and 'immunization', and explicitly names an alternative tool ('who_list_indicators') for cases where results are truncated or browsing by offset is needed. This helps the agent decide between this and sibling tools.

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