How do I use World Bank Indicators MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@World Bank Indicators MCP Server compare latest GDP of USA and China" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

World Bank Indicators MCP Server

by ryanngit

Overview Schema Related Servers Score Discussions

TypeScript

World Bank Indicators MCP Server

Read-only Model Context Protocol server for country and economic data from the World Bank Indicators API. No API key or credentials are required. This independent project is not affiliated with or endorsed by the World Bank Group.

Tools

Tool	Use
`find_countries`	Resolve country codes by name, region, or income level.
`get_indicator_metadata`	Read an indicator definition, source, and topics.
`get_indicator_data`	Fetch a paginated time series for up to 20 countries.
`compare_countries`	Compare latest non-empty indicator values across countries.
`get_country_profile`	Read latest GDP, growth, population, inflation, and unemployment data.

Every tool has bounded input and structured output schemas plus read-only MCP annotations. HTTP, network, timeout, and malformed-response failures return bounded tool errors without writing protocol noise to stdout.

Related MCP server: World Bank Data360 MCP Server

Requirements

Node.js 20 or newer.
Network access to https://api.worldbank.org.

Run With npx

After npm publication, run the pinned package without cloning:

npx -y world-bank-indicators-mcp@0.1.0

The process is a stdio MCP server. Direct terminal use waits silently for JSON-RPC input.

For source development after GitHub publication:

git clone https://github.com/ryanngit/world-bank-indicators-mcp.git
cd world-bank-indicators-mcp
npm ci
npm run verify
npm run build
node .\dist\src\index.js

Claude Desktop

Add this entry to Claude Desktop configuration. It uses the future pinned npm release and needs no local source path or environment variables.

{
  "mcpServers": {
    "world-bank-indicators": {
      "command": "npx",
      "args": ["-y", "world-bank-indicators-mcp@0.1.0"]
    }
  }
}

Configuration locations:

Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

Save the file and restart Claude Desktop. On Windows, if Claude cannot resolve npx, use "command": "cmd" and prepend "/c", "npx" to args.

Examples

Resolve country codes:

{
  "name": "find_countries",
  "arguments": {
    "query": "united",
    "limit": 10
  }
}

Compare latest reported GDP values:

{
  "name": "compare_countries",
  "arguments": {
    "countries": ["CAN", "MEX", "USA"],
    "indicator": "NY.GDP.MKTP.CD"
  }
}

Read a bounded time series page:

{
  "name": "get_indicator_data",
  "arguments": {
    "countries": ["IND", "CHN"],
    "indicator": "SP.POP.TOTL",
    "startYear": 2015,
    "endYear": 2023,
    "page": 1,
    "pageSize": 100
  }
}

get_indicator_data returns page, pages, perPage, and total metadata. Use page to retrieve later result pages.

Development

npm run typecheck
npm test
npm run verify
npm audit --audit-level=high
npm pack --dry-run --json

Tests use Node's built-in test runner and deterministic fetch fixtures. They do not require live World Bank access. Package tests guard repository and license metadata against unresolved publication markers.

For an optional local protocol check with mcp-smoke:

git clone --branch v0.1.0 --depth 1 https://github.com/ryanngit/mcp-smoke.git .mcp-smoke
python .\.mcp-smoke\mcp_smoke.py check --out .\mcp-smoke-out --server-name world-bank-indicators --overwrite -- node .\dist\src\index.js

Data Attribution

Data and indicator metadata come from the World Bank Indicators API. The software license in this repository does not relicense World Bank data. Review the World Bank dataset terms and each indicator's source metadata before redistribution or production use.

Limitations

Live values can be revised, delayed, or absent for some country-year pairs.
Latest non-empty observations can come from different years by country.
Requests have a 10-second full-response timeout and no retry or cache layer.
find_countries excludes aggregate regions by default; set includeAggregates to include them.
Inputs allow at most 20 countries, 100 years per request, 1,000 records per page, and page numbers through 10,000.
get_country_profile always returns five fixed metrics. Missing values use status: "missing" with null year and value.

Support

Search or open a reproducible report in GitHub Issues. Include server version, Node.js version, tool name, sanitized input, and error text. Do not include credentials or private conversation content.

License

Available Tools

5 tools

compare_countriesCompare CountriesA

Read-onlyIdempotent

Compare latest non-empty value for one indicator across 2 to 20 countries.

ParametersJSON Schema

