worldbank-mcp-server
Server Details
Query 29,500+ World Bank development indicators for 200+ countries across 60+ years.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- cyanheads/worldbank-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.4/5 across 7 of 7 tools scored.
Each tool has a distinct purpose: listing country, source, and topic catalogs; searching indicators; fetching metadata for individual countries or indicators; retrieving time-series data. No two tools overlap significantly.
All tools follow the pattern `worldbank_verb_noun` with consistent snake_case (e.g., `worldbank_get_country`, `worldbank_list_sources`). No mixing of styles.
With 7 tools covering the core operations—list, search, get—across the key entities (countries, indicators, sources, topics, data), the surface is well-scoped and not overly numerous.
The tool set covers the full lifecycle for reading World Bank data: discovering entities via listing/searching, retrieving metadata, and fetching actual indicator values. No obvious gaps for a read-only API wrapper.
Available Tools
7 toolsworldbank_get_countryGet World Bank CountryARead-onlyIdempotentInspect
Fetches full metadata for a specific country or aggregate entity: region, income level, capital, coordinates, and lending type. Accepts ISO2 codes (US, DE), ISO3 codes (USA, DEU), or World Bank aggregate codes (EAS, HIC, WLD).
| Name | Required | Description | Default |
|---|---|---|---|
| country_code | Yes | Country code. Accepts ISO2 (US), ISO3 (USA), or aggregate code (EAS, HIC, WLD). Use worldbank_list_countries to browse valid codes. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | Country or aggregate ID. |
| iso2 | Yes | ISO2 country code. |
| name | Yes | Country or aggregate name. |
| region | Yes | World Bank region this country belongs to. |
| latitude | Yes | Capital latitude (empty for aggregates). |
| longitude | Yes | Capital longitude (empty for aggregates). |
| capitalCity | Yes | Capital city name (empty for aggregates). |
| incomeLevel | Yes | World Bank income classification. |
| isAggregate | Yes | True when this entry is a regional or income-group aggregate. |
| lendingType | Yes | World Bank lending type classification. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint. Description adds valuable behavioral context: accepts multiple code types, returns specific metadata fields. No contradictions.
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 that are front-loaded with purpose and essential details. Every clause adds value; 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?
Output schema exists, so return values need not be detailed. Description covers purpose, input flexibility, and cross-reference to sibling tool. Complete for a read-only metadata fetch tool with rich annotations.
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 description, but the description adds practical guidance on valid codes and a cross-reference to the list tool, enhancing agent understanding beyond schema alone.
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 it fetches full metadata for a specific country or aggregate entity, listing fields like region, income level, capital, coordinates, and lending type. Distinguishes from siblings like worldbank_list_countries which lists valid 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?
Explicitly mentions accepted code formats (ISO2, ISO3, aggregate) and cross-references worldbank_list_countries for browsing valid codes. Implicitly guides when to use this tool vs listing tools, though no explicit 'when not to use'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
worldbank_get_dataGet World Bank Indicator DataARead-onlyIdempotentInspect
Queries World Bank indicator values for one or more countries across a time range. The primary data-access tool — use worldbank_search_indicators to find indicator_id values. Returns observations with null values when data is not available for a country×year cell (common for sparse series). Specify either date_range (historical analysis) or mrv (most recent N values), not both. For "all" countries, use pagination (per_page up to 1000) since the API returns ~266 entries per indicator.
| Name | Required | Description | Default |
|---|---|---|---|
| mrv | No | Return the N most recent available values (1–10). Mutually exclusive with date_range. | |
| page | No | Pagination page number (1-based). | |
| per_page | No | Results per page (default: server default, max: 1000). Use higher values for "all" country queries. | |
| countries | Yes | Country codes. Accepts: ISO2 (US, CN), ISO3 (USA, CHN), regional aggregate codes (EAS, LCN, MEA, SAS, SSF, ECS, NAC), income group codes (HIC, UMC, LMC, LIC), world code (WLD), or "all" for all 266 entries (use pagination). Pass a single string or an array of codes for multi-country queries. | |
| date_range | No | Year or year range in YYYY or YYYY:YYYY format (e.g. "2020" or "2010:2023"). Mutually exclusive with mrv. | |
| indicator_id | Yes | Indicator code to query (e.g. NY.GDP.PCAP.CD, SP.POP.TOTL). Use worldbank_search_indicators to find valid IDs. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Indicator observations for this page. Null values are common for sparse series. |
| page | Yes | Current page number. |
| pages | Yes | Total number of pages. |
| total | Yes | Total observations before pagination. |
| indicator | Yes | Indicator metadata echoed from the response. |
| nullCount | Yes | Count of null values on this page — indicates data sparsity for the requested filter. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate safe read-only, open-world, and idempotent behavior. The description adds that null values are returned for missing data, which is useful beyond annotations. No contradictions.
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?
Five sentences, no fluff, front-loaded with main purpose, efficiently covers all critical aspects.
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 complexity (6 params, pagination, mutual exclusivity, null values), the description covers all key usage aspects. Output schema exists, so return value details are not needed.
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 parameter descriptions. The description adds context on mutual exclusivity and pagination, but baseline 3 is appropriate as schema already explains parameters well.
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 World Bank indicator values for countries across a time range, and explicitly distinguishes from the sibling tool worldbank_search_indicators for finding indicator IDs.
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 provides explicit guidance on when to use this tool (primary data access) and when to use alternatives (search_indicators for ID lookup), explains mutual exclusivity of date_range and mrv, and advises pagination for 'all' countries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
worldbank_get_indicatorGet World Bank IndicatorARead-onlyIdempotentInspect
Fetches complete metadata for a single World Bank indicator by its ID: name, description, source dataset, source organization, unit, and thematic topics. Use worldbank_search_indicators to discover indicator IDs if you only know the concept.
| Name | Required | Description | Default |
|---|---|---|---|
| indicator_id | Yes | Indicator code (e.g. NY.GDP.PCAP.CD, SP.POP.TOTL). Use worldbank_search_indicators to find valid IDs. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | Indicator ID. |
| name | Yes | Indicator name. |
| unit | Yes | Unit of measurement (empty when not specified). |
| topics | Yes | Thematic topics this indicator belongs to. |
| sourceId | Yes | Source dataset ID. |
| sourceName | Yes | Source dataset name. |
| sourceNote | Yes | Detailed indicator description from the source. |
| sourceOrganization | Yes | Organization that collects or publishes this data. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, openWorldHint, and idempotentHint. The description adds context about the specific metadata fields returned, which is useful beyond annotations. No contradictions.
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 deliver purpose, content, and usage guidance with no fluff. Essential information is front-loaded.
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 an output schema present and annotations covering behavioral hints, the description provides a complete picture for a simple one-parameter tool, including fallback to sibling 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?
Input schema covers indicator_id with examples and reference to search tool. Schema coverage is 100%, so the description does not add new semantic information. 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 the tool fetches complete metadata for a single World Bank indicator by ID, listing specific metadata fields (name, description, source, etc.). It distinguishes itself from sibling worldbank_search_indicators, which is for discovering IDs.
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 directs the user to use worldbank_search_indicators when only the concept is known, providing clear when-to-use guidance and an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
worldbank_list_countriesList World Bank CountriesARead-onlyIdempotentInspect
Lists countries and regional aggregates with metadata: ISO codes, region, income level, capital, and coordinates. Filterable by region code (e.g. EAS, SSF, NAC) and income level (LIC, LMC, UMC, HIC). By default, excludes regional/income-group aggregate entries and returns individual countries only. Set include_aggregates=true to also see region, income group, and world aggregate entities.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Pagination page number (1-based). | |
| region | No | Filter by World Bank region code. Valid codes: EAS (East Asia & Pacific), ECS (Europe & Central Asia), LCN (Latin America & Caribbean), MEA (Middle East & North Africa), NAC (North America), SAS (South Asia), SSF (Sub-Saharan Africa). | |
| per_page | No | Results per page (default: server default, max: 300). | |
| income_level | No | Filter by income group code: LIC (Low income), LMC (Lower middle income), UMC (Upper middle income), HIC (High income). | |
| include_aggregates | No | When true, includes regional, income-group, and world aggregate entries alongside individual countries. Default false (individual countries only). |
Output Schema
| Name | Required | Description |
|---|---|---|
| page | Yes | Current page number. |
| pages | Yes | Total number of pages. |
| total | Yes | Total matching entries before pagination (includes aggregates if include_aggregates=true). |
| countries | Yes | Countries (and optionally aggregates) matching the filters. |
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. The description adds the default behavior of excluding aggregates, which is useful context 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 concise sentences front-loaded with the main purpose, followed by filtering details and behavior. No unnecessary 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?
With an output schema present and no missing details, the description covers filtering, defaults, and metadata fields. Fully adequate for a listing 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?
Input schema has 100% description coverage, so parameters are well-documented. The description adds minimal extra meaning beyond the schema, thus baseline score of 3.
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 that the tool lists countries and regional aggregates with metadata, distinguishing it from siblings like worldbank_get_country (specific country) and worldbank_get_data (data retrieval).
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 filtering options by region and income level, and explains the default exclusion of aggregates with a flag to include them. Lacks explicit comparison to alternative tools but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
worldbank_list_sourcesList World Bank Data SourcesARead-onlyIdempotentInspect
Lists the 70+ World Bank data sources (datasets) such as World Development Indicators, IDS, and Doing Business. Returns source IDs and names for use as source_id in worldbank_search_indicators. Supports pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Pagination page number (1-based). | |
| per_page | No | Results per page (default: server default, max: 100). |
Output Schema
| Name | Required | Description |
|---|---|---|
| page | Yes | Current page number. |
| pages | Yes | Total number of pages. |
| total | Yes | Total number of sources. |
| sources | Yes | World Bank data sources for this page. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, openWorld, idempotent. Description adds pagination support and approximate count, which is consistent and adds value.
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 concise sentences, front-loaded with purpose, no fluff. Every sentence adds value.
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?
Output schema exists, so return value details not needed. Description covers what is returned (source IDs, names), usage linkage, and pagination. Complete for a list 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 coverage is 100% with parameter descriptions. Description adds 'supports pagination' but does not provide additional semantic detail beyond 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?
Description clearly states verb 'Lists' and resource 'World Bank data sources', with examples. Distinguishes from siblings by mentioning usage in worldbank_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?
Provides context for when to use (to get source IDs for indicator search) but does not explicitly exclude alternatives or mention when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
worldbank_list_topicsList World Bank TopicsARead-onlyIdempotentInspect
Lists all 21 World Bank thematic topics (Economy & Growth, Health, Education, etc.) with descriptions. Use to browse the indicator space or find a topic_id for worldbank_search_indicators.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| topics | Yes | All 21 World Bank thematic topics. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds the exact count (21) and that descriptions are included, which is useful but not critical.
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 states usage. No redundant information, perfectly sized.
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 zero parameters and presence of output schema, the description sufficiently covers the behavior. Mentions the number of topics and that descriptions are included.
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?
No parameters in the schema, so baseline is 4. Description adds no param info, but none is needed.
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 it lists all 21 World Bank thematic topics with descriptions. It distinguishes from siblings by mentioning its use for browsing the indicator space or finding a topic_id for worldbank_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 says when to use: to browse the indicator space or find a topic_id. Does not mention explicit exclusions, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
worldbank_search_indicatorsSearch World Bank IndicatorsARead-onlyIdempotentInspect
Searches the 29,500+ World Bank indicator catalog by keyword, topic, or source. Returns indicator IDs and metadata for chaining into worldbank_get_data. At least one of query, topic_id, or source_id must be provided. When combined with topic_id or source_id, keyword filtering applies across all results in that topic or source. Use worldbank_list_topics for topic IDs, worldbank_list_sources for source IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Pagination page number (1-based). | |
| query | No | Keyword search terms. At least one of query, topic_id, or source_id must be provided. | |
| per_page | No | Results per page (default: server default, max: 100). | |
| topic_id | No | Filter by topic ID (e.g. "1" for Agriculture, "3" for Economy & Growth). Use worldbank_list_topics to browse valid IDs. | |
| source_id | No | Filter by data source ID (e.g. "2" for World Development Indicators). Use worldbank_list_sources to browse valid IDs. |
Output Schema
| Name | Required | Description |
|---|---|---|
| page | Yes | Current page number. |
| pages | Yes | Total number of pages. |
| total | Yes | Total matching indicators before pagination. |
| message | No | Recovery hint when no indicators matched — suggests how to broaden the search. |
| indicators | Yes | Matching indicators for this page. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, open-world, and idempotent hints. Description adds that results include IDs and metadata and explains filtering when combining parameters, adding useful behavioral context 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, no wasted words. Front-loaded with purpose, then constraint, then combination. Sibling references are 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 output schema exists (not detailed), description covers search intent, param constraints, and chaining. Complete for a search tool with 5 params and zero required.
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 parameters with descriptions (100% coverage). Description reinforces the mandatory-at-least-one constraint and clarifies how parameters interact, adding significant value beyond 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?
Clearly states the tool searches the World Bank indicator catalog by keyword, topic, or source, and returns IDs and metadata for chaining into worldbank_get_data. Differentiates from siblings by referencing them explicitly.
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 constraint that at least one of query, topic_id, or source_id must be provided and explains combination behavior. Suggests sibling tools for IDs. Lacks explicit 'when not to use' but this is sufficient.
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!