Skip to main content
Glama

worldbank-mcp-server

by io.github.cyanheads

Get World Bank Poverty and Inequality Estimates

worldbank_get_poverty
Read-onlyIdempotent

Queries poverty and inequality estimates from the World Bank Poverty and Inequality Platform (PIP) for one or more countries. Returns the poverty headcount ratio, poverty gap, and poverty severity at any poverty line, plus mean and median welfare and population. This is also the tool for inequality and distribution questions — survey-based rows carry the Gini coefficient, mean log deviation, polarization, and the ten decile income/consumption shares, because PIP returns poverty and inequality in the same row. PIP is a separate dataset from the WDI series worldbank_get_data reads: it measures welfare in PPP dollars per person per day and covers individual economies only, so regional and income-group aggregate codes are not accepted. Every row reports how it was produced. estimationType "survey" rows carry the full inequality block; "interpolation", "extrapolation", and "CMD estimation" rows are gap-filled estimates for years no survey covers, and their gini, mld, polarization, and decileShares are null — a documented gap in the source data, not an error.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPagination page number (1-based).
yearNoReporting year to return. A four-digit year (2022), "all" for the full history, or "MRV" for the most recent year available. Omitted behaves as "all". PIP coverage starts in 1963 and runs to the current year.
per_pageNoResults per page (default: server default, max: 1000). "all" countries across "all" years runs to a few thousand rows.
countriesYesCountry codes. PIP identifies economies by ISO3 code (IND, USA, BRA); "all" returns every economy it covers. Pass a single code, an array, or one string separated by commas or semicolons. Regional, income-group, and world aggregate codes (WLD, SSF, HIC) are not served by this dataset — query the individual economies instead.
fill_gapsNoWhen true (the default), any year the surveys do not cover falls back to PIP's own estimate for it instead of being left out — so a single-year query still answers, and a full-history query returns a row per year rather than only the survey years. Those fallback rows carry no inequality data. Set false to return survey-derived rows only, accepting an empty result for years no survey covers.
poverty_lineNoPoverty line in PPP dollars per person per day — any threshold, not only the published ones. Omitted uses the international poverty line of the PIP release currently served, so the applied value is echoed back on every row as povertyLine rather than assumed here. The poverty line does not affect the inequality fields, which describe the whole distribution.
welfare_typeNoRestrict results to one welfare measure. Surveys measure either income or consumption and the two are not directly comparable, so a cross-country comparison is safer pinned to one. Omitted returns whichever each economy publishes, and both where an economy publishes both — thirty-five do, and those return two rows per year.
reporting_levelNoRestrict results to one reporting level. Most economies publish a national figure only; ten publish a split and return an extra row per year for it, China with all three levels and the rest pairing national with either urban or rural. Every row states its own reportingLevel.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
noticeNoContext for an empty result set, or for a result carrying gap-filled rows with no inequality data.
estimatesNoPoverty and inequality estimates for this page, ordered by country, year, reporting level, then welfare type.
totalCountNoTotal estimates before pagination.
totalPagesNoTotal number of pages.
currentPageNoCurrent page number.
appliedFiltersNoThe effective parameters sent to PIP — confirms country code normalization and which filters were in force for these estimates.

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnly, openWorld, and idempotent, so the description builds on that. It discloses crucial behavioral traits: estimationType distinctions (survey vs interpolation/extrapolation/CMD), null gini/mld/polarization/decileShares for gap-filled rows, fill_gaps fallback behavior, welfare_type non-comparability and double-row cases for 35 economies, reporting_level splits for 10 economies, and the poverty_line echoing as povertyLine. This goes far beyond the annotation hints and prevents misinterpretation of null 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 dense paragraph, long but front-loaded with the core purpose and then systematically covering dataset distinction, behavioral notes, and field semantics. Every sentence earns its place; it is redundant only in a minor way (e.g., 'Every row reports how it was produced' is repeated by the estimationType explanation). The density is justified by the tool's complexity, though some agents may benefit from bullet points.

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 an 8-parameter tool with a rich output schema, this description covers the essentials: dataset provenance, field semantics, estimation-type behavior, null handling, coverage period, and parameter-specific quirks. It leaves nothing that an agent needs to know for correct selection and invocation. The presence of an output schema means return structure is not its responsibility. It is complete for both routing and use.

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?

Despite 100% schema coverage, the description adds substantial meaning. It explains the countries parameter's rejection of aggregate codes with examples (WLD, SSF, HIC), the fill_gaps toggle's consequence on row presence, welfare_type's comparability caveat and multi-row behavior, reporting_level's specific split counts, and poverty_line's independence from inequality fields. These details are not in the schema and materially improve correct usage.

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 opens with a specific verb and resource: 'Queries poverty and inequality estimates from the World Bank Poverty and Inequality Platform (PIP) for one or more countries.' It then enumerates the exact metrics returned (headcount ratio, poverty gap, severity, mean/median welfare, population) and explicitly separates itself from the WDI dataset via worldbank_get_data, making the tool uniquely identifiable among siblings.

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?

The description explicitly contrasts with worldbank_get_data ('PIP is a separate dataset from the WDI series worldbank_get_data reads') and frames itself as 'the tool for inequality and distribution questions.' It also gives a clear exclusion: regional and income-group aggregate codes are not accepted, guiding agents to query individual economies instead. This is proactive routing.

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

All worldbank-mcp-server toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

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.

Resources