Name	Required	Description	Default
`countries`	Yes
`indicator`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes
`values`	Yes
`indicator`	Yes

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already mark the tool as read-only, idempotent, and non-destructive, so the description's safety burden is low. It adds a useful behavioral detail by clarifying that the comparison uses the latest non-empty value, but it does not explain edge cases like countries with no data or ordering of results.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, tight sentence with no filler. It front-loads the action and includes the most important constraints, making it highly scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The read-only and idempotent annotations cover safety, and an output schema presumably documents the return structure. The main missing piece is explicit guidance on alternative tools, but for a simple two-parameter read-only comparison, the definition is reasonably complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry parameter meaning, but it only restates 'indicator' and '2 to 20 countries' without explaining formats, code conventions, or value domains. The schema regexes help, but the description adds little beyond what parameter names already imply.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description uses a specific verb ('Compare') and clearly defines scope: 'latest non-empty value for one indicator across 2 to 20 countries.' This distinguishes it from siblings like get_country_profile or get_indicator_data, which imply different operation shapes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context via 'across 2 to 20 countries' and 'one indicator,' but it never explicitly contrasts this tool with siblings such as get_indicator_data or find_countries. No when-not-to-use guidance is given, so an agent would need to infer routing.

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

find_countriesFind CountriesA

Read-onlyIdempotent

Find World Bank country codes by name, region, or income level.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`query`	No
`region`	No
`incomeLevel`	No
`includeAggregates`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes
`query`	Yes
`countries`	Yes

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already disclose that the tool is read-only, idempotent, and non-destructive, so the description does not need to repeat these. It adds that the tool returns country codes, but it does not explain behavior around partial matches, aggregate handling, or result limits. This is acceptable but minimal given the 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single efficient sentence with no filler and places the core purpose first. It is concise and easy to scan, though it misses an opportunity to clarify a couple of ambiguous parameters without becoming bloated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output schema covers return values, and annotations cover safety, so the main gap is parameter semantics. The description is adequate for a simple search tool but leaves includeAggregates and pagination/limit behavior ambiguous, which an agent may need when invoking the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry parameter meaning. It conveys that query relates to name, plus region and incomeLevel, but it leaves limit and includeAggregates completely unexplained. With five parameters, this is insufficient.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('find'), a clear resource ('World Bank country codes'), and the available search dimensions ('by name, region, or income level'). This clearly distinguishes it from sibling tools focused on indicators, profiles, or comparisons.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool: whenever an agent needs country codes filtered by name, region, or income level. However, it provides no explicit contrast with siblings such as get_country_profile or compare_countries, leaving some routing ambiguity.

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

get_country_profileGet Country ProfileB

Read-onlyIdempotent

Get country metadata plus latest GDP, growth, population, inflation, and unemployment values.

ParametersJSON Schema

Name	Required	Description	Default
`country`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`country`	Yes
`metrics`	Yes

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the 'latest' qualifier, but does not disclose behavior around missing data, response completeness, or any open-world caveats, so it adds only moderate value beyond 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that names the action, resource, and included data without wasted words. It is efficiently structured and easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter, read-only lookup with a robust output schema and clear annotations, the description is largely sufficient. The main gap is the lack of explicit country-code format guidance, but the schema's regex pattern partially mitigates this.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description needed to explain the 'country' parameter, but it makes no mention of it. The property name and regex pattern imply an ISO-style code, yet there is no explicit statement that the value should be a two- or three-letter country code, nor any example or format guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action ('Get') and a specific resource ('country profile'), and enumerates the exact data returned: metadata plus GDP, growth, population, inflation, and unemployment. It conveys the aggregate nature of this tool versus single-indicator siblings, but it does not explicitly name any sibling to reinforce differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool: whenever a caller needs a country's metadata plus a set of current economic indicators. However, it provides no explicit guidance about when to prefer get_indicator_data, compare_countries, or find_countries instead, so the sibling selection logic is left to inference.

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

get_indicator_dataGet Indicator DataB

Read-onlyIdempotent

Get a paginated annual indicator time series for up to 20 countries and a bounded year range.

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`endYear`	Yes
`pageSize`	No
`countries`	Yes
`indicator`	Yes
`startYear`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`page`	Yes
`observations`	Yes

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context by noting pagination and annual frequency, but most constraints it mentions ('up to 20 countries', 'bounded year range') merely repeat what the schema already enforces through maxItems and min/max values.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that wastes no words and immediately communicates the core action and primary constraints. It loses a point for using 'bounded year range' where something like 'inclusive startYear/endYear range' would be more precise, but overall it is concise and readable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema, the tool has 6 parameters with 0% schema coverage and the description leaves out essential invocation details such as what an 'indicator' is, how countries should be formatted, and how pagination behaves. It also provides no routing to sibling tools. The description is too sparse to fully enable correct use without external knowledge.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for parameter meaning, but it only broadly refers to countries and a year range. It does not explain the indicator format, country code pattern, page/pageSize defaults, or whether startYear/endYear are inclusive. This is inadequate for a 6-parameter tool with zero schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get') and a specific resource ('indicator time series'), and adds key scoping details: paginated, annual, up to 20 countries, and a bounded year range. This distinguishes it from siblings like get_indicator_metadata (metadata vs data) and find_countries (country lookup vs data retrieval).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no explicit guidance on when to use this tool instead of its siblings, such as compare_countries or get_indicator_metadata. There is no 'when to use', 'when not to use', or mention of alternatives. The intended selection context is only implied by the tool's name and the sibling list.

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

