Skip to main content
Glama

Search World Bank Projects

worldbank_search_projects
Read-onlyIdempotent

Searches the World Bank lending portfolio — the individual loans, credits, and grants the Bank finances — by free text, country, region, status, and board approval date. Returns the project ID, name, borrowing country, region, status, board approval and closing dates, total commitment in USD, financing instrument, major sectors, and a link to the project page. This is the operations catalogue, not the statistics catalogue: use it for "what is the World Bank funding in Kenya", "which climate adaptation projects are active", or "how much was committed to education in South Asia since 2020". For development statistics and time series, use worldbank_search_indicators and worldbank_get_data instead. Countries are identified by ISO2 code here (BR, IN, ZA), which is the one place this server departs from the ISO3 codes its other tools take — worldbank_get_country reports a country's iso2 field for either form, and multi-country operations carry a World Bank regional code such as 3A instead. Every filter is an exact match upstream and combines with the others by AND, so a narrow search can legitimately return nothing; when it does, the response says whether the country codes matched anything on their own.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPagination page number (1-based).
queryNoFree-text search across project names, abstracts, and objectives. Every word must appear, so extra words narrow the result. Omit to browse the portfolio by filter alone, newest board approvals first.
regionNoWorld Bank operational regions to include, combined as OR. These are the lending regions the portfolio is organized by, not the WDI aggregate codes worldbank_get_data accepts.
statusNoLifecycle stages to include, combined as OR. "Active" is under implementation, "Pipeline" is approved but not yet effective, "Closed" has finished disbursing, and "Dropped" was abandoned before approval. Most of the portfolio is closed, so omitting this returns mostly historical operations.
per_pageNoResults per page (default: server default, max: 1000, which is also the most the API will return for one request).
countriesNoBorrowing countries, by the two-character code this API keys on: ISO2 for an economy (BR), or a World Bank regional code for a multi-country operation (3A for Africa, 4E for East Asia and Pacific). Several codes are combined as OR — a project matching any of them is returned. Omit for every country.
approved_toNoLatest board approval date, as YYYY-MM-DD and inclusive.
approved_fromNoEarliest board approval date, as YYYY-MM-DD and inclusive. Board approval is the date the Bank committed to the operation; pipeline projects carry a scheduled date in the future.
include_abstractNoInclude each project's abstract. Abstracts run long — a median of roughly 1,200 characters — so a full page of them roughly doubles the response; leave this off while narrowing a search and turn it on once the result set is small enough to read. Projects that publish no abstract report null either way, which appliedFilters.includeAbstract distinguishes.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
noticeNoContext for an empty result set — including whether the country filter matched anything on its own — or for a page past the end of the results.
projectsNoProjects on this page, newest board approval date first — the order the API returns and the order pagination walks.
totalCountNoTotal projects matching the search, before pagination.
totalPagesNoTotal number of pages.
currentPageNoCurrent page number.
appliedFiltersNoThe effective search sent upstream — confirms country-code normalization and which filters were in force for these results.

TDQS

A5/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description goes far beyond that by explaining that filters are exact matches combined with AND, that narrow searches can legitimately return nothing, and that the response reports whether country codes matched on their own. It also details ISO2 vs. ISO3 handling, regional codes for multi-country operations, and the lifecycle stage definitions (Active, Pipeline, Closed, Dropped) — all behavioral nuances an agent needs to interpret results correctly.

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 long but every sentence earns its place. It is front-loaded with the core purpose, then systematically covers disambiguation, filter semantics, parameter nuance, and edge-case behavior. There is no filler or repetition, and the structure flows logically from 'what' to 'how' to 'when not to use it'.

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 9-parameter search tool with an output schema, the description is remarkably complete. It covers return fields, filter combination logic, country code conventions, regional codes, status definitions, date semantics, pagination hints, and the special behavior of include_abstract. It also anticipates likely mistakes (ISO2 vs ISO3, regional codes, empty results) and addresses them inline. Even with an output schema present, the description preempts most practical ambiguities an agent could face.

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

Parameters5/5

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

Even though schema description coverage is 100%, the description adds substantial meaning not present in the schema. It clarifies that 'region' uses operational lending regions rather than WDI aggregate codes, that 'countries' accepts ISO2 or regional codes with OR semantics, that 'approved_from/to' are inclusive dates and that board approval date is the commitment date (with pipeline projects carrying a scheduled future date). It also explains the size and appropriate usage of 'include_abstract', which is exactly the kind of pragmatic parameter guidance agents need.

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 ('searches') and a precise resource (the World Bank lending portfolio), enumerates the filter dimensions and the returned fields, and explicitly contrasts it with the statistics catalogue. It names sibling tools (worldbank_search_indicators, worldbank_get_data) that serve different purposes, making it unmistakable which 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.

Usage Guidelines5/5

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

It gives explicit when-to-use guidance with concrete example queries ('what is the World Bank funding in Kenya', 'which climate adaptation projects are active') and explicitly routes users to worldbank_search_indicators/worldbank_get_data for statistics and time series. It also flags the ISO2/ISO3 departure, which is a critical operational detail for this server.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: metadata retrieval (worldbank_get_country, worldbank_get_indicator, worldbank_list_countries, worldbank_list_sources, worldbank_list_topics), data querying (worldbank_get_data, worldbank_get_poverty), and searching (worldbank_search_indicators, worldbank_search_projects). No two tools overlap in function; even search_indicators vs get_indicator are complementary (search returns IDs, get fetches details).

Naming Consistency5/5

All tools follow a uniform pattern: the 'worldbank_' prefix followed by a consistent verb_noun structure (get_country, get_data, list_sources, search_indicators). The convention is applied uniformly across all 9 tools, with no mixed styles or deviating verbs.

Tool Count5/5

9 tools is well-scoped for a World Bank data server. It covers metadata, discovery, data access, and project search without redundancy. The number is neither too sparse nor overwhelming, and each tool serves a clear role in the domain.

Completeness5/5

The tool surface covers the core workflows: browsing the catalog (topics, sources, indicators), fetching metadata, retrieving time-series data, accessing poverty/inequality data, and exploring the lending portfolio. There are no obvious gaps; the inclusion of pagination and clear chaining (e.g., search → get) makes the set comprehensive.