Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@worldbank-documents-reports-mcp Search for World Bank documents on renewable energy in India from 2020 to 2023"
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.
An MCP server for accessing the World Bank's Documents & Reports database.
Provides searching, retrieval, and detailed breakdowns of World Bank documents for LLMs and programmatic use.
document-reports-mcp/
worldbank_dnr_mcp/ # main package
core.py # business logic, models, utilities
factory.py # server creation and tool registration
parsers.py # transport-specific response parsers
__init__.py # package exports
server_stdio.py # STDIO transport server
server_sse.py # SSE transport server
start_server_claude.py # launcher for Claude Desktop
pyproject.toml # project configuration
requirements.txt # legacy requirements file
docs/ # documentation
API Document.pdf
DESIGN_LOGIC.md
STRUCTURE_GUIDE.md
mcp_simulation.mp4 # demonstration videoRelated MCP server: World Bank Documents MCP Server
comprehensive document search with advanced filters
multi-dimensional filtering (by country, type, language, date range)
result faceting and category exploration
metadata and abstract retrieval
project-based document lookup
flexible markdown/json output formats
extensive error handling and validation
support for both STDIO and SSE transports
Watch the MCP server in action:
Note: Click the link above to view the demonstration video. GitHub README files don't support embedded video players, but you can download or view the video directly through the link.
API Document (PDF): Official World Bank API documentation
DESIGN_LOGIC.md: Core design principles and logic explained
STRUCTURE_GUIDE.md: File structure, configuration, and usage
Using uv (recommended):
uv syncUsing pip:
pip install -r requirements.txtUpdate your Claude Desktop config to use the launcher:
{
"mcpServers": {
"worldbank-dnr": {
"command": "uv",
"args": ["run", "/absolute/path/to/start_server_claude.py"],
"cwd": "/absolute/path/to/document-reports-mcp"
}
}
}Restart Claude Desktop
You can test the SSE server using the MCP Inspector:
Start the SSE server:
uv run server_sse.pyIn another terminal, run the MCP Inspector:
npx @modelcontextprotocol/inspector@latestThe inspector will open at http://localhost:6274
Select "SSE" as the transport type
Enter the server URL: http://localhost:8002/sse
Click "Connect" to interact with the server and test tools
Alternatively, you can use the simple test client:
uv run test_sse_client.pyworldbank_search_documents - primary search with filters
worldbank_get_document_details - retrieve detailed document information
worldbank_explore_facets - discover available filter values
worldbank_search_by_project - find documents by project ID or name
For detailed tool documentation and API usage, see DESIGN_LOGIC.md.
The codebase follows these principles:
DRY principle: shared utilities in core.py, no code duplication
pydantic models: automatic validation for all inputs
async/await: all I/O operations use async patterns
transport abstraction: business logic separated from transport-specific code
factory pattern: centralized server creation with dependency injection
See STRUCTURE_GUIDE.md for detailed architecture explanation.
worldbank_dnr_mcp/core.py: constants, enums, pydantic models, utility functions, formatting helpers
worldbank_dnr_mcp/factory.py: server factory, tool registration
worldbank_dnr_mcp/parsers.py: transport-specific response parsing (only transport-dependent code)
server_stdio.py: STDIO transport wrapper
server_sse.py: SSE transport wrapper
For full architecture breakdown and troubleshooting, see documentation in the docs/ folder.
Explore available facet values in the World Bank Documents database.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered. The description adds nothing beyond that profile: no note on how many facet values come back, whether values are exhaustively enumerated, or what the 'explore' behavior implies about completeness.
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?
A single clean sentence with no waste and the key resource front-loaded. Its brevity edges into under-specification rather than padding, so it reads efficiently even if it does too little.
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?
An output schema exists so return values needn't be explained, but for a discovery-style tool the description omits the essential workflow context: that the returned facet values are meant to become filters for the search tools, and how query narrows the facet set. The definition is too thin for a tool whose whole purpose is discovery-driven.
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?
Reported schema description coverage is 0% at the top level, and the description supplies no parameter meaning at all — it never mentions the facets list, the optional query filter, or the response format. Although the nested $defs schema happens to carry descriptions, the prose contributes nothing to compensate for the coverage gap.
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 and resource ('Explore available facet values') scoped to the World Bank Documents database, which an agent can distinguish from searching or fetching documents. However, it never differentiates itself from its siblings (worldbank_search_documents, worldbank_get_document_details, worldbank_search_by_project) or explains what a 'facet' is in this context.
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?
There is no when-to-use guidance, no stated prerequisites, and no mention of alternatives. An agent cannot tell from the description whether to call this first to discover filter values, or when to prefer worldbank_search_documents instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve detailed information for a specific World Bank document.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered without the description. The description itself adds no behavioral context such as what 'detailed information' comprises, error behavior for a bad ID, or that open-world lookups may refer to external URLs.
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?
A single front-loaded sentence with no filler, which is structurally clean. It is arguably undersized for a tool with usage and parameter nuances, but nothing in it is wasted.
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 read-by-ID tool with full annotations and an output schema, the essentials are present: an output schema removes the need to describe return values, and annotations cover safety. However, the description omits any pointer to where IDs originate and any when-to-use vs search guidance, leaving minor 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?
The description mentions no parameters at all. The nested input model does carry useful descriptions for document_id (ID/GUID with an example) and response_format, which partially mitigates the gap, but against a reported top-level schema coverage of 0% the description should have compensated and does not.
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 ('Retrieve') and resource ('detailed information for a specific World Bank document'), which is clearly distinct from the search/explore siblings. It does not explicitly name or contrast with those siblings, but the get-by-id semantics are unambiguous.
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?
No when-to-use guidance, no prerequisites, and no reference to alternatives like worldbank_search_documents. The only hint that a document_id comes from elsewhere appears in the schema, not the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for documents related to a specific World Bank project.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is fully covered elsewhere. The description adds almost no behavioral context beyond restating that results are project-scoped: no pagination behavior, no result-set characteristics, no indication that an identifier or name is mandatory.
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?
A single, well-formed sentence with no filler and the scoping constraint front-loaded. It is efficiently sized for the sentence it contains, though the same brevity is the source of its specification gaps.
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?
An output schema exists so return values need not be explained, and read-only annotations cover safety. Still, for a search tool sitting beside three siblings, the description omits routing guidance and the required project selector, leaving meaningful 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?
The description contributes zero parameter meaning, but the nested WorldBankProjectSearchInput schema documents limit (1-100, default 20), offset, project_id (example 'P123456'), project_name (example 'Rural Education Project') and response_format in detail. With the schema doing the heavy lifting, baseline 3 applies, though the description misses the either/or constraint between project_id and project_name at the top level.
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?
States a specific verb (search) and resource (documents) and names the scoping dimension (a specific World Bank project). However, it never distinguishes itself from the sibling worldbank_search_documents, so an agent cannot tell from the text which search tool to pick.
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?
No when-to-use or when-not-to-use guidance is given, and no sibling is named as an alternative. The description is silent on the fact that either project_id or project_name must be supplied as the selector.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for documents in the World Bank Documents & Reports database.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered and the description is not contradicted. But the description adds nothing behavioral beyond that: no note on pagination semantics, rate limits, or the fact that results are ranked rather than exact matches. With annotations carrying the load, this is a thin add.
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?
One front-loaded sentence with zero filler, which is structurally clean. The brevity arguably crosses into under-specification, but as a sentence it earns its place and wastes no tokens.
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?
An output schema exists, so return values need not be explained, and the nested input schema documents filters, dates, sorting and pagination thoroughly. What is missing is the selection layer: with three sibling search/exploration tools, the description never says when this one is the right choice, leaving a real gap for a 10-filter search 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 description coverage is reported at 0%, so the description is expected to compensate for parameter ambiguity, and it does not — it mentions no query syntax, date filters, country/language/document-type filters, sorting, or pagination. All of that meaning sits in the nested schema only, and the single visible top-level "params" reference is opaque.
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?
States a specific verb and resource ("Search for documents in the World Bank Documents & Reports database"), so the agent knows exactly what operation is performed. However, it offers no differentiation from sibling worldbank_search_by_project, which is also a document search, so the agent cannot tell from the description alone which search tool to pick.
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?
There is no when-to-use guidance, no stated exclusions, and no reference to any alternative (e.g. worldbank_search_by_project for project-scoped queries, or worldbank_explore_facets when the user does not know valid filter values). The agent must infer usage purely from the name.
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.
v1.0.0worldbank_explore_facetsworldbank_get_document_detailsworldbank_search_by_projectworldbank_search_documentsScored across 4 tools
Each tool targets a distinct action: general search, document details, facet exploration, and project-specific search. The only mild overlap is between search_documents and search_by_project, but their parameters clearly differentiate them.
All tools use the worldbank_ prefix and snake_case with clear verbs. The only minor deviation is search_by_project, which uses a preposition instead of a direct noun, but the pattern remains predictable.
Four tools is on the low side for a documents database, but each serves a distinct purpose and the set is focused. It is not so thin that any tool feels redundant or missing.
The surface covers search, details, facets, and project-specific search. However, there is no tool to list or look up projects, making it hard to obtain project IDs needed for search_by_project, which is a notable workflow gap.
Query 29,500+ World Bank development indicators for 200+ countries across 60+ years.
Access World Bank development indicators for 200+ countries.
Discover, resolve, and query official Brazilian economic data with semantic search and provenance.
Dive into the wealth of information provided by the World Bank with our zero-auth API. Instantly