get_indicator_metadataGet Indicator MetadataA

Read-onlyIdempotent

Get definition, source, and topics for an exact World Bank indicator code.

ParametersJSON Schema

Name	Required	Description	Default
`indicator`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`indicator`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already provide rich behavioral signals (readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false). The description adds only the exact-match requirement and lists the returned fields, which is useful but not extensive. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. Every word adds meaning: verb, returned content, and the exact-match qualifier are all present.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple, read-only, one-parameter metadata lookup with an output schema and safety annotations, the description is complete. An agent has enough information to invoke it correctly without needing additional behavioral or return details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the meaning of the 'indicator' parameter. It does this by clarifying that the value is an exact World Bank indicator code, which is sufficient for a single, intuitively named parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get') and names concrete return facets ('definition, source, and topics'), scoped to an exact World Bank indicator code. This clearly distinguishes metadata retrieval from the sibling get_indicator_data tool, which implies data values.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The usage context is implied by the tool name and description—use this when you need metadata rather than data series—but it does not explicitly state when to prefer this tool over alternatives like get_indicator_data or get_country_profile. There is no when-not or alternative routing guidance.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation4/5

Each tool has a broadly distinct purpose: metadata lookup, country lookup, time-series data, cross-country comparison, and country profile. get_indicator_data and compare_countries overlap somewhat since both return indicator values, but the former is explicitly a bounded time series while the latter is a latest-value comparison.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern: get_, find_, and compare_ prefixes with clear objects. There are no mixed conventions or vague verbs.

Tool Count5/5

Five tools is a well-scoped size for a World Bank indicators server. Each tool covers a clear need without redundancy or bloat.

Completeness4/5

The core workflows of finding countries, retrieving indicator metadata, fetching time series, comparing countries, and getting a profile are covered. The main gap is that there is no way to search or discover indicators by keyword, topic, or text; only exact indicator codes are supported.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

World Bank Indicators
io.github.Taru0208
Access World Bank development indicators for 200+ countries.
Government Data Open Data Research & Data
2
worldbank-mcp-server A
io.github.cyanheads
Query 29,500+ World Bank development indicators for 200+ countries across 60+ years.
Government Data Open Data Research & Data
923
World Bank Indicators Mcp
io.github.varvararatta
Dive into the wealth of information provided by the World Bank with our zero-auth API. Instantly
Government Data Open Data
2
worlduank A
io.github.pipeworx-io
World Bank MCP — wraps the World Bank Data API v2 (free, no auth)
Government Data Open Data Research & Data
372

Related MCP Servers

World Bank MCP Server
Government Data Open Data
anshumax
F
license
B
quality
F
maintenance
Enables AI assistants to interact with the World Bank open data API, allowing for listing and analysis of indicators across available countries.
Updated a year ago (2025-08-17 09:14 UTC)
1
50
World Bank Data360 MCP Server
Government Data Open Data Research & Data
llnOrmll
A
license
A
quality
D
maintenance
Enables access to World Bank Data360 API with 1000+ economic and social indicators across 200+ countries and 60+ years of historical data, allowing searches, temporal coverage checks, and filtered data retrieval through natural language queries.
Updated 7 months ago (2026-01-27 08:21 UTC)
5
1
MIT
worldbank-mcp
Government Data Open Data Research & Data
tianyuio
A
license
Not graded
quality
C
maintenance
Provides query capabilities for global economic and social development data from the World Bank Open Data API.
Updated 6 months ago (2026-03-01 06:19 UTC)
480
8
MIT
Data360 MCP Serverofficial
Government Data Open Data Research & Data
worldbank
F
license
Not graded
quality
D
maintenance
Provides LLM agents direct access to World Bank development indicators, enabling search, validation, and retrieval of data on topics like GDP, poverty, and gender equality.
Updated 12 days ago (2026-08-22 20:17 UTC)
34

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ryanngit/world-bank-indicators-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

World Bank Indicators MCP Server

Tools

Requirements

Run With npx

Claude Desktop

Examples

Development

Data Attribution

Limitations

Support

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Data360 MCP Serverofficial

Latest Blog Posts

MCP directory API